糟糕的 filebeat

因为公司的服务器和日志所在的kafka集群不是在一个网络下，导致服务器到kafka之间日志传输率受带宽的限制，高峰期一直把带宽跑满，最近花了挺长时间来解决这个问题。

问题

遇到带宽跑满时，大概率就知道是压缩有问题。我们的filebeat采用了snappy压缩算法，这算法压缩率确实感人，单机发往kafka集群的流量在3Mb/s左右。

第一次尝试解决问题

看到snappy压缩这么感人，果断立马用了gzip，压缩效果立马就体现出来了，单机发往kafka集群的流量在1.5Mb/s左右。但是又遇到了一个无法接受的问题，filebeat客户端cpu使用率有点高，2c机器大概在30%上下。(ps: lz4的流量也不能接受)

第二次尝试解决问题

在尝试了调各种参数无法解决问题后，只能尝试改代码了。。

说实话，我以前没有写过go代码，第一次上手真的是晕，全程面向搜索引擎编程。

因为我们只需要把数据发到kafka，所以需要做的就只是改filebeat kafka output部分的逻辑。

查问题

为什么filebeat发到kafka的cpu使用这么高，在对代码一顿研究之后，发现filebeat发到kafka是一行日志发一条消息，然后kafka producer针对每条消息，做gzip压缩。

filebeat在采集日志时，会把一批日志构建一个batch，然后在协程里把batch的每条日志作为一个kafka record发到kafka。

解决思路

既然filebeat在采集时已经构建了一个batch，为啥还要再把batch单条发送，直接把batch自己用gzip压缩一发不就完了嘛，然后把这批压缩后的batch作为一条kafkfa消息发给集群就行了(kafka producer的压缩策略配置为none)。

然后花了挺久的时间改代码，改完后测试了一发，流量比默认的gzip压缩还小，cpu比默认的gzip也有所降低，大概低了5-8%之间。

总结

说实话没啥好总结的，改fb的代码真是头疼。。。还是写flink开心多了，哈哈哈哈哈。