540
技術社區[雲棲]
日誌係列--程序日誌處理挑戰與方案
程序日誌（AppLog）有什麼特點？
內容最全：程序日誌是由程序員給出，在重要的地點、變量數值以及異常都會有記錄，可以說線上90%以上Bug都是依靠程序日誌輸出定位到
格式比較隨意：代碼往往經過不同人開發，每個程序員都有自己愛好的格式，一般非常難進行統一，並且引入的一些第三方庫的日誌風格也不太一樣
-
有一定共性：雖然格式隨意，但一般都會有一些共性的地方，例如對Log4J日誌而言，會有如下幾個字段是必須的：
- 時間
- 級別（Level）
- 所在文件或類（file or class）
- 行數（Line Number）
- 線程號（ThreadId）
處理程序日誌會有哪些挑戰？
1. 數據量大
程序日誌一般會比訪問日誌大1個數量級：假設一個網站一天有100W次獨立訪問，每個訪問大約有20邏輯模塊，在每個邏輯模塊中有10個主要邏輯點需要記錄日誌。
則日誌總數為：
100W * 20 * 10 = 2 * 10^8 條
每條長度為200字節，則存儲大小為
2 * 10^8 * 200 = 4 * 10^10 = 40 GB
這個數據會隨著業務係統複雜變得更大，一天100-200GB日誌對一個中型網站而言是很常見的。
2. 分布服務器多
大部分應用都是無狀態模式，跑在不同框架中，例如:
- 服務器
- Docker（容器）
- 函數計算（容器服務）
對應實例數目會從幾個到幾千，需要有一種跨服務器的日誌采集方案
3. 運行環境複雜
程序會落到不同的環境上，例如：
- 應用相關的會在容器中
- API相關日誌會在FunctionCompute中
- 舊係統日誌在傳統IDC中
- 移動端相關日誌在用戶處
- 網頁端（M站）在瀏覽器裏
為了能夠獲得全貌，我們必須把所有數據統一並存儲起來。
如何解決程序日誌需求
1.統一存儲
目標：要把各渠道數據采集到一個集中化中心，打通才可以做後續事情。
我們可以在日誌服務中創建一個項目來存儲應用日誌，日誌服務提供30+種日誌采集手段：無論是在硬件服務器中埋點，還是網頁端JS，或是服務器上輸出日誌，都可以在實時采集列表中找到。
在服務器日誌上，除了使用SDK等直接寫入外，日誌服務提供便捷、穩定、高性能Agent-Logtail。logtail提供windows、linux兩個版本，在控製台定義好機器組，日誌采集配置後，就能夠實時將服務日誌進行采集，這裏有一個5分鍾視頻。
在創建完成一個日誌采集配置後，我們就可以在項目中操作各種日誌了。
可能有人要問到，日誌采集Agent非常多，有Logstash，Flume，FluentD，以及Beats等，Logtash和這些相比有什麼特點嗎？
- 使用便捷：提供API、遠程管理與監控功能，融入阿裏集團百萬級服務器日誌采集管理經驗，配置一個采集點到幾十萬設備隻需要幾秒鍾
- 適應各種環境：無論是公網、VPC、用戶自定義IDC等都可以支持，https以及斷點續傳功能使得接入公網數據也不再話下
- 性能強，對資源消耗非常小：經過多年磨練，在性能和資源消耗方麵比開源要好，詳見對比測試
2. 快速查找定位
目標：無論數據量如何增長、服務器如何部署，都可以保證定位問題時間是恒定的
例如有一個訂單錯誤，一個延時很長，我們如何能夠在一周幾TB數據量日誌中快速定位到問題。其中還會涉及到各種條件過濾和排查等。
- 例如我們對於程序中記錄延時的日誌，調查延時大於1秒，並且方法以Post開頭的請求數據：
Latency > 1000000 and Method=Post*
- 對於日誌中查找包含error關鍵詞，不包含merge關鍵詞的日誌
-
一天的結果
-
一周的結果
-
更長時間結果
這些查詢都是在不到1秒時間內可以返回
3. 關聯分析
關聯有兩種類型，進程內關聯與跨進程關聯。我們先來看看兩者有什麼區別：
- 進程內關聯：一般比較簡單，因為同一個函數前後日誌都在一個文件中。在多線程環節中，我們隻要根據線程Id進行過濾即可
- 跨進程關聯：跨進程的請求一般沒有明確線索，一般會通過RPC中傳入TracerId來進行關聯
3.1 上下文關聯
還是以使用日誌服務控製台距離，線上通過關鍵詞查詢定位到一個異常日誌：
點擊上下文查詢後，既跳轉到前後N條上下文
- 顯示框可以通過“更早”、“更新”等按鈕加載更多上下文
- 也可以點擊“返回普通搜索模式”進一步排查通過篩選框篩選ThreadID，進行精準上下文的過濾
更多上下文查詢文檔請參見文檔索引查詢下上下文查詢
3.2 跨進程關聯
跨進程關聯也叫Tracing，最早的工作是Google在2010年的那篇著名“Dapper, a Large-Scale Distributed Systems Tracing Infrastructure”，之後開源界借鑒了Google思想做成過了平民化的各種Tracer版本。目前比較有名的有：
- Dapper(Google): 各 tracer基礎
- StackDriver Trace (Google)，現在兼容了ZipKin
- Zipkin：twitter開源的Tracing係統
- Appdash：golang版本
- 鷹眼：阿裏巴巴集團中間件技術技術部研發
- X-ray：AWS在2016年Re：Invent上推出技術
如果從0開始使用Tracer會相對容易一些，但在現有係統中去使用，則會有改造的代價和挑戰。
今天我們可以基於日誌服務，實現一個基本Tracing功能：在各模塊日誌中輸出Request_id, OrderId等可以關聯的標示字段，通過在不同的日誌庫中查找，即可拿到所有相關的日誌。
例如我們可以通過SDK查詢 前端機，後端機，支付係統，訂單係統等日誌，拿到結果後做一個前端的頁麵將跨進程調用關聯起來，以下就是基於日誌服務快速搭建的Tracing係統。
4. 統計分析
查找到特點日誌後，我們有時希望能做一些分析，例如線上有多少種不同類型的錯誤日誌？
- 我們先通過對"__level__"這個日誌級別字段進行查詢，得知一天內有2720個錯誤：
__level__:error
- 接下來，我們可以根據file,line這兩個字段(確定唯一的日誌類型)來進行統計聚合
__level__:error | select __file__, __line__, count(*) as c group by __file__, __line__ order by c desc
就能夠拿到所有錯誤發生的類型和位置的分布了
其他還有諸如根據錯誤碼、高延時等條件進行IP定位與分析等，更多可以參見訪問日誌分析案例。
5. 其他
1.備份日誌審計
可以將日誌備份至OSS或存儲成本更低的IA，或直接到MaxCompute，詳情參見日誌投遞
2.關鍵詞報警
目前有如下方式可以進行報警
1. 在日誌服務中將日誌查詢另存為一個定時任務，對結果進行報警，參見文檔
2. 通過雲監控日誌報警功能，參見文檔
3.日誌查詢權限分配管理
可以通過子賬號+授權組方法隔離開發、PE等權限，參見文檔
最後說一下價格與成本，程序日誌主要會用到日誌服務LogHub + LogSearch功能，這裏有一個和開源方案對比，在查詢成本上是開源方案25%，使用非常便捷，另你開發工作事半功倍。
最後更新：2017-07-11 16:02:36