从ELK到EFK演进 (3)

Logstash / Filebeat 读取 350W 条日志 到 console,单行数据 580B,8个进程写入采集文件

压测结果 项目workerscpu usr总共耗时收集速度
Logstash   8   53.7%   210s   1.6w line/s  
Filebeat   8   38.0%   30s   11w line/s  

Filebeat 所消耗的CPU只有 Logstash 的70%,但收集速度为 Logstash 的7倍。从我们的应用实践来看,Filebeat 确实用较低的成本和稳定的服务质量,解决了 Logstash 的资源消耗问题。

最后,分享给大家一些血泪教训,希望大家以我为鉴。

1. Indexer 运行一段时间后自动挂掉

突然有一天监控发现日志不消费了,排查下来发现消费Kafka数据的indexer 挂掉了。所以,Indexer 进程也是需要用 supervisor 来监控的,保证它时刻都在运行。

2. Java异常日志输出

开始我们在通过 grok 切割日志的时候,发现Java 的 Exception 日志输出之后,会出现换行的问题。后来使用 Logstash codec/multiline 插件来解决。

input { stdin { codec => multiline { pattern => "^\[" negate => true what => "previous" } } } 3. 由于时区导致日志8小时时差

Logstash 2.3版本 date插件配置如下,查看解析结果发现@timestamp比中国时间早了8小时。

解决方案 Kibana 读取浏览器的当前时区,然后在页面上转换时间内容的显示。

date { match => [ "log_timestamp", "YYYY-MM-dd HH:mm:ss.SSS" ] target => "@timestamp" } 4.Grok parse failure

我们遇到线上node日志突然有几天日志查看不出来。后来拉出原始日志对比才发现生成出来的日志格式不正确,同时包含 JSON 格式和非 JSON格式的日志。但是我们用grok解析的时候采用是json格式。建议大家输出日志保证格式一致同时不要出现空格等异常字符,可以使用在线grok debug () 来调试正则。

总结

基于 ELK stack 的日志解决方案的优势主要体现于

可扩展性:采用高可扩展性的分布式系统架构设计,可以支持每日 TB 级别的新增数据。

使用简单:通过用户图形界面实现各种统计分析功能,简单易用,上手快

快速响应:从日志产生到查询可见,能达到秒级完成数据的采集、处理和搜索统计。

界面炫丽:Kibana 界面上,只需要点击鼠标,就可以完成搜索、聚合功能,生成炫丽的仪表板

从ELK到EFK演进

参考资料

https://www.elastic.co/guide/en/beats/filebeat/1.3/filebeat-overview.html

https://zhuanlan.zhihu.com/p/26399963

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zzpfyj.html