1. 背景
另外一个推荐系统的推荐请求追踪日志，通过ELK收集，方便遇到问题时，可以通过唯一标识sid来复现推荐过程
在一次上线之后，发现日志大量缺失，缺失率达90%，确认是由上线引起的，但因为当时没立即发现这个问题，所以没有通过回滚解决
上线的内容改动了推荐请求日志，数据格式未变，增加了单条日志的大小，估计有10~20%的增长
2. 分析
推荐日志的整个收集流程如下：
flowchart LR
线上机器日志 --> 平台Flume --> Kafka --> Logstash --> ES
2.1 版本信息
Flume: 未知
Kafka: 2.4.0
ELK: 6.8
2.2 ELK排查-日志和配置
- 排查确认ELK日志无报错
- Logstash配置也没有问题
- 本地启动Logstash也无报错
2.2 Kafka排查-Kafka数据是否丢失
- Kafka写入Hive确认无丢失
2.3 继续ELK排查-消费不动
在本地启动Logstash过程中发现ES的写入量增加了
于是怀疑是Logstash消费能力不足，于是让DB同学调整了参数Kafka input插件配置consumer_thread，修改后启动报错，于是又改回来
改回来重启之后的Logstash开始消费Kafka的数据，且消费速度很快，因为之前已经堆积了很多消息，但在半个小时之后，消费速度再次降到0附近
2.4 后续修改-无效
后来DB同学在Logstash中看到了报错
Commit cannot be completed since the group has already rebalanced and assigned the partitions to another member. This means that the time between subsequent calls to poll() was longer than the configured max.poll.interval.ms, which typically implies that the poll loop is spending too much time message processing. You can address this either by increasing the session timeout or by reducing the maximum size of batches returned in poll() with max.poll.records.
看起来报错和下面文章中一致，于是按照使用Kafka时一定要注意防止消费速度过慢触发rebalance而导致的重复消费做了下述修改，均无效果
- 升级集群，提供消费能力
- 使用新的group，意味着抛弃了堆积的数据
- 调整max.poll.interval.ms和max.poll.records，减少一批次拉取的数据
2.4 继续排查-日志格式问题
DB同学怀疑是日志格式或者是日志过大的问题，但也没有具体的bad case，后来提出，这个集群的单条日志是比之前排查的集群小很多的，但之前排查的集群数据已无缺失（整体数据量现在排查的集群更大一些）
对比之后发现两个集群ELK版本不同，目前排查的集群版本为6.8，而之前的是7.17，所以想尝试用7.17版本的Logstash写入6.8版本的ES
问题得以解决，虽然解决了问题，但由于Logstash版本跨度太大且Kafka Input插件也跨很多版本，所以无法得知原因
2.5 为何没有立即回滚
- 虽然是修改日志引发的问题，但这个修改也是一个修复，更希望能保留下来，最坏的打算是回滚
- 有紧急的查日志的需求，可以去Hive查，虽然不如Kibana使用的方便，但能提供足够的信息
3. 总结
最终通过升级Logstash的版本，从6.8改为7.17，解决了消费速度过慢的问题