K8S/Kubernetes

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