經反饋，新部署的服務器上filebeat佔用的cpu太高，且內存只增不減。html
而據我瞭解filebeat很是輕量級，正常狀況下佔用的資源幾乎都能忽略不計，因此懷疑是filebeat自己出了問題。java
第一時間查看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
看日誌描述，彷佛是一直地在不停的建立和關閉kafka鏈接。運維
起初懷疑是kafka相關dns沒有配置（/etc/resolve.conf）致使連不上kafka的broker，但檢查並和正常的機器對比後，dns配置是同樣的，也就排除了這種狀況。ide
接下來懷疑多是filebeat版本的問題，由於elastic家族的產品就是那個尿性，發版速度很頻繁，並且不一樣大版本有不少不兼容。ui
對比filebeat版本，發現它的版本（6.5.3）比正常的服務器（5.6.12）高一個大版本，因此懷疑不一樣版本對kafka的處理機制不同致使的。spa
爲了驗證這個問題，在查閱filebeat官網後發現，6.5.x默認kafka的版本是1.0.0，而5.6.x默認的是0.8.2.0，而詢問運維得知kafka版本是0.10.2.2，因此問題基本確認。日誌
根據官方文檔描述，在配置中指定了kafka版本：code
output.kafka:
version: 0.10.2.2
...htm
問題得以解決。
參考
https://www.elastic.co/guide/en/beats/filebeat/6.5/kafka-output.html#_literal_version_literal
https://www.elastic.co/guide/en/beats/filebeat/5.6/kafka-output.html#_version