日誌監控實踐 - 監控Agent整合Lua引擎實現多維度日誌採集

如上圖所示，這是一個典型的K:V形式組成的日誌。

我們可以透過簡單的分隔符將日誌分隔開，並根據K:V的式樣從日誌中提取出uri、c_time、idc等監控項。

這是一個C++程式的Stack資訊。需要將多行日誌作為一個Trace資訊進行完整提取，並且將每一行裡面的函式名、檔名、行號單獨提取，統一推送，用於批次例項的故障定位。

這個例子需要具備兩個能力，多行日誌處理和單行日誌內提取字串。

在這個例子中，每行日誌混合了服務名、程式碼位置、使用者自定義資料等資訊。需要分別用分隔符、K:V和JSON解析的方式進行提取。

針對這些場景，一些開源方案（例如Logstash，Collectd）透過在配置檔案中支援此類語義或外掛的方式實現了此類功能。我們參考了這些開源實現，結合百度業務的場景，在監控採集Agent上透過日誌外掛功能實現日誌處理需求。

實現外掛時，需要重點考慮以下幾方面：

1. 通用性和易用性：需要儘可能滿足使用者定製化需求， 並且開發簡單。

2. 效能：典型的日誌採集場景中，需要每秒處理數MB甚至數十MB的日誌檔案，並完成欄位切分、正則匹配、資料格式轉換等操作，需要處理引擎有較強的效能。

3. 可用性和安全性：Agent執行線上上生產伺服器上，對穩定和安全有相當高的要求。

如何實現定製化的日誌解析邏輯很簡單。我們封裝了Log解析類，包含獲取單行日誌和返回監控項解析結果的介面，供使用者自定義日誌解析指令碼來呼叫。使用者需要在日誌解析指令碼中實現Callback函式，在解析每行日誌時，被Agent呼叫。

所有的日誌處理邏輯完全在指令碼中實現，例如，使用者可以在指令碼中維護全域性Context，透過Context中儲存的進度資訊，完成多行日誌的處理。

這裡還封裝了通用的日誌處理工具庫，以Lua內建類的形式提供，包含JSON、Debug等工具。

Agent在所有伺服器上執行，可用性和安全性是最重要的考量因素。

可用性方面，主要是避免自定義指令碼本身的Bug或外掛引擎Bug導致採集功能異常。除此之外，需要規避資源佔用超限導致伺服器上其它業務受影響。

對使用者程式碼，需要嚴格規範資源佔用量。執行外掛的任務，作為一個單獨的程式，使用Cgroup和Ulimit等機制限制資源佔用，同時也作為執行隔離的手段，規避單個指令碼或外掛引擎的Bug影響所有采集任務正常執行。

另外，在任務執行時間上，也由Agent加以控制，避免任務超時執行。

安全性方面，自定義日誌解析指令碼需要配置中心統一託管，避免被篡改。

Lua本身提供的一些功能也做了遮蔽，例如io.open/io.popen/os.execute/os.remove等高危操作介面，避免從指令碼呼叫外部程式，或做出刪除系統檔案等操作。

經過一段時間的線上執行，在某些場景下，日誌處理的效能無法滿足需求。

對於通用日誌採集場景，透過將Lua替換成Luajit，日誌解析吞吐量獲得約4倍的提升，可以覆蓋我們幾乎所有的通用日誌採集場景。替換過程中需要關注相容問題處理，例如Regexp語意和標準的Lua並不完全相同，lua_ctx最大數量限制等等。

特殊的業務需求場景，需要針對性地進行最佳化。例如，某些業務日誌的採集過程中，需要進行UNIX時間戳到RFC格式的轉換、IP地址到機房資訊的轉換等操作，在Lua指令碼中透過查表或進行轉換來實現需求的效率非常低。對於這些場景我們使用C++等語言封裝了可以在Lua中直接呼叫的類，有效提升此類操作效能超過一個數量級。這種整合方式也可以用於支援一些定製功能，例如Protobuf和BaiduRPC變數等資訊的採集。

效能方面仍有提升的空間。當前的日誌處理是單程式單執行緒中執行日誌處理引擎解決需求，擴充套件成為多執行緒，利用併發方式可以有效提升吞吐量。