高峰只对攀登它而不是仰望它的人来说才有真正意义。

亿级日志收集,filebeat能否支撑!

Beats | 作者 zriplj | 发布于2021年06月15日 | 阅读数:2645

架构:filebeat-->kafka-->logstash-->es
filebeat版本,7.4.2
背景:
服务器日志每2小时切割,2小时日志量在60-70G。一共有40台机器接入。
之前采用每台机器安装filebeat收集,因为担心影响业务,所以限制filebeat CPU为2C,发现无法及时收全日志,导致日志丢失。
现采用共享磁盘的方案,把40台机器的日志统一收集以主机名称目录存到共享磁盘中,然后创建新机器专门安装filebeat来收集,filebeat不限制CPU核心
创建机器的配置:8C16g
问题1,filebeat也无法把所有40台主机日志收集进来。
问题2,filebeat paths二台主机目录的日志,8C的CPU只能利用到400%的资源。                                                                                                     
PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND 
3977 root 20 0 1485604 119304 19928 S 410.7 0.7 262:33.90 filebeat
问题3,有什么方案可以收集这40台的日志呢?
 
 
已邀请:

zriplj

赞同来自:

问题4,filebeat写入kafka,应该使用哪种压缩算法呢?gzip/lz4/snappy?
现已把机器配置升级到16C32G,filebeat采用多进程,每个进程跑1台机器的日志,开启1个filebeat进程时CPU使用率在1000%左右,开启2个进程CPU资源如下:
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                 
15269 root 20 0 2092436 367788 19780 R 599.7 1.1 218:17.92 filebeat
15268 root 20 0 2223508 369560 19760 S 589.0 1.1 219:08.92 filebeat

zqc0512 - andy zhou

赞同来自:

你入库的是不是有很多自定义处理的,这个会慢,可以从kafka出来的时候做处理。

要回复问题请先登录注册