我们的日志收集系统使用的是Fluentd,使用Fluentd的原因大概是因为配置简单、插件比较多、而且能够比较容易的定制自己的插件。但是随着日志越来越多以后,Fluentd会出现性能上的问题,以下的文章将回顾我们进行Fluentd性能优化的操作。

Fluentd 性能问题的主要原因?

抛开自己配置错误的一些原因,Fluentd性能问题的最主要原因是因为Fluentd是使用Ruby写的,而Ruby有全局锁(GIL),因而在一个Ruby进程里面同时最多只有一个线程在运行。这样的话,Ruby的多线程对需要更多计算资源的操作显得无能为力,具体的体现可以用top查看进程的运行情况,如果Fluentd到达性能瓶颈的话,Fluentd的进程会一直占用100%左右的计算资源,再也不能提升,对于有四个核的计算机来说,最多也就使用的1/4的计算能力,这是极其浪费的。而且当Fluentd进程到达瓶颈后,数据会处理不完,导致数据收集的速度落后于数据产生的速度。

Fluentd 多进程优化一

既然已经知道了Fluentd性能瓶颈的问题主要是因为单进程不能使用多核的计算能力,那解决的方法也是很简单的,可以把收集的日志按照不同的类型来拆分成不同的进程,这样就能充分的利用多核的计算能力了。

多进程架构
Fluentd多进程架构一
Fluentd多进程架构一

如上图所示,之前单进程的架构可以改成如上的多进程架构,这样每个进程最多可以使用100%的cpu资源,理论上四核的机器起四个Fluentd进程就可以充分的利用机器的计算资源的了,但是实际上这个架构还有一些问题未能解决。

主要问题

这个多进程的架构相比于单进程的架构在性能上已经有很大的提升了,不过还有如下两个问题:

  1. 该架构要求Log的拆分要比较均衡,这样每个进程都能合理的利用计算资源,不然会出现有些进程非常繁忙,但是有些进程却非常的空闲。然而Log的拆分是按照之前的经验来拆分的,不可能做到绝对的均衡,而且拆分完后是直接写到配置文件里面的,也不能进行实时调整。
  2. 即使是按照现在的架构进行日志拆分了,但是有些日志的计算任务比较繁重,有可能导致即使一个进程只处理一个类型的Log也会到达性能瓶颈。如上图的Process3只处理Log5,但是在top中却看到Process3的cpu使用率一直是100%,这说明Process3已经到达了性能瓶颈,但是Log5已经不能再进行拆分了。

基于上面的这两个问题,这种多进程架构还是会遇到性能瓶颈,因此需要对架构再继续进行优化,接下来介绍新的架构来优化Fluentd的性能。

Fluentd 多进程优化二

上面的日志拆分架构其实在我们的系统中已经用过了一段时间了,但是我们发现有些Fluentd进程一直很繁忙,我们本来是想着怎么把日志拆分的更加均衡一些,但是无意中在Fluentd官网中看到了他们推荐的架构,觉得这才是真正正确的做法,之前走的是弯路。

新的多进程架构
Fluentd多进程架构二
Fluentd多进程架构二

这是Fluentd官网给出的多进程架构图,该架构采用两层的结构,前面的一层只负责数据的路由,把数据按照一定的比例路由到第二层,然后第二层才对数据进行处理。第二层可以根据机器的资源起不同个数的进程,甚至可以把第二层部署到不同的机器上去。这样就能解决旧的架构的分配不均和计算瓶颈的问题了,每种日志都能很均衡的使用机器的计算资源,甚至可以分布式扩展。同时也不用苦恼于怎么拆分Log来让进程的计算资源更加的均衡。

注意事项

新的架构虽然在理论上是非常好的架构,但是在配置的过程中需要注意一些问题:

  1. 新架构第一层使用的是forward插件把log路由到第二层的,需要注意的是forward的插件也是需要把buffer_type配置成文件的,不然如果第二层的处理能力不够的话,就会导致第一层的buffer数据一直堆在内存里面,导致内存不够。还会造成在停Fluentd进程的时候,如果是第二层进程先停的话,那么第一层的数据会不能发送的到第二层,第一层的进程会一直停不掉。如果机器不小心关掉的话,还会造成数据丢失。
  2. 新架构第一层的flush_interval(推荐1秒)和buffer_chunk_size(推荐1M)要配置的尽量小,这样数据才能尽快的发送到第二层进行处理。其实如果配置的比较大的话,到时候第二层会有报警的。
  3. 新架构的缺点是同一种Log会有多个处理进程,这样的话就会导致一些只能单进程处理的操作变得不那么优美了。比如webhdfs插件,现在使用新的多进程架构后,因为每个hdfs文件只能由一个进程写入,所以现在同一种Log是由多个进程写入的,只能写入到多个不同的文件,这样会造成hdfs文件数量成倍的增加。

总结

通过这次架构的升级,Fluentd的性能已经得到了很大的提升,而且配置也变得更加简单了,好的架构往往能够事半功倍。