使用 logstash + kafka + elasticsearch 實現日志監控
https://blog.csdn.net/github_39939645/article/details/78881047
在本文中，將介紹使用 logstash + kafka + elasticsearch 實現微服務日志監控與查詢。
服務配置
添加 maven 依賴：
添加 log4j2 配置：
在 conf 目錄下創建配置文件 zoo.cfg , 並在其中添加以下內容：
tickTime=2000
dataDir=/var/lib/zookeeper
clientPort=2181
啟動 ZooKeeper
windows:
bin/zkServer.bat start
Kafka_2.11-1.0.0 官網
修改日志存儲位置
config/server.properties
log.dirs=D:/kafka-logs
啟動 Kafka
windows:
bin/windows/kafka-server-start.bat config/server.properties
注：
如果在啟動的時候出現以下錯誤：
錯誤: 找不到或無法加載主類
需要手動修改 bin/windows/kafka-run-class.bat ，找到以下的代碼：
set COMMAND=%JAVA% %KAFKA_HEAP_OPTS% %KAFKA_JVM_PERFORMANCE_OPTS% %KAFKA_JMX_OPTS% %KAFKA_LOG4J_OPTS% -cp %CLASSPATH% %KAFKA_OPTS% %*
將其中的 %CLASSPATH% 添上雙引號 => "%CLASSPATH%" 。
Elasticsearch-6.1.1 官網
安裝 x-pack
bin/elasticsearch-plugin install x-pack
新增用戶：
bin/users useradd mcloud-user
修改角色：
bin/users roles -a logstash_admin mcloud-log-user
注：
系統內置角色：
Known roles: [kibana_dashboard_only_user, watcher_admin, logstash_system, kibana_user, machine_learning_user, remote_monitoring_agent, machine_learning_admin, watcher_user, monitoring_user, reporting_user, kibana_system, logstash_admin, transport_client, superuser, ingest_admin]
啟動服務
bin/elasticsearch.bat
Kibana-6.1.1 官網
安裝 x-pack
bin/kibana-plugin.bat install x-pack
啟動服務
bin/kibana.bat
Logstash-6.1.1 官網
創建配置文件 文檔
config/logstash.conf
input {
logstash-input-kafka {
topics => ["mcloud-log"]
}
}
output {
elasticsearch {
hosts => ["localhost:9200"]
user => "mcloud-user"
password => 123456
}
}
最終效果
相關服務啟動完成后， 登陸 kibana 管理界面，可以看到以下的效果：
KafKa+Logstash+Elasticsearch日志收集系統的吞吐量問題
https://blog.csdn.net/remoa_dengqinyi/article/details/77895931
公司的KafKa+Logstash+Elasticsearch日志收集系統的吞吐量存在問題，logstash的消費速度跟不上，造成數據堆積；
三者的版本分別是：0.8.2.1、1.5.3、1.4.0
數據從KafKa中消費，采用的是logstash-input-kafka插件，輸出到Elasticsearch中采用的是logstash-output-Elasticsearch插件。
對於兩個插件分別進行了一定的配置，參照了下面的博客：點擊打開鏈接
但是問題並沒有得到解決，消費的速度沒有什么提升，或者說提升很小，還有數據堆積。考慮到使用的logstash版本以及插件的版本比較低，所以進行了版本升級：
在logstash的網站上下載了集成所有插件的2.3.4版本的logstash，配置的過程中遇到了以下問題：
Elasticsearch插件的配置：
1、新版本的插件沒有host和port配置，改成了hosts：["127.0.0.1:9200"]
2、新版本的配置中沒有protocol配置
在運行logstash的過程中，命令中有參數-l logs，用來配置log的目錄logs，我沒有手動創建這個目錄，所以日志一直沒有生成，開始一直沒有找到日志文件，一旦有了日志，其中就提示了配置文件的問題，很容易就將新版本的logstash以及兩個插件配置好了。
但是配置好之后，新版本的logstash的吞吐量有所上升，但是在數據量大、上升比較快的時候仍然會有數據堆積，所以問題還是沒有解決。
下面的分析思路：
1、觀察logstash的消費過程發現，kafka的中的數據均衡很差，少部分節點中的數據多，增長快，大部分節點中幾乎沒有數據，所以logstash的多線程到節點的分區中取數據，對於性能的提升不大。由於logstash對於數據的消費采用的是fetch的方式，個人感覺：每個線程會不斷的去kafka中取數據，發現沒有數據之后，在過一段時間之后又會去取，雖然這些分區中沒有數據，但是仍然占用了一部分cpu去取數據，這反而會影響到有數據的線程。如果可以知道哪個節點上有數據，將cpu資源都給這幾個節點，針對這幾個節點進行數據抓取，效率會快很多。現在的情況是，每個分區都分配了一個cpu核心，其中2/3的核心是在不斷去讀卻讀不到數據，只有1/3的cpu在讀取，這對於計算資源是很浪費的。
上面的想法是傻逼的。。。並不是每個分區分配一個線程，就是將一個核心綁定給了這個線程，線程申請的是cpu的計算資源，是從所有的核心中去申請，一個線程對應的分區中沒有數據，那么這個線程就不占用cpu資源，或者說占用的很少，那么剩余的cpu資源就可以給別的線程用。注意：線程綁定的是cpu的計算資源，並不是一個線程綁定一個核心。所以說某些分區中數據少，kafka的負載均衡不好，並不會怎么影響logstash從中消費數據的速度。問題可能還是存在於logstash向ES中寫數據的速度。
2、通過工具觀察一下Elasticsearch的索引速度，如果很慢，很可能是logstash的output環節影響到了吞吐量。
針對Logstash吞吐量一次優化
Logstash性能優化：
場景：
部署節點配置極其牛逼（三台 48核 256G內存 萬兆網卡的機器），ES性能未達到瓶頸，而filebeat又有源源不斷的日志在推送（日志堆積），此時卻發現ES吞吐量怎么也上不去，基本卡在單logstash 7000/s 的吞吐。
這時候我們基本確定瓶頸在logstash上。logstash部署在服務端，主要處理接收filebeat（部署在節點機）推送的日志，對其進行正則解析，並將結構化日志傳送給ES存儲。對於每一行日志進行正則解析，需要耗費極大的計算資源。而節點CPU負載恰巧又不高，這個時候我們就要想辦法拓寬logstash的pipeline了，畢竟我們一天要收集18億條日志。
ELFK部署架構圖如下所示：
這里寫圖片描述
影響logstash性能因素如下：
logstash是一個pipeline，數據流從input進來，在filter進行正則解析，然后通過output傳輸給ES。
filebeat->logstash tcp連接
logstash->es tcp連接
logstash input
logstash filter
logstash output
filebeat-> logstash tcp連接 (目前 非瓶頸)
TCP連接數 ：之前性能測試，3節點logstash可以承受1000節點filebeat的連接。
注：當時性能測試方案 1000節點filebeat推流極低，不確保線上日志大時,filebeat連接數增高成為瓶頸。
網絡帶寬： 萬兆網卡支持，無性能瓶頸
logstash-> es tcp連接 (目前 非瓶頸)
TCP連接數 ：logstash后端僅與3個ES節點建立TCP連接，連接數無問題
網絡帶寬： 萬兆網卡支持，無性能瓶頸。
logstash input (目前 非瓶頸)
接收filebeat推送日志，接收量由filter,output協同決定。
logstash filter & logstash output ( 瓶頸)
升級logstash版本 1.7 -> 2.2
2.2版本之后的logstash優化了input,filter,output的線程模型。
增大 filter和output worker 數量 通過啟動參數配置 -w 48 （等於cpu核數）
logstash正則解析極其消耗計算資源，而我們的業務要求大量的正則解析，因此filter是我們的瓶頸。官方建議線程數設置大於核數，因為存在I/O等待。考慮到我們當前節點同時部署了ES節點，ES對CPU要求性極高，因此設置為等於核數。
增大 woker 的 batch_size 150 -> 3000 通過啟動參數配置 -b 3000
batch_size 參數決定 logstash 每次調用ES bulk index API時傳輸的數據量，考慮到我們節點機256G內存，應該增大內存消耗換取更好的性能。
增大logstash 堆內存 1G -> 16G
logstash是將輸入存儲在內存之中，worker數量 * batch_size = n * heap （n 代表正比例系數）
worker * batch_size / flush_size = ES bulk index api 調用次數
1
2
調優結果：
三節點 logstash 吞吐量 7000 -> 10000 （未達到logstash吞吐瓶頸，目前集群推送日志量冗余） logstash不處理任何解析，采用stdout輸出方式，最高吞吐 11w/s
集群吞吐量 24000 -> 32000 （未飽和）
stop兩個logstash節點后，單節點logstash吞吐峰值15000 （集群目前應該有 2w+ 的日質量，單節點采集1w5，所以為單節點峰值）
集群調優前：
調優前
集群調優后：
這里寫圖片描述
最后觀察，系統負載也一下上去了
這里寫圖片描述
最后，總結一下調優步驟：
worker * batch_size / flush_size = ES bulk index api 調用次數
根據CPU核數調整合適的worker數量，觀察系統負載。
根據內存堆大小，調整batch_size,調試JVM，觀察GC，線程是否穩定。
調整flush_size，這個值默認500，我在生產環境使用的1500，這個值需要你逐步增大，觀察性能，增大到一定程度時，性能會下降，那么那個峰值就是適合你的環境的。