0x00 概述
filebeat非常轻量级,正常情况下占用的资源几乎都能忽略不计,但是部署后发现资源占用很大,所以怀疑是filebeat本身出了问题。
第一时间查看filebeat日志(默认路径/var/log/filebeat/filebeat,K8S需要在控制台实时查看pod的日志),发现有大量内容输出:
2019-03-20T08:55:02.198+0800 INFO kafka/log.go:53 producer/broker/544 starting up 2019-03-20T08:55:02.198+0800 INFO kafka/log.go:53 producer/broker/544 state change to [open] on wp-news-filebeat/4 2019-03-20T08:55:02.198+0800 INFO kafka/log.go:53 producer/leader/wp-news-filebeat/4 selected broker 544 2019-03-20T08:55:02.198+0800 INFO kafka/log.go:53 producer/broker/478 state change to [closing] because EOF 2019-03-20T08:55:02.199+0800 INFO kafka/log.go:53 Closed connection to broker bitar1d12:9092 2019-03-20T08:55:02.199+0800 INFO kafka/log.go:53 producer/leader/wp-news-filebeat/5 state change to [retrying-3] 2019-03-20T08:55:02.199+0800 INFO kafka/log.go:53 producer/leader/wp-news-filebeat/4 state change to [flushing-3] 2019-03-20T08:55:02.199+0800 INFO kafka/log.go:53 producer/leader/wp-news-filebeat/5 abandoning broker 478 2019-03-20T08:55:02.199+0800 INFO kafka/log.go:53 producer/leader/wp-news-filebeat/2 state change to [retrying-2] 2019-03-20T08:55:02.199+0800 INFO kafka/log.go:53 producer/leader/wp-news-filebeat/2 abandoning broker 541 2019-03-20T08:55:02.199+0800 INFO kafka/log.go:53 producer/leader/wp-news-filebeat/3 state change to [retrying-2] 2019-03-20T08:55:02.199+0800 INFO kafka/log.go:53 producer/broker/478 shut down
0x01 发现问题
看日志描述,似乎是一直地在不停的创建和关闭kafka连接。
起初怀疑是kafka相关dns没有配置(/etc/resolve.conf)导致连不上kafka的broker,但检查并和正常的机器对比后,dns配置是一样的,也就排除了这种情况。
接下来怀疑可能是filebeat版本的问题,因为elastic家族的产品就是那个尿性,发版速度很频繁,而且不同大版本有很多不兼容。
对比filebeat版本,发现它的版本(6.5.3)比正常的服务器(5.6.12)高一个大版本,所以怀疑不同版本对kafka的处理机制不一样导致的。
为了验证这个问题,在查阅filebeat官网后发现,6.5.x默认kafka的版本是1.0.0,而5.6.x默认的是0.8.2.0,而询问运维得知kafka版本是0.10.2.2,所以问题基本确认。
根据官方文档描述,在配置中指定了kafka版本:
问题得以解决。
0x02 总结
查看kafka版本,https://blog.csdn.net/wuzhuge1990/article/details/80733622