如何優化日志系統？

答：此題邀請xinghua來解答，他總結了實際項目中對elk系統的一些調優的經驗，與你分享百億級elk日志系統優化紀實。

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

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

1、日志系統架構

（elk日志系統架構）

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

Elasticsearch 是個開源分布式搜索引擎，提供搜集、分析、存儲數據三大功能。

Logstash 主要是用來日志的搜集、分析、過濾日志的工具，支持大量的數據獲取方式。

Kibana 可以為 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面，可以幫助匯總、分析和搜索重要數據日志。

2、優化日志系統

以下主要介紹 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

問題：不是所有日志都會打印本機IP，比如異常錯誤日志往往無法打印服務器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使用率降低）

3.總結

通過以上調整，目前elk日志系統可以支持每天超過20億條，2.2 TB的日志，峰值創建索引超6萬QPS

后續優化：不同配置（磁盤空間）機器按權重分配，充分利用資源