摘要: 針對主流日志采集客戶端(Logstash,Fluentd,以及日志服務客戶端Logtail)進行功能、性能和穩定性測評
日志收集的場景
DT時代,數以億萬計的服務器、移動終端、網絡設備每天產生海量的日志。
中心化的日志處理方案有效地解決了在完整生命周期內對日志的消費需求,而日志從設備采集上雲是始於足下的第一步。
三款日志收集工具
logstash
開源界鼎鼎大名ELK stack中的"L",社區活躍,生態圈提供大量插件支持。
logstash基於JRuby實現,可以跨平台運行在JVM上。
模塊化設計,有很強的擴展性和互操作性。
fluentd
開源社區中流行的日志收集工具,td-agent是其商業化版本,由Treasure Data公司維護,是本文選用的評測版本。
fluentd基於CRuby實現,並對性能表現關鍵的一些組件用C語言重新實現,整體性能不錯。
fluentd設計簡潔,pipeline內數據傳遞可靠性高。相較於logstash,其插件支持相對少一些。
logtail
阿里雲日志服務的生產者,目前在阿里集團內部機器上運行,經過3年多時間的考驗,目前為阿里公有雲用戶提供日志收集服務。
采用C++語言實現,對穩定性、資源控制、管理等下過很大的功夫,性能良好。相比於logstash、fluentd的社區支持,logtail功能較為單一,專注日志收集功能。
日志文件收集場景 - 功能對比
| 功能項 | logstash | fluentd | logtail |
|---|---|---|---|
| 日志讀取 | 輪詢 | 輪詢 | 事件觸發 |
| 文件輪轉 | 支持 | 支持 | 支持 |
| Failover處理 (本地checkpoint) | 支持 | 支持 | 支持 |
| 通用日志解析 | 支持grok(基於正則表達式)解析 | 支持正則表達式解析 | 支持正則表達式解析 |
| 特定日志類型 | 支持delimiter、key-value、json等主流格式 | 支持delimiter、key-value、json等主流格式 | 支持key-value格式 |
| 數據發送壓縮 | 插件支持 | 插件支持 | LZ4 |
| 數據過濾 | 支持 | 支持 | 支持 |
| 數據buffer發送 | 插件支持 | 插件支持 | 支持 |
| 發送異常處理 | 插件支持 | 插件支持 | 支持 |
| 運行環境 | JRuby實現,依賴JVM環境 | CRuby、C實現,依賴Ruby環境 | C++實現,無特殊要求 |
| 線程支持 | 支持多線程 | 多線程受GIL限制 | 支持多線程 |
| 熱升級 | 不支持 | 不支持 | 支持 |
| 中心化配置管理 | 不支持 | 不支持 | 支持 |
| 運行狀態自檢 | 不支持 | 不支持 | 支持cpu/內存閾值保護 |
日志文件收集場景 - 性能對比
日志樣例
以Nginx的access log為樣例,如下一條日志365字節,結構化成14個字段:
在接下來的測試中,將模擬不同的壓力將該日志重復寫入文件,每條日志的time字段取當前系統時間,其它13個字段相同。
相比於實際場景,模擬場景在日志解析上並無差異,有一點區別是:較高的數據壓縮率會減少網絡寫出流量。
logstash
logstash-2.0.0版本,通過grok解析日志並寫出到kafka(內置插件,開啟gzip壓縮)。
日志解析配置:
-
grok {
-
patterns_dir=> "/home/admin/workspace/survey/logstash/patterns"
-
match=>{ "message"=>"%{IPORHOST:ip} %{USERNAME:rt} - \[%{HTTPDATE:time}\] \"%{WORD:method} %{DATA:url}\" %{NUMBER:status} %{NUMBER:size} \"%{DATA:ref}\" \"%{DATA:agent}\" \"%{DATA:cookie_unb}\" \"%{DATA:cookie_cookie2}\" \"%{DATA:monitor_traceid}\" %{WORD:cell} %{WORD:ups} %{BASE10NUM:remote_port}" }
-
remove_field=>[ "message"]
-
}
測試結果:
| 寫入TPS | 寫入流量 (KB/s) | CPU使用率 (%) | 內存使用 (MB) |
|---|---|---|---|
| 500 | 178.22 | 22.4 | 427 |
| 1000 | 356.45 | 46.6 | 431 |
| 5000 | 1782.23 | 221.1 | 440 |
| 10000 | 3564.45 | 483.7 | 450 |
fluentd
td-agent-2.2.1版本,通過正則表達式解析日志並寫入kafka(第三方插件fluent-plugin-kafka,開啟gzip壓縮)。
日志解析配置:
-
<source>
-
type tail
-
format /^(? <ip>\S+)\s(?<rt>\d+)\s-\s\[(?<time>[^\]]*)\]\s"(?<url>[^\"]+)"\s(?<status>\d+)\s(?<size>\d+)\s"(?<ref>[^\"]+)"\s"(?<agent>[^\"]+)"\s"(?<cookie_unb>\d+)"\s"(?<cookie_cookie2>\w+)"\s"(?
-
<monitor_traceid>\w+)"\s(?<cell>\w+)\s(?<ups>\w+)\s(?<remote_port>\d+).*$/
-
time_format %d/%b/%Y:%H:%M:%S %z
-
path /home/admin/workspace/temp/mock_log/access.log
-
pos_file /home/admin/workspace/temp/mock_log/nginx_access.pos
-
tag nginx.access
-
</source>
-
測試結果:
| 寫入TPS | 寫入流量 (KB/s) | CPU使用率 (%) | 內存使用 (MB) |
|---|---|---|---|
| 500 | 178.22 | 13.5 | 61 |
| 1000 | 356.45 | 23.4 | 61 |
| 5000 | 1782.23 | 94.3 | 103 |
注:受GIL限制,fluentd單進程最多使用1個cpu核心,可以使用插件multiprocess以多進程的形式支持更大的日志吞吐。
logtail
logtail 0.9.4版本,設置正則表達式進行日志結構化,數據LZ4壓縮后以HTTP協議寫到阿里雲日志服務,設置batch_size為4000條。
日志解析配置:
-
logRegex : ( \S+)\s(\d+)\s-\s\[([^]]+)]\s"([^"]+)"\s(\d+)\s(\d+)\s"([^"]+)"\s"([^"]+)"\s"(\d+)"\s"(\w+)"\s"(\w+)"\s(\w+)\s(\w+)\s(\d+).*
-
keys : ip,rt,time,url,status,size,ref,agent,cookie_unb,cookie_cookie2,monitor_traceid,cell,ups,remote_port
-
timeformat : %d/%b/%Y:%H:%M:%S
-
測試結果:
| 寫入TPS | 寫入流量 (KB/s) | CPU使用率 (%) | 內存使用 (MB) |
|---|---|---|---|
| 500 | 178.22 | 1.7 | 13 |
| 1000 | 356.45 | 3 | 15 |
| 5000 | 1782.23 | 15.3 | 23 |
| 10000 | 3564.45 | 31.6 | 25 |
單核處理能力對比
總結
可以看到三款日志工具各有特點:
-
logstash支持所有主流日志類型,插件支持最豐富,可以靈活DIY,但性能較差,JVM容易導致內存使用量高。
-
fluentd支持所有主流日志類型,插件支持較多,性能表現較好。
-
logtail占用機器cpu、內存資源最少,結合阿里雲日志服務的E2E體驗良好,但目前對特定日志類型解析的支持較弱,后續需要把這一塊補起來。



