记Filebeat系统资源使用优化

Posted 2023-04-07

参考技术A 本文重点：

本文将着重关注filebeat，在filebeat在生产部署后，必定会对服务CPU、内存、网络有影响，如果将这些因素都在可控范围内，那是完全可以接受的。但是可能由于我们的配置不合理，或者非预期的情况导致CPU、内存占用过大，势必会影响到同在一起的业务应用稳定性。

我们将在本文一步步介绍我们在使用过程中遇到的问题，配置的优化，如何确保filebeat部署在业务主机上对业务的影响降到最低，如何使用cgroup来限制filebeat的系统资源使用配额！

有些文章说filebeat的内存消耗很少，不会超过100M，这是没有针对场景和没有经过测试不严谨的说法(刚开始我们也没有完全覆盖所有情况进行测试，当然部分偶然情况有时无法预知)，当真正按照默认的简单配置将filebeat部署到生产环境，或者某个参数配置错误，都可能会出现意想不到的问题，轻则影响服务的整体性能，重则可能造成应用被OOM-killer导致业务中断。我们在刚开始使用filebeat时，觉得这个组件已经如此成熟，应该问题不大。所以使用了最简单最基本的配置将其部署，为后来的问题埋下了祸根！

我们在实际使用中的确遇到了如下问题:

来看几个问题样本:

这是初版的配置文件，相对简单，基本没有做什么特殊的配置:

我们接收业务反馈CPU占据到了300%上下(四核)，并且偶现开头出现的OOM现象。

经过文档的查阅，发现几个明显的配置问题，并针对其做过一次初步的优化

初步调整:

上面的改动，以为已经控制住问题，但是在不久之后还是反复出现了多次同样的OOM问题

filebeat限制单条消息最大不能超过20k，默认内存队列存储4096条记录，再加上明文日志，最高内存理论最高值在 20k * 4096 * 2 = 160M 左右浮动，即使做了以上限制，还是不时出现内存爆增的情况

一时没有找到问题解决方案，我们做了如下的几个阶段策略:

阶段一：降低非预期情况下对应用的影响

阶段二：重新梳理和优化配置，达到优化内存的目的

降低非预期情况下对应用的影响，是将filebeat进程的oom_score_adj值设置为999，在出现意外情况时OOM也优先 kill 掉filebeat，从而达到即使出现意外情况，也不会影响到业务进程

具体的操作是：

启动filebeat -> 获取进程PID -> 写入/proc/$pid/oom_score_adj 为999

针对多次问题的场景，进行样本的提取，发现多次问题出现的都是在大量的堆栈异常日志中出现，怀疑是多行合逻辑不对导致的问题：

下面我们来着重看一下多行最初配置：

发现官网对于此参数的默认值是5s，但是现在却被误配置成了30s，肯定是有问题的啦

问题的原因应该就在 multiline.timeout 这个参数之上，我们尝试调整多次参数的大小进行测试:

我的对官方的这句话的理解是:

如果日志中如果包含很多错误堆栈，或者不规范的日志大量匹配多行逻辑，会产生过多的多行合并任务，但是超时时间过长，过多的任务就会最大限度的匹配和在内存中等待，占用更多的内存！

除此以外我们也做了其他调整包括但不限于如下:

queue.mem.events :从默认的4096 设置到了2048

queue.mem.flush.min_events : 从默认2048设置到了1536

multiline.max_lines :从默认500行设置到了200行

最后我们的最优配置如下，在调整之后将问题样本进行测试，内存只占用350M～500M之间：

对于我们的业务机器来说，让filebeat独占一个CPU去进行日志收集，显然不被业务人员所接受，因为在业务高峰期日志量会很大，filebaat进行大吞吐量的日志收集、多行合并、消息发送；很有可能会限制业务的性能，可能没有filebeat我原本需要10台主机，但是有了filebeat我就需要15台主机来承载高峰业务。

上面的配置虽然已经基本控制住内存用量，但也有可能出现不同的不可预期的情况导致内存增长

我们该如何限制CPU使用量和应对意想不到的内存增长情况？

答案是：绝对性的控制CPU/内存在一个范围内，我们可以使用cgroup来实现

什么是cgroup？

cgroup相关的所有操作都是基于内核中的cgroup virtual filesystem，使用cgroup很简单，挂载这个文件系统即可。一般情况默认已经挂载到 /sys/fs/cgroup 目录下了

mount | grep cgroup 查看系统默认是否挂载cgroup，cgroup包含很多子系统，用来控制进程不同的资源使用，我们只用其中cpu和memory这两个

filebeat_cpu和filebeat_memory下都会自动生成与上级目录相同的文件，我们重点关注一下几个文件

改造我们的filebeat启动脚本,支持在启动后限制内存和cpu:

限制:

CPU -> 单核25%

内存 -> 500M,大于此值则触发cgroup的OOM-killer机制

优化前：

优化后:

总结filebeat进程写满磁盘的情况处理

采用filebeat收集日志，日志文件频繁rotate，造成filebeat占用文件不释放，只要filebeat保持着被删除文件Open状态，操作系统就不释放磁盘空间，导致可用磁盘空间逐渐减小。

使用lsof命令查看filebeat保持着的文件资源，可以发现许多被filebeat占用空间的失效文件（deleted）文件。

deleted状态的文件没有释放，始终占据磁盘空间

解决办法：

查看filebeat配置文件位置： /etc/filebeat/filebeat.yml

在配置文件中添加close_timeout： 5m，保证每隔5分钟file handler被关闭，不管是否遇到EOF符号。

需要注意的是，该close_timeout参数在Filebeat没有处理到文件末尾而文件被删除的情况下，会导致数据丢失。

filebeat.prospectors:
- type: log
?? paths:
??? - /opt/apps/ecm/service/storm/1.0.1/package/apache-storm-1.0.1/logs/workers-artifacts/xyz*/*/worker.log
?? tail_files: false
?? force_close_files: true
?? close_timeout: 5m
processors:
- add_cloud_metadata: ~
output.logstash:
?? hosts: ["10.109.3.193:6667"]
?? loadbalance: true
?? worker: 1