原文作者:EdisonZhou
原文链接:https://developer.aliyun.com/article/727997
监控和日志历来都是系统稳定运行和问题排查的关键,在微服务架构中,数量众多的容器以及快速变化的特性使得一套集中式的日志管理系统变成了生产环境中一个不可获取的部分。此次话题我们会集中在日志管理方面,本篇会介绍 Docker 自带的 logs 子命令以及其 Logging driver,然后介绍一个流行的开源日志管理方案 ELK/EFK。
一、Docker logs 子命令
默认情况下,Docker 的日志会发送到容器的标准输出设备(STDOUT)和标准错误设备(STDERR),其中 STDOUT 和 STDERR 实际上就是容器的控制台终端。
我们可以通过 logs 子命令来查看具体某个容器的日志输出:
docker logs edc-k8s-demo
这时看到的日志是静态的,截止到目前为止的日志。如果想要持续看到新打印出的日志信息,那么可以加上 -f 参数,如:
docker logs -f edc-k8s-demo
二、Docker logging driver
刚刚我们学习了默认配置下,Docker 日志会发送到 STDOUT 和 STDERR。但实际上,Docker 还提供了其他的一些机制允许我们从运行的容器中提取日志,这些机制统称为 logging driver。
对 Docker 而言,其默认的 logging driver 是 json-file,如果在启动时没有特别指定,都会使用这个默认的 logging driver。
json-file 会将我们在控制台通过 docker logs 命名看到的日志都保存在一个json文件中,我们可以在服务器Host上的容器目录中找到这个 json 文件。
容器日志路径:/var/lib/docker/containers/<container-id>/<container-id>-json.log
例如我们可以查看一个 exceptionless-api 容器的 json 日志:
一个快速查看某个容器的日志文件路径的方法:
docker inspect exceptionless_api_1
通过 inspect 命令,可以查到该容器的 ID 及一系列配置信息,我们重点关注 LogPath 即可:
查到 LogPath 后,即可复制其后面的日志路径了,打开这个 json 文件你就可以看到输出的容器日志了。
除了 json-file,Docker 还支持以下多种 logging dirver,来源:Configure logging drivers
其中,none 代表禁用容器日志,不会输出任何容器日志。
其他几个logging driver解释如下:
- syslog 与 journald 是Linux上的两种日志管理服务
- awslog、splunk 与 gcplogs是第三方日志托管服务
- gelf 与 fluentd 是两种开源的日志管理方案
我们可以在容器启动时通过加上 --log-driver 来指定使用哪个具体的 logging driver,例如:
docker run -d --log-driver=syslog ......
如果想要设置默认的logging driver,那么则需要修改Docker daemon的启动脚本,例如:
{
"log-driver": "json-file",
"log-opts": {
"labels": "production_status",
"env": "os,customer"
}
}
每个logging driver都有一些自己特定的log-opt,使用时可以参考具体官方文档。
三、关于ELK
3.1 ELK简介
ELK 是Elastic公司提供的一套完整的日志收集以及展示的解决方案,是三个产品的首字母缩写,分别是ElasticSearch、Logstash 和 Kibana。
Elasticsearch 是实时全文搜索和分析引擎,提供搜集、分析、存储数据三大功能
Logstash 是一个用来搜集、分析、过滤日志的工具
Kibana 是一个基于 Web 的图形界面,用于搜索、分析和可视化存储在 Elasticsearch 指标中的日志数据
3.2 ELK 日志处理流程
上图展示了在 Docker 环境下,一个典型的 ELK 方案下的日志收集处理流程:
- Logstash 从各个 Docker 容器中提取日志信息
- Logstash 将日志转发到 ElasticSearch 进行索引和保存
- Kibana 负责分析和可视化日志信息
由于 Logstash 在数据收集上并不出色,而且作为 Agent,其性能并不达标。基于此,Elastic 发布了 beats 系列轻量级采集组件。
这里我们要实践的 Beat 组件是 Filebeat,Filebeat 是构建于 beats 之上的,应用于日志收集场景的实现,用来替代 Logstash Forwarder 的下一代 Logstash 收集器,是为了更快速稳定轻量低耗地进行收集工作,它可以很方便地与 Logstash 还有直接与 Elasticsearch 进行对接。
本次实验直接使用Filebeat作为Agent,它会收集我们在第一篇《Docker logs & logging driver》中介绍的json-file的log文件中的记录变动,并直接将日志发给ElasticSearch进行索引和保存,其处理流程变为下图,你也可以认为它可以称作 EFK。
四、ELK套件的安装
本次实验我们采用 Docker 方式部署一个最小规模的 ELK 运行环境,当然,实际环境中我们或许需要考虑高可用和负载均衡。
首先拉取一下 sebp/elk 这个集成镜像,这里选择的 tag 版本是 640(最新版本已经是 7XX 了):
docker pull sebp/elk:640
注:由于其包含了整个 ELK 方案,所以需要耐心等待一会。
通过以下命令使用 sebp/elk 这个集成镜像启动运行 ELK:
docker run -it -d --name elk \
-p 5601:5601 \
-p 9200:9200 \
-p 5044:5044 \
sebp/elk:640
运行完成之后就可以先访问一下 http://[Your-HostIP]:5601 看看Kibana的效果:
Kibana管理界面
Kibana Index Patterns界面
当然,目前没有任何可以显示的ES的索引和数据,再访问一下http://[Your-HostIP]:9200 看看ElasticSearch的API接口是否可用:
ElasticSearch API
_Note:_如果启动过程中发现一些错误,导致ELK容器无法启动,可以参考《Docker启动ElasticSearch报错》及《ElasticSearch启动常见错误》一文。如果你的主机内存低于4G,建议增加配置设置ES内存使用大小,以免启动不了。例如下面增加的配置,限制ES内存使用最大为1G:
docker run -it -d --name elk \
-p 5601:5601 \
-p 9200:9200 \
-p 5044:5044 \
-e ES_MIN_MEM=512m \
-e ES_MAX_MEM=1024m \
sebp/elk:640
五、Filebeat配置
5.1 安装Filebeat
这里我们通过rpm的方式下载Filebeat,注意这里下载和我们ELK对应的版本(ELK是6.4.0,这里也是下载6.4.0,避免出现错误):
wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-6.4.0-x86_64.rpm
rpm -ivh filebeat-6.4.0-x86_64.rpm
5.2 配置Filebeat
这里我们需要告诉Filebeat要监控哪些日志文件 及 将日志发送到哪里去,因此我们需要修改一下Filebeat的配置:
cd /etc/filebeat
vim filebeat.yml
要修改的内容为:
(1)监控哪些日志?
filebeat.inputs:
# Each - is an input. Most options can be set at the input level, so
# you can use different inputs for various configurations.
# Below are the input specific configurations.
- type: log
# Change to true to enable this input configuration.
enabled: true
# Paths that should be crawled and fetched. Glob based paths.
paths:
- /var/lib/docker/containers/*/*.log
- /var/log/syslog
这里指定paths:/var/lib/docker/containers/_/_.log,另外需要注意的是将 enabled 设为 true。
(2)将日志发到哪里?
#-------------------------- Elasticsearch output ------------------------------
output.elasticsearch:
# Array of hosts to connect to.
hosts: ["192.168.16.190:9200"]
# Optional protocol and basic auth credentials.
#protocol: "https"
#username: "elastic"
#password: "changeme"
这里指定直接发送到ElasticSearch,配置一下ES的接口地址即可。
_Note:_如果要发到Logstash,请使用后面这段配置,将其取消注释进行相关配置即可:
#----------------------------- Logstash output --------------------------------
#output.logstash:
# The Logstash hosts
#hosts: ["localhost:5044"]
# Optional SSL. By default is off.
# List of root certificates for HTTPS server verifications
#ssl.certificate_authorities: ["/etc/pki/root/ca.pem"]
# Certificate for SSL client authentication
#ssl.certificate: "/etc/pki/client/cert.pem"
# Client Certificate Key
#ssl.key: "/etc/pki/client/cert.key"
5.3 启动 Filebeat
由于 Filebeat 在安装时已经注册为 systemd 的服务,所以只需要直接启动即可:
systemctl start filebeat.service
检查 Filebeat 启动状态:
systemctl status filebeat.service
5.4 验证 Filebeat
通过访问ElasticSearch API可以发现以下变化:ES建立了以filebeat-开头的索引,我们还能够看到其来源及具体的message。
六、Kibana 配置
接下来我们就要告诉 Kibana,要查询和分析 ElasticSearch 中的哪些日志,因此需要配置一个 Index Pattern。从 Filebeat 中我们知道 Index 是 filebeat-timestamp 这种格式,因此这里我们定义 Index Pattern 为 filebeat-*
点击 Next Step,这里我们选择 Time Filter field name 为 @timestamp:
单击 Create index pattern 按钮,即可完成配置。
这时我们单击 Kibana 左侧的 Discover 菜单,即可看到容器的日志信息啦:
仔细看看细节,我们关注一下 message 字段:
可以看到,我们重点要关注的是 message,因此我们也可以筛选一下只看这个字段的信息:
此外,Kibana 还提供了搜索关键词的日志功能,例如这里我关注一下日志中包含 unhandled exception(未处理异常)的日志信息:
这里只是朴素的展示了导入 ELK 的日志信息,实际上 ELK 还有很多很丰富的玩法,例如分析聚合、炫酷 Dashboard 等等。笔者在这里也是初步使用,就介绍到这里啦。
七、Fluentd 引入
7.1 关于 Fluentd
前面我们采用的是 Filebeat 收集 Docker 的日志信息,基于 Docker 默认的 json-file 这个 logging driver,这里我们改用 Fluentd 这个开源项目来替换 json-file 收集容器的日志。
Fluentd 是一个开源的数据收集器,专为处理数据流设计,使用 JSON 作为数据格式。它采用了插件式的架构,具有高可扩展性高可用性,同时还实现了高可靠的信息转发。Fluentd 也是云原生基金会 (CNCF) 的成员项目之一,遵循 Apache 2 License 协议,其 github 地址为:https://github.com/fluent/fluentd/。
Fluentd 与 Logstash 相比,比占用内存更少、社区更活跃,两者的对比可以参考这篇文章《Fluentd vs Logstash》。
因此,整个日志收集与处理流程变为下图,我们用 Filebeat 将 Fluentd 收集到的日志转发给 Elasticsearch。
当然,我们也可以使用 Fluentd 的插件(fluent-plugin-elasticsearch)直接将日志发送给 Elasticsearch,可以根据自己的需要替换掉 Filebeat,从而形成 Fluentd => ElasticSearch => Kibana 的架构,也称作 EFK。
7.2 运行 Fluentd
这里我们通过容器来运行一个 Fluentd 采集器:
docker run -d -p 24224:24224 -p 24224:24224/udp -v /edc/fluentd/log:/fluentd/log fluent/fluentd
默认 Fluentd 会使用 24224 端口,其日志会收集在我们映射的路径下。
此外,我们还需要修改 Filebeat 的配置文件,将 /edc/fluentd/log 加入监控目录下:
#=========================== Filebeat inputs =============================
filebeat.inputs:
# Each - is an input. Most options can be set at the input level, so
# you can use different inputs for various configurations.
# Below are the input specific configurations.
- type: log
# Change to true to enable this input configuration.
enabled: true
# Paths that should be crawled and fetched. Glob based paths.
paths:
- /edc/fluentd/log/*.log
添加监控配置之后,需要重新 restart 一下 filebeat:
systemctl restart filebeat
7.3 运行测试容器
为了验证效果,这里我们 Run 两个容器,并分别制定其 log-dirver 为 fluentd:
docker run -d \
--log-driver=fluentd \
--log-opt fluentd-address=localhost:24224 \
--log-opt tag="test-docker-A" \
busybox sh -c 'while true; do echo "This is a log message from container A"; sleep 10; done;'
docker run -d \
--log-driver=fluentd \
--log-opt fluentd-address=localhost:24224 \
--log-opt tag="test-docker-B" \
busybox sh -c 'while true; do echo "This is a log message from container B"; sleep 10; done;'
这里通过指定容器的 log-driver,以及为每个容器设立了 tag,方便我们后面验证查看日志。
7.4 验证 EFK 效果
这时再次进入 Kibana 中查看日志信息,便可以通过刚刚设置的 tag 信息筛选到刚刚添加的容器的日志信息了:
八、小结
本文从 Docker 自带的 logs 子命令入手,介绍了 Docker 具有多种 logging dirver,然后过度到 ELK 的基本组成,并介绍了 ELK 的基本处理流程,以及从 0 开始搭建了一个 ELK 环境,演示了基于 Filebeat 收集容器日志信息的案例。然后,通过引入 Fluentd 这个开源数据收集器,演示了如何基于 EFK 的日志收集案例。当然,ELK/EFK 有很多的知识点,希望未来能够分享更多的实践总结。
“阿里巴巴云原生微信公众号(ID:Alicloudnative)关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术公众号。”