背景
本文涉及的日志系统是文章《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。这篇文章记录的就是在升级过程中的踩过的坑。
漫漫升级之路
空欢喜
文章《dapeng日志的收集处理及查询应用》中提到过，我们对原生的fluent-bit进行过优化，其中一项就是添加了db_count字段来控制向写文件偏移量offset的频率。在升级v1.2的过程中，在tail插件的文档中，我们发现了一个新的字段Ignore_Older，如下图所示。
Ignore_Older.png
文档的描述表明，该字段可以控制fluent-bit只读取近期（m,h,d时间自定义）修改过的文件。我们希望在新版本使用该字段来替换掉db_count，如此我们就不需要在修改源码，升级会更方便。
但是本地测试后，大失所望。定义了仍会读取所有的文件，通过查询github上的issues发现，如下图所示：
Ignore_Older_issues.png
原作者表示该字段生效需要配置Parser，同时该字段时基于记录的，而不是基于文件的。至此，空欢喜一场，还是老老实实改源码吧。
痛苦的环境
Round 1
在升级之前，心想就是改好源码，然后按照Quick Start所示命令（如下）一顿操作即可。但是事实并非如此。
$ cd build
$ cmake ..
$ make
$ bin/fluent-bit -i cpu -o stdout
改好源码后，按照如上操作会出现如下的错误提示：
fluent-bit-err.png
会提示没有相应的插件FLEX，在安装了相应的插件（还有bison插件）之后，再次编译。仍然会出现如下错误提示：
fluent-bit-err2.png
现在的我是一脸懵逼，完全不知道什么原因（有哪位了解的大神可以解答下么）。
Round 2
通过上述命令不成功之后，我们尝试使用Dockerfile文件进行编译，打成镜像。首次运行，会因为Dockerfile文件的第56行如下所示，而无法获取到资源而失败。
FROM gcr.io/distroless/cc
通过对Dockerfile文件的分析，我们发现文件的第56行之后的命令并不会对产生fluent-bit的可执行文件构成影响，可以满足我们的需求，所以我们将这些命令进行了屏蔽，重试构建惊醒。这次居然成功了，异常兴奋:)。
但是高兴还是很太早，我们发现通过Dockerfile构建的镜像非常大，更重要的是我们将镜像里面的fluent-bit可执行文件cp到我们的服务镜像里面，仍然不可用。心情down到底。
Round 3
我们又回到Round 1中关于flex等插件的问题中来，试图找到原因。我们在fluent-bit文档中发现如下的说明:
fluent-bit-requirements.png
Flex和Bison插件仅仅只在开启了Stream Processor的时候需要，为此，我们尝试将Stream Processor关闭在进行编译，修改CMakeLists.text文件:
option(FLB_STREAM_PROCESSOR "Enable Stream Processor" No)
果然，如预期的一样，这次编译成功了！吸取前几次教训，这次不能太早高兴。果不其然，这次编译得到的fluent-bit可执行文件并不支持kafka插件，我*哦。
Round 4
告诉自己淡定淡定，问题还得解决。我们再次回到Dockerfile文件，仔细分析下。我们尝试用如下的命令进行编译：
cmake -DFLB_DEBUG=Off \
-DFLB_TRACE=Off \
-DFLB_JEMALLOC=On \
-DFLB_BUFFERING=On \
-DFLB_TLS=On \
-DFLB_SHARED_LIB=Off \
-DFLB_EXAMPLES=Off \
-DFLB_HTTP_SERVER=On \
-DFLB_IN_SYSTEMD=On \
-DFLB_OUT_KAFKA=On ..
这次打算趁环境不注意，悄悄编译。。。。。我*，居然成功了。再进行make命令。欧耶，又成功，看来离成功不远了。最后将fluent-bit可执行文件cp到我们服务的容器里面，执行了如下命令：
./fluent-bit -i cpu -o kafka -p Brokers=192.168.*.*:9092 -p Topics=****
得到如下界面：
fluent-bit-success.png
只想说一句：终于成功了！
最后我们还测试了我们添加的功能，最后都升级成功，升级不易。
总结
通过正常的Quick Start应该是可以成功的，因为我们环境的原因最终没有成功（有了解的大神可以成功解决否？）但是通过不断的尝试，最后找到折中的方法，也是不错的。过程比较曲折，结果还算满意！我们使用fluent-bit工具用于基于dapeng-soa架构的服务日志的收集。有兴趣的朋友可以通过dapeng文档了解我们的高可用的微服务架构。
网友评论