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 界面上,只需要点击鼠标,就可以完成搜索、聚合功能,生成炫丽的仪表板
参考资料https://www.elastic.co/guide/en/beats/filebeat/1.3/filebeat-overview.html
https://zhuanlan.zhihu.com/p/26399963