本文主要是介绍糟糕的 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开心多了，哈哈哈哈哈。
这篇关于糟糕的 filebeat的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
