推送,并不保证可靠。Kafka保证可靠但有点延时
数据堆积:Redis 队列容量取决于机器内存大小,如果超过设置的Max memory,数据就会抛弃。Kafka 的堆积能力取决于机器硬盘大小。
综合上述的理由,我们决定采用 Kafka 来缓冲队列。不过在这种架构下仍然存在一系列问题
- Logstash shipper 收集数据同样会消耗 CPU 和内存资源
- 不支持多机房部署
这种架构适合较大集群的应用部署,通过消息队列解决了消息丢失、网络堵塞的问题。
多机房部署
随着沪江业务的飞速增长,单机房的架构已经不能满足需求。不可避免的,沪江的业务需要分布到不同机房中,对于日志服务来说也是不小的挑战。当然业界也有不少成熟的方法,比如阿里的单元化、腾讯的 SET 方案等等。单元化在这边不详细展开,大家可以参考微博的【单元化架构】
最终我们决定采用单元化部署的方式来解决 ELK 多机房中遇到的问题(延时、专线流量过大等),从日志的产生、收集、传输、存储、展示都是在同机房里面闭环消化,不存在跨机房传输与调用的问题。因为交互紧密的应用尽量部署在同机房,所以这种方案并不会给业务查询造成困扰。
Logstash、Elasticsearch、Kafka、Kibana 四个集群都部署到同一机房中,每个机房都要每个机房自己的日志服务集群,比如A机房业务的日志只能传输给本机房 Kafka ,而A机房 Indexer 集群消费并写入到A机房 Elasticsearch 集群中,并由A机房 Kibana 集群展示,中间任何一个步骤不依赖B机房任何服务。
引入Filebeat
Filebeat 是基于原先 logstash-forwarder 的源码改造出来的,无需依赖 Java 环境就能运行,安装包10M不到。
如果日志的量很大,Logstash 会遇到资源占用高的问题,为解决这个问题,我们引入了Filebeat。Filebeat 是基于 logstash-forwarder 的源码改造而成,用 Golang 编写,无需依赖 Java 环境,效率高,占用内存和 CPU 比较少,非常适合作为 Agent 跑在服务器上。
下面看看Filebeat的基本用法。编写配置文件,从 Nginx access.log 中解析日志数据
# filebeat.yml
filebeat.prospectors:
- input_type: log
paths: /var/log/nginx/access.log
json.message_key:
output.elasticsearch:
hosts: ["localhost"]
index: "filebeat-nginx-%{+yyyy.MM.dd}"
我们来看看压测数据
压测环境
- 虚拟机 8 cores 64G内存 540G SATA盘
- Logstash 版本 2.3.1
- Filebeat 版本 5.5.0
压测方案
Logstash / Filebeat 读取 350W 条日志 到 console,单行数据 580B,8个进程写入采集文件
压测结果
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 (http://grokdebug.herokuapp.com/) 来调试正则。
总结
基于 ELK stack 的日志解决方案的优势主要体现于
- 可扩展性:采用高可扩展性的分布式系统架构设计,可以支持每日 TB 级别的新增数据。
- 使用简单:通过用户图形界面实现各种统计分析功能,简单易用,上手快
- 快速响应:从日志产生到查询可见,能达到秒级完成数据的采集、处理和搜索统计。
- 界面炫丽:Kibana 界面上,只需要点击鼠标,就可以完成搜索、聚合功能,生成炫丽的仪表板
参考资料
- https://www.elastic.co/guide/en/beats/filebeat/1.3/filebeat-overview.html
- https://zhuanlan.zhihu.com/p/26399963