标签:查看 doc article 循环 等等 stash event对象 原因 group
一、概述
在笔者的上一篇博客介绍了Spring Cloud ELK+kafka日志分析平台的搭建,http://xuyangyang.club/articles/2018/05/24/1527176074152.html,但是笔者在测试环境中发现,在logstash采用了grok插件去处理日志埋点和解析的时候发现了高资源占用,在阿里云8核16G的服务器部署后,测试环境大概每秒不超过几百条的日志的解析下竟然CPU占用高达95%左右,笔者分析了其中的原因,首先由于几个服务的日志格式相关配置还没有落地导致了日志格式无法解析和解析慢,其次grok天生解析正则表达式非常耗CPU。在笔者分析原因后立马进行了改造,将无法解析的格式不做任何处理直接输出到elasticsearch,另外多起了同一个group的基于kafka的logstash去消费日志,发现CPU占用虽然降低了,但任然在高达70%的CPU占用,这使得笔者不得不放弃原先的logstash插件grok,采用了ruby来解析日志和处理日志埋点,并且这次同时对docker启动shell脚本做相应修改,原先由于书写filter导致脚本杂乱无法查看改为启动传入配置文件的方式。
二、改造logstash
本次主要的问题主要发生在logstash的grok插件,在笔者查阅相关资料中发现,logstash提供了grok、mutate、ruby、json等等多种filter插件,由于我们的日志非表中的json格式,所以放弃了测试json插件,而笔者在ruby插件的介绍中发现官方对其颇为称赞,它支持ruby语法,对一些字符串、循环、判断能更方便,并且可以操作event对象(其实就是logstash对象),所以笔者采用了ruby插件。以下为笔者所写的logstash配置文件示例:
性能优化分析Spring Cloud ELK+kafka日志分析平台
标签:查看 doc article 循环 等等 stash event对象 原因 group
原文地址:https://www.cnblogs.com/java8899/p/11755985.html