必看的一篇博客的文章：
https://blog.csdn.net/qq_42150559/article/details/100121453
問題
logstash消費速率遠低於日志數量,消息堆積
部署背景
架構優點：
1、采用kafka作為日志緩沖，在高並發情況下可以通過隊列就能起到削峰填谷的作用，防止 es 集群丟失數據。
2、實現動態schema，業務可以自定義schema，方便日志檢索和查詢
3、每一個業務有獨立的索引
2.1 elk+kafka
發現問題
部署后發現日志量很大，一天有幾個億，kafka中堆積了很多消息，logstash消費不掉，增加logstash實例也收效甚微
1.懷疑是logstash的配置問題，導致消費太慢
2.es的效率是瓶頸
logstash配置
pipeline:
workers: 30
output.workers: 32
batch.size: 3000
batch.delay: 5
1
2
3
4
5
一下是input配置
inputs:
main: |-
input {
kafka {
type => "lx_service"
codec => "plain"
auto_offset_reset => "latest"
client_id => "logstash2es-consumer"
group_id => "logstash2es-consumer"
topics_pattern => ".*"
bootstrap_servers => "kafka.logcenter-cluster.svc:9092"
decorate_events => true
consumer_threads => 4
max_poll_records => "5000"
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
關鍵參數
pipeline.workers:64
總工作線程數，filter的速率主要取決於這個參數
pipeline.output.workers:32
output的線程數，不能高於worker線程數
pipeline.batch.size:1000
batch的總大小
pipeline.batch.delay:10
batch延遲的時間
consumer_threads => 4
消費者線程數，所有pod加起來的總數要盡量跟kafka的partition保持一致max_poll_records => “5000”
每次拉取的最大記錄數queue.max_bytes: 4gblogstash隊列最大保存大小。注：一定要比存儲盤小
kafkaManager
事例：
假設logstash配置30個pod，每個pod配置4個consumer thread,那么共計我們就有4*30=120個consumer。假設有200個partition，那么就有80個partition會和其他partition持有相同的consumer,這樣就沒有分配到最合理。
優化方案：
發布4*50個=consumer線程，每個partition對應一個consumer線程。
問題排查
1.查看pod狀態
進入pod
exec -it xxx /bin/bash
使用top命令，觀察cpuload
cpuload保持在核數左右，還是比較可行的，高了則可以減少worker數量
2.查看集群pod內存及cpu使用
注：logstash在發布時cpu會快速增長，啟動后恢復正常
3.通過ES索引速率查看當前消費效果
一萬以下一定是有問題的
4.ES集群一直處於runing，沒有可用
一般是狀態沒有達到green
查看實際workers
top -H -p [pid進程號]
查看實際workers，一般等於核數
cpu load最好差不多等於核數
vmstat命令
查看bi和bo
看進入的io和輸出io的量是否差不多
優化前
優化后
千萬不要加的配置
queue.checkpoint.writes: 1
logstash的持久化策略，為1時隨時持久化到磁盤，非常影響效率
————————————————
版權聲明：本文為CSDN博主「HurricaneXXX」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/qq_42150559/article/details/100121453