容器日志收集ELK+Filebeat+Kafka

简介

随着容器如火如荼的发展,分布式的业务架构日志收集便也成了我们需要重点考虑之一;传统方式中已经有相对成熟的解决方案,无不外乎容器中我们同样能够采取相同的架构解决容器基于Kubernetes的日志收集问题;

 

组件介绍

对于这套方案,网上已经有无数种介绍,在此就不再对各大组件进行赘述,仅做简单描述

组件	作用	优点
Filebeat	作为客户端收集日志,输送消息至Kafka	占用资源少，处理数据快，十分稳定
Kafka	接收Filebeat产生的消息,并由Logstash进行消费	解决程序异常导致的日志丢失问题
Logstash	消费Kafka中的消息,根据规则自动创建索引	可配置型高,支持多输入输出方式
Elasticsearch	持久化存储数据	便于检索查询
Kibana	展示日志收集结果	便于结果查询

 

架构图

 

容器日志采集方式

• 文件读取: 容器日志通过程序定义输出到文件然后通过挂载出来

• Daemonset: 在Node节点部署filebeat采集容器日志

• Sidercar: 在每个Pod中部署sidecar容器用于收集容器日志

这三种方式各有利弊,从维护性及资源使用上,比较推荐的是Daemonset方式

 

要求

• 首先需要在每个Node节点上部署filebeat
  

• 定义容器中的日志输出到控制台,以nginx为例

       access_log /dev/stdout json;
       error_log  /dev/stderr;

• 为Pod添加annotations用于收集控制参数

        annotations:
          filebeat.harvest: "true"
          filebeat.index: "elktest"

日志收集效果

场景	是否丢日志	测试过程
更新nginx/php配置时	否	持续请求2W次，日志有2W条展示
更新k8s yaml模版	否	持续请求2W次，日志有2W条展示
更新代码	否	持续请求2W次，日志展示偶尔少1条、2条，无错误日志；经排查由于脚本执行过程中未发起http请求
Hpa进行弹性伸缩	否	持续请求2W次，日志有2W条展示
Hpa进行弹性伸缩的情况下更新代码	是（出现502情况）	持续请求2W次，日志有大于2W条展示日志，有短时间502出现（5～20S服务不可达）待调优

服务部署

为防止篇幅过长影响可读性,部署章节分文编写,请见下章