fluent-bit升级v1.2的漫漫长路

最新推荐文章于 2024-09-08 11:53:26 发布

hui_tony

最新推荐文章于 2024-09-08 11:53:26 发布

阅读量460

点赞数

文章标签：经验分享 elk

本文链接：https://blog.csdn.net/fei243660702/article/details/120044779

版权

随着业务增长，日志量激增导致fluent-bit与fluentd之间的堆积问题。本文分享了从v1.2升级fluent-bit的历程，包括尝试使用新特性`Ignore_Older`失败，解决编译环境问题，以及最终成功升级并测试功能的完整过程。

摘要由CSDN通过智能技术生成

背景

本文涉及的日志系统是文章《dapeng日志的收集处理及查询应用》中详细描述的以fluent-bit => fluentd => kafka => fluentd => elasticsearch为结构的日志系统。如果有兴趣可以详细的了解下。

由于公司现有服务逐步增加，现有日志量相比之前已经有了成倍的增加。近期，运维小伙伴反应线上服务器的磁盘空间消耗突然增加，达到预警值（90%）。经过排查发现，是因为业务量的增加导致日志量激增，而由于fluentd的处理能力有限，没有及时将fluent-bit收集的日志发送到kafka，导致日志堆积和日志的告警延迟。

为了解决日志堆积问题，我们提出了两种解决方案：

- 第一种是增加fluentd节点，通过多进程来同时处理fluent-bit收集的日志，但是这个方案会带来另一个问题，就是cpu的开销会增加，在线上已经存在很多fluentd线程的情况下，该方案并不是适用。
- 第二种就是剔除掉fluentd对日志的转发，直接通过fluent-bit向kafka发送日志消息。该方案依赖kafka强大的处理能力，剔除掉fluentd，不仅可以解决日志堆积问题，还可以减小cpu消耗，同时因为环节的减少，日志将会更加实时。因此该方案就成了我们的选择。

因为我们使用的fluent-bit版本太低，并不支持kafka-plugin。因此需要对fluent-bit进行升级，这次我们直接升级到最新的稳定版本v1.2。这篇文章记录的就是在升级过程中的踩过的坑。