經反饋，新部署的服務器上filebeat占用的cpu過高，且內存只增不減。
而據我了解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
看日志描述，似乎是一直地在不停的創建和關閉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版本：
output.kafka:
version: 0.10.2.2
...
問題得以解決。
參考
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