程序日誌處理挑戰與方案

本文作者：簡志，阿里雲計算高級專家，擅長領域日誌分析與處理。

程序日誌（AppLog）有什麼特點？

內容最全：程序日誌是由程序員給出，在重要的地點、變數數值以及異常都會有記錄，可以說線上90%以上Bug都是依靠程序日誌輸出定位到

格式比較隨意：代碼往往經過不同人開發，每個程序員都有自己愛好的格式，一般非常難進行統一，並且引入的一些第三方庫的日誌風格也不太一樣

有一定共性：雖然格式隨意，但一般都會有一些共性的地方，例如對Log4J日誌而言，會有如下幾個欄位是必須的：

時間

級別（Level）

所在文件或類（file or class）

行數（Line Number）

線程號（ThreadId）

處理程序日誌會有哪些挑戰？

1. 數據量大

程序日誌一般會比訪問日誌大1個數量級：假設一個網站一天有100W次獨立訪問，每個訪問大約有20邏輯模塊，在每個邏輯模塊中有10個主要邏輯點需要記錄日誌。

則日誌總數為：

每條長度為200位元組，則存儲大小為

這個數據會隨著業務系統複雜變得更大，一天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開頭的請求數據：

對於日誌中查找包含error關鍵詞，不包含merge關鍵詞的日誌

一天的結果

一周的結果

更長時間結果

這些查詢都是在不到1秒時間內可以返回

3. 關聯分析

關聯有兩種類型，進程內關聯與跨進程關聯。我們先來看看兩者有什麼區別：

進程內關聯：一般比較簡單，因為同一個函數前後日誌都在一個文件中。在多線程環節中，我們只要根據線程Id進行過濾即可

跨進程關聯：跨進程的請求一般沒有明確線索，一般會通過RPC中傳入TracerId來進行關聯

3.1 上下文關聯

點擊上下文查詢後，既跳轉到前後N條上下文

顯示框可以通過「更早」、「更新」等按鈕載入更多上下文

也可以點擊「返回普通搜索模式」進一步排查通過篩選框篩選ThreadID，進行精準上下文的過濾

更多上下文查詢文檔請參見文檔索引查詢下上下文查詢

3.2 跨進程關聯

跨進程關聯也叫Tracing，最早的工作是Google在2010年的那篇著名「Dapper, a Large-Scale Distributed Systems TracingInfrastructure」，之後開源界借鑒了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個錯誤：

接下來，我們可以根據file,line這兩個欄位(確定唯一的日誌類型)來進行統計聚合

就能夠拿到所有錯誤發生的類型和位置的分布了

其他還有諸如根據錯誤碼、高延時等條件進行IP定位與分析等，更多可以參見訪問日誌分析案例。

5. 其他

1.備份日誌審計

可以將日誌備份至OSS或存儲成本更低的IA，或直接到MaxCompute，詳情參見日誌投遞

2.關鍵詞報警

目前有如下方式可以進行報警

1. 在日誌服務中將日誌查詢另存為一個定時任務，對結果進行報警，參見文檔

2. 通過雲監控日誌報警功能，參見文檔

3.日誌查詢許可權分配管理

可以通過子賬號+授權組方法隔離開發、PE等許可權，參見文檔

最後說一下價格與成本，程序日誌主要會用到日誌服務LogHub + LogSearch功能，這裡有一個和開源方案對比，在查詢成本上是開源方案25%，使用非常便捷，另你開發工作事半功倍。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！