日志收集是集群运维的一个重点工作。日常的排错、监控、分析工作都高度依赖日志,而在微服务架构下,实例数呈几何级数上升,手工收集已经几乎不可能,这更加凸显了日志收集工作的重要性。本文讲述如何通过fluentd组件高效收集kubernetes日志。
日志收集简介
kubernetes是一个优秀的容器编排框架,提供容器调度方案以及各类网络、存储插件的集成。但其本身(in-tree)并不提供日志解决方案,而是以插件(add on)的方式提供,官方推荐的是EFK方案。
官网有对于日志架构的专门一章的描述,官方把kubernetes中的日志解决方案分为三种类型:
- 基础日志
- node级别日志
- 集群级别日志
基础日志:比较好理解,和docker的日志方案类似,通过捕获标准输出流(stdout)和标准错误流(stderr)来fetch日志,使用的命令是kubectl logs
,相信大家都比较熟悉了,这里不多赘述。基础日志由于是写在容器里面,所以当容器crash或者pod迁移后,之前的日志就没有了。
node级别日志:任何在容器中写入stdout和stderr的内容都会通过容器引擎重定向到某个文件,比如docker中会把日志信息写入log-file.log
。这里要注意的是,kubernetes目前默认是不提供日志轮转的,可以使用logrotate这样的工具来实现轮转的效果。注意node级别的日志还是写在每个节点上的。
集群级别日志:有如下几个选项
- 使用一个node-level logging agent运行在每个节点上
- 给一个pod配置一个日志收集专用的sidecar
- 从应用中直接向日志后端写日志
后面两种暂时不讨论,主要讨论第一种方案(node agent),也是官方推荐的日志方案。使用node logging agent的架构图如下:
可以看到这种方案特点是在每个node上起了一个daemonset,作为日志收集的守护进程,读取节点上
log-file.log
中的日志,并发送给日志后端(比如elasticsearch)。这是一种相对比较完善的日志方案,可以将整个群集的日志统一收集,并进行集中的检索,大大提高了运维的效率,同时对于应用没有任何的侵入性(做过应用开发的都知道无侵入是一种多么宝贵的能力)。
针对这种场景,官方推荐的这个node agent就是fluentd。fluentd本身也是cncf项目,性能比logstash要更好。由于和k8的结合比较好,所以在云原生场景中,一般推荐的解决方案都是EFK而非ELK
安装EFK
EFK就是elasticsearch+fluentd+kibana,对于es和kibana,我在之前的文章中已经有论述如何安装,可以参考使用helm charts安装elasticsearch集群这篇文章,这次主要讲fluentd的安装。
对于生产环境,如果节点数较多,比较建议的是先通过前端fluentd将日志收集到kafka,再通过统一的日志后端将kafka中的日志写入es中。如果节点数不是特别多,则可以直接通过fluentd将日志写入es。官方仓库中的EFK方案,就是fluentd直接写入es的。网址:https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/fluentd-elasticsearch,里面有6个yaml文件,直接部署完就得到了一个EFK的解决方案。不过使用官方的部署文件部署出来的es集群默认使用emptyDir的存储,自然不能用在生产上。考虑到索引是一个重IO的工作,es最好是接一个高性能的分布式存储(如ceph)。
实际生产中,一般es会独立部署,那么就需要修改fluentd-es-configmap.yaml
配置文件,修改一下es的地址和端口即可
output.conf: |-
<match **>
@id elasticsearch
@type elasticsearch
@log_level info
type_name _doc
include_tag_key true
host elasticsearch-logging
port 9200
logstash_format true
<buffer>
@type file
path /var/log/fluentd-buffers/kubernetes.system.buffer
flush_mode interval
retry_type exponential_backoff
flush_thread_count 2
flush_interval 5s
retry_forever
retry_max_interval 30
chunk_limit_size 2M
queue_limit_length 8
overflow_action block
</buffer>
</match>