日志是大規模叢集管理系統中非常關鍵的部分，伺服器上的各種日志資料（如通路日志、應用日志等）可以幫助我們回答如運維、開發、營運、客服、安全等各種問題，例如：
運維：服務是否正常，流量和qps是多少；
開發：線上有沒有異常和錯誤發生；
營運：多少賬号開通了服務，其中開通失敗原因是什麼；
客服：系統登入不上了，是客戶的問題還是系統的問題；
安全：誰通路了不該通路的資料。
然而要想從日志中擷取這些資訊，通常需要開發大量腳本和工 具，從頭到底搭建端對端系統，并且為了保證服務可靠性和穩 定性，要做大量維護開發工作。阿裡雲自主研發的針對日志數 據的實時、大規模集中式管理服務sls（simple log service，簡 單日志服務），能夠提供一個從日志采集、過濾、處理、聚合到 線上查詢的完整的海量日志處理平台，滿足各種類型的日志處 理分析需求，減輕廣大開發者的負擔。
sls從2012年開始主要服務于阿裡巴巴内部使用者。後來随着外部使用者對日志服務的需求越來越強烈，我們在2014年4月開始對外開放sls的試用。為何使用者對sls有如此之高的需求，我們認為出于以下幾方面的原因。
要基于資料分析結果做營運。根據日志資料，分析每個使用者的行為軌迹（如何使用産品，在哪些使用場景下會遇到哪些問題等），對于改善産品設計思路和營運方向都很重要。
要定位細小問題。網際網路化使得任何小問題被放大的機率大大增加。例如，有萬分之五的失敗率不足為奇，但在大促銷等時間段内這個影響就會非常之大。日志服務有助于在較短時間内精準定位到一些細小的問題。
要快速響應使用者需求。在使用者回報訂單失敗，或遇到錯誤，客服借助日志服務能馬上找出問題，并盡快解決，這将極大提升使用者滿意度，以及對産品和服務的認可程度。
要降低研發成本。雖然可以通過開發資訊系統（例如客服系統、營運記錄系統）來滿足營運和運維需求，但開發系統本身的時間、成本、維護負擔等，都會影響企業的核心業務。而使用sls，使用者可以投入很少的研發成本，就能得到很好的日志服務。
為了便于了解，我們來看看使用者是如何使用sls的。小a創業開發了一個應用，有10台ecs，分别運作了app、web伺服器等。由于團隊人數有限，他需要身兼運維、開發、營運等多種崗位職責于一身。于是小a借助于sls來進行日志管理服務。
小a首先建立sls project，以及對應的日志類型（category）和儲存時間等選項（例如應用伺服器、系統日志30天輪轉，審計日志90天輪轉）。
為了能收集應用日志，小a在sls控制台上配置了描述日志路徑及其格式（logconfig），定義了每個應用的機器分組（machine group）。
當需要查詢日志時，既可以用api/sdk等方式進行調用，也可以通過sls提供的控制台直接服務（例如在access_log中定位validate步驟執行見圖2）。
小a的日志及其用途如下:
<b>通路日志</b>：通常線上系統的最前端都是apache或者nginx類的http伺服器，它的日志記錄了不同使用者在特定時間的通路行為。以下是一條常見的伺服器通路日志。
213.60.233.243 - - [25/may/2004:00:17:09 +1200] "get /internet/index.html http/1.1" 200 6792 “http://www.aliyun-inc.com" "mozilla/5.0 (x11; u; linux i686; es-es; rv:1.6) gecko/20040413 debian/1.6-5"
小a比較關心每天從www.aliyun.com過來的流量有多少。于是他在sls中選中時間段，輸入ref:“http://www.aliyun-inc.com”，控制台就能馬上篩選出對應的通路日志和次數。
<b>分析請求處理是否正常</b>：在經過前端伺服器處理後，請求會交由具體的後端服務進行處理。以下是java應用服務的異常日志。
[2013-10-25 00:00:29 production mode] - get /search_checked_form.htm/i25587486i error c.a.c.w.impl.webxrootcontrollerimpl - full stack trace of the error templatenotfoundexception: could not find template "/screen/search_checked_form.htm/i25587486i" com.alibaba.citrus.service.pipeline.pipelineexception: failed to invoke valve[#3/3, level 3]
日志中包含了錯誤發生的頁面、傳遞的參數、錯誤發生的接口和具體錯誤堆棧等資訊。小a通過查詢“level:erorr”及其他關鍵詞篩選每天的錯誤，并找到出錯的地方進行修複。但在查詢過程中難免會遇到因為日志不嚴謹引起的誤傷情況，此時除了調整日志輸出外，小a也可以通過在查詢中加上not來排除這些已知原因。
<b>是否有安全隐患或漏洞</b>：在正常提供服務的同時，小a也十分關心是否有漏洞或者安全隐患可能對存儲的資料或者其他敏感資訊造成洩露。以下是使用者登入時的通路日志。
2014-06-03 15:47:26&@#!abcusr_base4&@#!10.128.10.147&@#!&@#!def101500219
2014-06-03 15:47:26&@#!abcusr_base2&@#!10.128.10.47&@#!&@#!def70198810
2014-06-03 15:47:26&@#!jusrabc35u&@#!10.132.161.36&@#!&@#!wfp
日志中包含某個時間點使用者從何處登入特定賬号的記錄。小a可以通過寫一個監控程式調用sls api獲悉是否有緊急的異常登入行為。一般黑客入侵會删除系統中的日志，但sls實時收集日志的機制，能杜絕這種情況的發生。
<b>伺服器是否正常</b>：在伺服器運作期間，硬體或者系統可能出現各種各樣的故障，通過系統日志（類似/var/log/messages）使用者可以獲悉是否有異常發生。
2013 jun 8 23:01:01 out of memory: kill process 9682 (mysqld) score 9 or sacrifice child
killed process 9682, uid 27, (mysqld) total-vm:47388kb, anon-rss:3744kb, file-rss:80kb
以上日志内容表明，mysqld程序由于記憶體使用超過核心限制而被kill。小a更新了ecs記憶體後，再次查詢“kill” 或“out of memory”，就可以發現問題已經解決了。其實以上隻是典型的線上服務系統的一部分日志，還有資料庫、網絡服務、檔案系統等的日志能夠幫助管理人員在出現問題時及時處理。6個月之後，小a的應用非常受歡迎，不僅資料量和機器數目随之增加，sls服務能力也随之動态擴充。 除了以上例子外，我們還可以基于sls的api進行二次開發，支撐運維、營運和客服等系統。讓我們來看一下在阿裡内部使用sls的幾個典型場景：
<b>應用監控</b>：得益于強大的日志收集和查詢能力，飛天監控系統神農底層也是基于sls開發的，現已成為各個叢集标配（圖3）。
<b>性能診斷分析</b>：使用sls日志收集和查詢功能可以存儲所有子產品的請求日志，當發現服務問題時，隻需輸入requestid進行查詢，就能分析該請求的生命周期。例如系統記錄到有一個請求超過10秒，需要快速找到最消耗的時間占據在哪台機器上、在哪個子產品裡、是哪個參數引起。以往需要各個應用進行調查，而現在輸入requestid，就能把問題找到（見圖4）。
<b></b>
<b>客服系統</b>：基于sls可以快速開發客服系統。cnzz、rds等控制台已經通過該方法向終端使用者提供日志，讓使用者自主做查詢和分析（見圖5）。
sls之是以具有如此全面的日志分析能力，和它與生俱來的基因分不開，即為解決阿裡雲的實踐難題而生。下面就從sls的“身世”開始，解析其背後的技術架構和核心優勢。
飛天系統研發初期，為了讓系統順利地運作起來，我們經常要面對“調試基本靠摸，運維基本靠人肉，解決bug基本靠猜”的困境。為了解決這些問題，最直接的方法就是基于日志開發工具，以降低人力成本。剛開始兩年中，我們開發了以下幾種工具：
監控工具（神農）：針對狀态資料的采集和監控系統。
性能工具（tracer）：跨程序/機器跟蹤請求在多台機器和程序中的執行情況和狀态。
離線分析：将日志導入maxcompute進行離線統計和分析。
雖然這些工具幫我們解決了很多問題，但每次面臨新的業務場景時都需要重新搭建一套服務，重新部署一個腳本、寫工具。這些工具背後使用者真正的痛是什麼？ 我們發現，開發人員和運維人員的大部分時間和精力都耗費在定位和分析上。然而為什麼開發環境（特别是分布式環境）調試會變得這麼複雜呢？總體來講，大緻有以下幾方面困難：
動态排程：由于計算和資料解耦，計算會被排程到不同的機器上，例如在系統中往往會有多個前端機處理各種請求，這使我們不得不查找所有機器定位特定問題。
跨子產品依賴：線上系統的讀取或寫入，會從http伺服器開始，到線上系統的伺服器，最後到檔案系統的伺服器，整個生命周期會與多個系統打交道。
分布式：資料分布在十幾台機器上，查詢一次失敗的作業往往需要登入十幾台機器。
規模與資料量：由于系統每秒鐘會處理大量請求和資料，是以log産生速度非常快。最痛苦的是問題快找到了，日志卻被沖垮了，且系統盤ssd小型化使得這個問題更突出。
從以上幾點看，異構系統、機器位置和資料量等都會使傳統調試變得複雜，但問題的複雜性可以分解為以下幾部分：
相關系統數
機器位置數
資料量
本身複雜性
要降低問題複雜度，理想的情況是将分布式和異構系統的調試降維成單機問題。那麼是否可以給使用者提供一種模式，讓他像用單機一樣來調試和診斷複雜系統呢？ 于是我們開始研發sls，解決思路是将日志集中起來，并提供一套簡單而靈活的日志接口滿足各類日志資料需求，優勢在于：建構在飛天系統之上，天生就有擴充性；靈活易用，像瑞士軍刀一樣适配各類日志需求。是以開發人員和運維人員隻需将注意力放在具體的業務邏輯上，所有異構系統、機器等細節問題都由sls服務解決，将所有機器上日志當成在一台機器上使用。
例如：有一個業務場景橫向分布在3台機器（machine1、machine2和machine3）上，縱向每台機器分别有三套服務運作（scheduler、executor和jobworker）（圖6）。
在sls設計中，由于所有日志都已中心化存儲，使用者不需要再擔心日志輪轉、硬碟損壞等問題，也無需登入多台機器寫任何腳本和處理程式。隻需要輸入指定查詢條件（instanceid:“2003…” and project:“apsara_profiling”），sls服務端會在秒級掃描指定時間段的所有日志資料，并且根據語義（and）對結果進行join，把符合條件的日志回報給使用者。此外，使用者還能輸入任意子產品的任意條件進行查找，例如查找錯誤的get請求，統計一個資料的通路行為等。
從圖7中可以清楚地看出sls的架構思路。sls服務端基于飛天服務模式開發，由伏羲（fuxi）進行排程，存儲基于盤古（pangu）和ots（開放結構化資料服務），在服務前端使用nginx伺服器進行restful api托管。
除服務端api外，sls提供了sdk和用戶端（logtail）。logtail對于sls api進行了封裝，将日志資料監控、抓取、過濾和可靠性傳輸等問題進行了處理，減少了使用者收集日志的門檻。
考慮到伴随日志實時需求的同時，大部分使用者會将日志用以離線分析，是以sls服務端還提供了一種maxcompute資料同步機制，能夠将sls中的資料定時歸檔到maxcompute表中。是以對于日志而言，線上查詢和離線分析的需求都能夠簡單地配置使用。為了服務使用者這些需求，sls有哪些挑戰呢？舉兩個例子：
<b>使用者環境千差萬别、日志多樣化，如何保證日志收集穩定可靠？</b>
例如，日志格式有幾百種，如何來适配？如何從檔案夾中篩選到特定模式的日志檔案？日志什麼時候開始寫資料？日志輪轉怎麼處理？當網絡發生閃斷時，如何保證資料不丢？在使用者寫錯程式輸出大量日志後，如何保護logtail不消耗過度的性能等？如何快速配置5000台機器的日志收集？
在過去兩年中，我們花了大量時間從細節中學習，深入使用者場景抽象日志變化的本質原因。在阿裡内部sls的用戶端logtail疊代了不下十幾個版本，從場景覆寫和對于錯誤處理能力中積累了大量的經驗，不斷把使用體驗做好，把錯誤處理做細。
以檔案輪轉為例，輪轉過程中會出現邊界丢少量日志的情況，同時作業系統的不同行為、日志輪轉方法（按大小或時間）、輪轉參數（時間命名、順序編号、壓縮等）等都會将這個問題複雜化。為此我們在作業系統檔案層面之上抽象了輪轉動作，定義了一套系統原語，能夠追溯輪轉的上下遊關系和生命周期，能保證任何輪轉方式都能靈活應對。
<b>對于服務端，如何能夠對一天幾億的日志進行實時存儲和查詢？</b>
日志的資料量和規模通常是非常龐大的。對于一個100mb的日志檔案，如果按每條100位元組計算有一百萬條。當這些日志被寫入時，如何保證将日志産生到可以查詢的時間控制在1分鐘之内？當使用者查詢資料時，如何能在盡可能短的時間（例如2秒内）根據篩選條件在幾千萬資料中找到符合的日志？如何平衡性能和存儲的成本？
針對這些問題，我們最主要的解決方法是采用分布式、批處理以及多級索引技術。由于日志大部分情況下是連續流格式，是以我們對相鄰日志進行切塊，每塊資料内部通過bitmap和linkedlist進行索引存儲，而塊則通過反向索引的方式建立。這樣既能節省日志資料龐大的索引空間，又能在不影響索引速度的情況下保證查詢品質。
對日志研究是從20世紀80年代開始的，在各個領域内積累了豐富的經驗，在安全、監控、營運分析等領域，也有不少關于日志的垂直化應用：
使用splunk等日志服務。splunk為日志解決方案提供較完整的解決方案，然而高昂的使用費及有限的免費資料量，加上傳統軟體部署方式使得其使用成本較高。而sls在規模、性能和服務能力很不錯，隻是由于開發時間還不長，在查詢豐富語義上還有較大提升空間，我們會不斷完善sls查詢能力。
通過mysql+web application搭建解決方案。mysql在千萬級以下作為存儲非常理想，但超過該規模後，性能和穩定性等名額會直接下降。
開源陣營（elastic search+logstash+kibana)。利用第三方開源軟體來搭建一套日志系統，維護和建設成本通常較高，并且es依賴lucene主要進行中長文檔，面對日志這樣的短文檔，索引存儲成本會比較高。而使用sls可以減少開發時間及維護代價，簡單地點幾下配置，就能獲得全面服務，并且具備彈性擴充能力。
此外，sls在技術上還有以下亮點。
<b>用戶端</b>
功能：支援正規表達式支援所有日志。
高性能：每秒十mb級别吞吐量（單core）。
可靠性：處理網絡中斷，檔案輪轉，檔案删除，建立日志等。
管理性：web管理，自動推送，可部署上萬台機器。
<b>服務端</b>
吞吐量：幾十tb/天。
整體延時：日志産生後30秒可查詢，最快5秒。
查詢速度：1秒内過億級别日志。
查詢能力：and or not邏輯組合，支援鍵值以及全文兩種查詢模式。
可靠性：無單點，不丢失資料。
從2012年開始，sls以一套标準化的接口進行支撐，逐漸完善服務環節的各個功能，例如用戶端管理、權限控制、增強服務的規模化管理能力。到目前為止，sls每天接受千萬級查詢請求，處理百tb日志資料，可以為運維、開發、營運和安全等多個部門提供服務。例如在阿裡雲官網所有雲産品的日志資料（ecs、rds、ots等）已經全部通過sls進行管理。未來，我們會在使用體驗和查詢能力上不斷進行優化，包括提供全套api讓使用者來自動化運維自己的叢集，使用者可以定義自己的日志模闆、機器分組等資訊，自動化管理所有産品的日志；提供更多的表達條件滿足日志查詢的需求。
<a href="https://lingyun.aliyun.com/6/sls.html" target="_blank"><b>原文連結</b></a>