0x00 概述
filebeat非常輕量級，正常情況下占用的資源幾乎都能忽略不計，是以懷疑是filebeat本身出了問題。
第一時間檢視filebeat日志（預設路徑/var/log/filebeat/filebeat），發現有大量内容輸出：
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