背景说明：
深夜接到客户紧急电话，反馈腾讯云kafka中有大量消息堆积未及时消费。每分钟堆积近100w条数据。但是查看es监控，各项指标都远还没到性能瓶颈。后天公司就要搞电商促销活动，到时候数据量是现在的至少2倍。这让客户很是着急。那这究竟是怎么回事呢？该从何排查才能发现问题所在呢？下面我们一起还原“案发”现场。
客户es集群基本信息如下：
集群使用场景：使用腾讯云es集群存储业务日志数据。
集群架构：冷热架构。
集群规模：3个热节点：8C32G 4T SSD 4个温节点： 8C32G 5T高性能云盘。
数据链路：Filebeat采集日志数据 ---> 腾讯云kafka ----> 客户自建logstash ----> 腾讯云Elasticsearch
具体问题反馈：
kafka的日常消息生产量在260w/min。但是看kafka监控发现消费量只有180w/min。也就是说每分钟会堆积近100w条消息，积累了一段时间后，kafka中堆积的数据量达到数亿条。
kafka消息生产消费监控问题分析：
经过电话沟通后，拿到了客户的logstash配置如下：
logstash.conf
代码语言：javascript复制input{
kafka{
bootstrap_servers => "xx.xx.xx.xx:9092"
#topics => ["xx-yhtplus","xx-order","xx-user","xx-image","xx-goods","xx-activities","xx-wechat"]
topics_pattern => "xx-.*"
consumer_threads => 24
decorate_events => true
group_id => "logstash"
codec => "json"
auto_offset_reset => "latest"
}
}
filter {
mutate {
convert => ["respones-time", "float"]
}
}
output {
elasticsearch {
hosts => ["http://腾讯云VIP:9200"]
user => ""
password => ""
index => "%{[@metadata][topic]}-%{ YYYY-MM-dd}"
}
}logstash.yml
代码语言：javascript复制pipeline.workers: 8
pipeline.output.workers: 8
pipeline.batch.size: 5000
pipeline.batch.delay: 10经过了解发现，客户在腾讯云tke中启动了8个logstash进程，但是实际上只有3个是活跃的，另外5个一直处于空闲状态，且每个logstash进程只使用了不到3核的CPU。
logstash进程客户反馈对logstash.yml配置文件做了多次调整，均不生效。
pipeline.workers设置为logstash核数；
pipeline.batch.size从5000到20000均有调整。
通过客户的配置优化反馈来看，问题应该不是出在logstash.yml配置的调整上，极有可能出现在消费kafka的源头上。我们可以把logstash理解为一个水管，从kafka上游取水，往下游es中灌。既然上游的水有积压，那无非就是调大进水口或者调大出水口。既然es还没到瓶颈，且logstash.yml相关配置无论怎么优化调整，依然没有更多的水灌到es中来。那可以肯定的是问题不在出水口，而是在kafka这侧的进水口出了点问题，即消费kafka的口子没有完全打开。
优化建议：
经过和客户更细致的沟通，得到如下反馈：
- logstash是统一消费一个消费组，该消费组中一共有24个topic；
- 24个topic中有2个topic数据量非常大，其他22个topic数据量一般；
- 每个topic设置为3个partition。
得到如上反馈后，我这边给客户针对该问题的更进一步优化方案，如下： 1. 将topic进行拆分，两个大的topic分别单独作为一个消费组，其他的22个topic作为一个消费组，这样将一个消费组拆分出三个消费组进行消费；
2. 增大topic的partition数量，将两个大的topic的partition调整为24，其他的22个topic的partition调整为8；
3. 起三组logstash，分别消费对应的消费组；
4. 将每组logstash中consumer_threads设置的和每组消费组的总partition大小一致，即保证每个logstash的consumer_thread数目*logstash的进程数目 = kafka对应topic的分区数。
起三组logstash消费进程做完这些调整后，再次观察kafka的消费情况，已经从原来的180w/min提升到了520w/min。消费性能立马提升了近3倍。客户表示非常满意。再也不用担心两天后的促销活动的消息堆积问题。
优化后的消费能力问题解答：
1、这个客户为什么用冷热分离的架构呢？
答：因为该客户对数据的保存时间有严格要求，即数据至少要保存两个月的时间，但是对es的热节点ssd架构比较敏感，因此我们推荐了客户使用腾讯云es的冷热分离的架构，即新索引在热节点上创建，数据保存一周后，通过es提供的索引生命周期管理，自动将热节点上的数据迁移到冷节点中，冷节点使用腾讯云高性能云盘，价格相对ssd更加便宜。数据满2个月后，通过es的索引生命周期自动将冷节点上的数据进行删除，以释放更多的存储空间。
2、明明设置了索引生命周期管理，但是热节点上的数据都超过一周了为什么还是没有迁移到冷节点？
答：索引的生命周期配置只会对新增的索引生效，默认对存量的索引是不生效的，这是为了防止对存量比较重要的索引造成误删除等不可逆的影响，如果需要对存量索引也生效的话， 可以通过设置存量索引的settings，关联对应的Policy即可。
