導語：elk是搭建實時日誌分析系統的通用解決方案，透過elk可以方便地收集、搜尋日誌。但隨著日誌量的增加，根據實際應用場景的最佳化調整能夠更充分的利用系統資源。本文主要記錄我們專案中對elk系統的一些調優。

隨著王者人生相關業務的快速發展，我們每天日誌量很快超過了20億條，儲存超過2TB，elk日誌系統的壓力逐漸增加，日誌系統的調整最佳化已經迫在眉睫。

（elk日誌系統架構）

FileBeat 是一個輕量級的日誌收集處理工具(Agent)。

Elasticsearch 是個開源分散式搜尋引擎，提供蒐集、分析、儲存資料三大功能。

Logstash 主要是用來日誌的蒐集、分析、過濾日誌的工具，支援大量的資料獲取方式。

Kibana 可以為 Logstash 和 ElasticSearch 提供的日誌分析友好的 Web 介面，可以幫助彙總、分析和搜尋重要資料日誌。

以下主要介紹 filebeat、logstash、elasticsearch 的一些最佳化調整

2.1 filebeat最佳化

(1) 負載均衡

問題 ：當日志量非常大（單機超過每天超100GB）的模組上報日誌時，日誌落地延時大，要等一段時間才能在es裡查出來。

原因：

當filebeat.yml 配置檔案裡hosts配置了多個Logstash主機，並且loadbalance設定為true，則輸出外掛會將已釋出的事件負載平衡到所有Logstash主機上。 如果設定為false，則輸出外掛僅將所有事件傳送到一個主機（隨機確定），如果所選主機無響應，則會切換到另一個主機。 預設值為false。

方案：配置多個hosts，配置loadbalance為true

（修改配置前只有一個連線）

（負載均衡最佳化後多個連線）

效果

單機filebeat吞吐量變大

（多連線最佳化後單機出流量變大）

（es建立索引的速度變大）

（2）上報採集 源伺服器ip

原因：filebeat目前不支援上報本機ip

方案：新增欄位client_ip，重啟指令碼動態修改client_ip為本機IP

filebeat.yml 部分配置

restart_filebeat.sh示例

效果

異常日誌也能定位伺服器IP

2.2logstash最佳化

（1）日誌清洗、格式化

問題：採集的原始日誌不規範，需要過濾，格式化

方案：利用logstash進行清理

logstash.conf 示例

效果

以刪掉message欄位為例看效果

（刪掉message前冗餘一份完整原始日誌）

效果

平均每條日誌儲存空間從1.2KB 下降到 0.84KB，減少了近30%的儲存

（每天日誌統計）

2.3elasticsearch最佳化

（1）最佳化模板_template配置

問題：隨著王者榮耀wifi特權上線，日誌量激增，預設配置下磁碟達到瓶頸。

原因：預設配置滿足不了專案需要

number_of_shards 是資料分片數，預設為5

當es叢集節點超過分片數時，不能充分利用所有節點

number_of_replicas 是資料備份數，預設是1

方案：調整模板配置

number_of_shards改為72

number_of_replicas改為0

效果

每天日誌的72個分片均勻分部在36個節點

（每個節點分配了2個分片）

備份從 1 改成了 0，減少了一半的寫入

（io使用率降低）

透過以上調整，目前elk日誌系統可以支援每天超過20億條，2.2 TB的日誌，峰值建立索引超6萬QPS

後續最佳化：不同配置（磁碟空間）機器按權重分配，充分利用資源