ELK
<bdo id='ixvsk'></bdo><ul id='ixvsk'></ul>
ES方案是傳統成熟的日志采集的方案，也是目前團隊內外部項目采用的方案。
之前一直采用的是傳統的采集方案：日志 -> filebeat -> kafka ->logstash ->es
涉及組件多，部署運維鏈路復雜。同時，ES有存儲空間占用高的問題。從而引發了日志方案調研比較的討論。
ELK的話，調研驗證了一套可行的輕量級方案，在輕量級場景下（比如單純給一個小的Doris集群采集日志），相比傳統的ELK方案更加簡單輕便：
日志 -> filebeat -> es
Loki
Loki是新興的，面向云原生的方案。與監控告警(grafana\alertmanager)的集成好，存儲成本低。缺點是復雜搜索和分析支持弱、查詢語言和標簽系統用戶上手需要學習成本，團隊內沒有實際落地過。也是我們這次重點比較的一套方案。
功能性能比較
|
對比項 |
說明 |
重要程度 |
ELK方案 |
Loki方案 |
ELK更優 |
Loki更優 |
|
數據存儲成本 |
|
P0 |
官方數據是通常可以將數據壓縮20%~30%，實測下來在某些場景下可以達到50%，使用DEFLATE壓縮算法，最低可以降低超過70% |
10倍的壓縮比 5G數據輸入 存儲實際增長0.5G |
|
√ |
|
數據查詢成本 |
占用的CPU等 |
P0 |
500條并發查詢大概消耗不到一個cpu core |
500條并發查詢大概0.1個CPU |
- |
- |
|
查詢速度 |
1.同一個查詢語句，多久返回結果 2.關鍵字檢索、過濾、提取 |
P0 |
十億條數據規模的文本數據下（單條260B），包括關鍵詞檢索、范圍檢索、組合檢索、模糊查詢等都可以在秒級完成。 |
1.13G總數據量，查詢30天內數據， 耗時21.9秒 |
√ |
|
|
特定字段檢索 |
|
P0 |
支持 |
支持 |
- |
- |
|
分析能力 |
|
P3 |
支持多種分析方法，包括聚合分析，ML，自定義分析器等； |
過濾關鍵詞式查詢分析 |
√ |
|
|
采集方式 |
支持幾種采集方式，鏈路輕量化、插件性能 |
P3 |
可以支持filebeat -> es的輕量化采集，也可以支持大規模采集 |
Promtail，大規模場景未驗證 |
√ |
|
|
采集速度 |
|
P3 |
單個日志文件采集速度約4MB/s，2W條/s。 |
單文本1.2MB/s |
√ |
|
|
吞吐量 |
單位時間的寫入量、寫入速度 |
P2 |
3臺的ES集群，吞吐數據最高可以達到100MB/s |
單臺，3MB/s |
√ |
|
|
監控告警 |
是否支持監控告警、支持程度、復雜度等 |
P2 |
Filebeat和es都有監控接口。可以通過prometheus相應的exporter進行監控告警。 對日志做監控告警需要ElasticAlert ES支持高可用。Filebeat支持數據重傳。 |
支持集群本身監控告警和日志監控告警。原生集成grafana |
|
√ |
|
高可用 |
主備、副本 |
P0 |
副本方式，需要3臺 |
副本方式，需要3臺 |
- |
- |
|
大數據組件支持 |
支持采集的大數據組件列表 |
P0 |
全部支持 |
全部支持 |
- |
- |
|
支持審計日志采集 |
|
P0 |
支持 |
支持 |
- |
- |
|
可擴展性 |
|
P2 |
可動態擴展 |
支持 |
- |
- |
|
Manager納管難度 |
|
P2 |
ES已納管，filebeat/logstash/kibana已具備納管條件。 |
目前不支持 |
√ |
|
Loki在存儲和監控告警方面更優，而ELK在查詢速度、采集能力、分析能力、吞吐量、Manager納管等方面都更優。如果是供客戶使用，ELK更加通用和客戶友好，Loki的話客戶需要有個學習成本。
場景支持比較
|
序號 |
場景 |
場景說明 |
優先級 |
ELK方案 |
Loki方案 |
|
場景1 |
查詢特定節點在特定時間段內的所有日志 |
在此場景中，我們將查詢特定節點在特定時間段內的所有日志。預計查詢速度較快，因為我們已經根據時間戳和主機名進行了優化 |
P0 |
支持 |
支持 |
|
場景2 |
查詢特定時間段內所有節點的 ERROR 日志 |
在此場景中，我們將查詢特定時間段內所有節點的 ERROR 日志。預計查詢速度較快，因為我們已經根據時間戳進行了優化 |
P0 |
支持 |
支持 |
|
場景3 |
查詢特定時間段內某個類別的日志數量（按主機名分組 |
在此場景中，我們將查詢特定時間段內某個日志類別的數量，并按主機名分組。預計查詢速度較快，因為我們已經根據時間戳進行了優化 |
P2 |
支持 |
支持 |
|
場景4 |
查詢某個關鍵詞出現在日志信息中的所有記錄 |
在此場景中，我們將查詢某個關鍵詞出現在日志信息中的所有記錄。預計查詢速度較慢，因為我們需要在“日志信息”列中搜索關鍵詞 |
P0 |
支持 |
支持 |
|
場景5 |
查詢特定日志記錄的上下文（例如前后5條記錄） |
在此場景中，我們將查詢特定日志記錄（例如場景5中找到的記錄）的上下文，包括前后5條記錄。預計查詢速度較快，因為我們可以通過時間戳和主機名快速定位目標日志及其上下文 |
P0 |
支持 |
支持 |
|
場景6 |
查詢特定時間段內某個節點的 ERROR 日志 |
|
P0 |
支持 |
支持 |
|
場景7 |
指定節點、集群、實例維度、指定時間范圍的日志查詢，自由排列組合對日志進行篩選查詢 |
|
P0 |
支持 |
支持 |
|
場景8 |
解析日志里面關鍵字出現數量達到一定的閾值觸發告警 |
|
P2 |
方案需要驗證，通過kibana實現 |
支持 |
場景支持方面，兩套方案都可以支持絕大部分的場景。解析日志關鍵詞出發監控告警這個，ELK方案的實現還未驗證過。
結論
根據各方案現狀以及功能性能場景比較測試下來看，目前比較合適的方案是繼續使用ELK方案。輕量級場景下，通過filebeat直接發送到es來簡化部署鏈路降低復雜性。大規模場景下，繼續使用之前的filebeat->kafka->logstash->es方案。
Loki方案作為一個備選方案，如果出現ELK無法支持的場景，可以看看Loki能否支持。
