经反馈，新部署的服务器上filebeat占用的cpu过高，且内存只增不减。
而据我了解filebeat非常轻量级，正常情况下占用的资源几乎都能忽略不计，所以怀疑是filebeat本身出了问题。
第一时间查看filebeat日志（默认路径/var/log/filebeat/filebeat），发现有大量内容输出：
--20T08::02.198+ INFO kafka/log.go: producer/broker/ starting up
--20T08::02.198+ INFO kafka/log.go: producer/broker/ state change to [open] on wp-news-filebeat/
--20T08::02.198+ INFO kafka/log.go: producer/leader/wp-news-filebeat/ selected broker
--20T08::02.198+ INFO kafka/log.go: producer/broker/ state change to [closing] because EOF
--20T08::02.199+ INFO kafka/log.go: Closed connection to broker bitar1d12:
--20T08::02.199+ INFO kafka/log.go: producer/leader/wp-news-filebeat/ state change to [retrying-]
--20T08::02.199+ INFO kafka/log.go: producer/leader/wp-news-filebeat/ state change to [flushing-]
--20T08::02.199+ INFO kafka/log.go: producer/leader/wp-news-filebeat/ abandoning broker
--20T08::02.199+ INFO kafka/log.go: producer/leader/wp-news-filebeat/ state change to [retrying-]
--20T08::02.199+ INFO kafka/log.go: producer/leader/wp-news-filebeat/ abandoning broker
--20T08::02.199+ INFO kafka/log.go: producer/leader/wp-news-filebeat/ state change to [retrying-]
--20T08::02.199+ INFO kafka/log.go: producer/broker/ 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