50 | 让日志无处可逃：容器日志收集与管理

张磊



该思维导图由 AI 生成，仅供参考

你好，我是张磊。今天我和你分享的主题是：让日志无处可逃之容器日志收集与管理。
在前面的文章中，我为你详细讲解了 Kubernetes 的核心监控体系和自定义监控体系的设计与实现思路。而在本篇文章里，我就来为你详细介绍一下 Kubernetes 里关于容器日志的处理方式。
首先需要明确的是，Kubernetes 里面对容器日志的处理方式，都叫作 cluster-level-logging，即：这个日志处理系统，与容器、Pod 以及 Node 的生命周期都是完全无关的。这种设计当然是为了保证，无论是容器挂了、Pod 被删除，甚至节点宕机的时候，应用的日志依然可以被正常获取到。
而对于一个容器来说，当应用把日志输出到 stdout 和 stderr 之后，容器项目在默认情况下就会把这些日志输出到宿主机上的一个 JSON 文件里。这样，你通过 kubectl logs 命令就可以看到这些容器的日志了。
上述机制，就是我们今天要讲解的容器日志收集的基础假设。而如果你的应用是把文件输出到其他地方，比如直接输出到了容器里的某个文件里，或者输出到了远程存储里，那就属于特殊情况了。当然，我在文章里也会对这些特殊情况的处理方法进行讲述。
而 Kubernetes 本身，实际上是不会为你做容器日志收集工作的，所以为了实现上述 cluster-level-logging，你需要在部署集群的时候，提前对具体的日志方案进行规划。而 Kubernetes 项目本身，主要为你推荐了三种日志方案。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

Kubernetes容器日志管理方案概览 Kubernetes中容器日志的收集与管理是关键的运维任务之一。本文介绍了三种主要的容器日志管理方案。首先，通过在节点上部署logging agent，将日志文件转发到后端存储进行保存。其次，针对特殊情况，可以通过添加sidecar容器将日志文件重新输出到stdout和stderr上，以便使用第一种方案进行处理。最后，通过在应用Pod中部署sidecar容器，直接将应用的日志文件发送到远程存储中。文章还提到了各种方案的优缺点和实际操作方法。建议将应用日志输出到stdout和stderr，然后通过在宿主机上部署logging agent的方式进行集中处理。另外，及时清理日志文件也被强调为重要性。这些内容为读者提供了对Kubernetes容器日志管理的全面了解，帮助他们选择适合自己场景的日志处理方案。当日志量很大时，直接将日志输出到容器stdout和stderr上可能会导致性能问题，可以通过使用日志收集工具进行缓冲和批量发送来解决。除了本文提到的方案，还有一些其他容器日志收集的方案，如使用Fluentd、Elasticsearch等开源工具进行日志收集和分析，以及使用云服务商提供的日志管理服务等。希望本文能帮助读者快速了解Kubernetes容器日志管理的基本概念和常见方案，为其在实际应用中做出明智的选择提供参考。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《深入剖析 Kubernetes》，新⼈⾸单¥68

立即购买

登录后留言

全部留言(23)

最新
精选

lovelife
如果每秒日志量很大时，直接输出到容器的stdout和stderr,很容易就把系统日志配额用满，因为对系统默认日志工具是针对单服务(例如docker)而不是进程进行限额的，最终导致的结果就是日志被吞掉。解决办法一个是增加配额，一个是给容器挂上存储，将日志输出到存储上。当然日志量大也要考虑写日志时过多的磁盘读写导致整个节点的整体性能下降。
2018-12-17
1
50
ch_ort
Kubernetes项目的监控体系现在已经被Prometheus"一统"，而Prometheus与Kuberentes类似，也是来自Google内部系统的设计理念。 Prometheus项目工作的核心：通过pull方式拉取监控对象的metric数据，存储到时序数据库中供后续检索。时序数据库的特点：支持大批量写入、高性能搜索、聚合。基于这样的核心，Prometheus剩下的组件就是用来配合这套机制运行，比如 Pushgateway: 允许被监控对象以Push的方式向Prometheus推送数据 Alertmanager：根据Metrics信息灵活地设置报警 Grafana：活动配置监控数据可视化页面 Kubernetes借助Promethus监控体系，可以提供Custom Metrics的能力，即自定义指标。Custom Metrics借助Aggregator APIServer扩展机制来实现，即对APIServer的请求，会先经过Aggreator来转发，它会根据URL来决定把请求转发给自定义的Custom Metrics APIServer，还是Kubernetes的APIServer。有了这样的体系，就可以方便的实现自定义指标的感知了比如，现在启动了一个Custom Metrics APIServer，它对应的url是custom.metrics.k8s.io，当我需要获取某一个Pod内的自定义指标（例：http_requests）： https://<apiserver_ip>/apis/custom-metrics.metrics.k8s.io/v1beta1/namespaces/default/pods/sample-metrics-app/http_requests 这个请求就会被Custom Metrics APIServer接收，然后它就会去Promethus里查询名叫sample-metrics-app这个pod的http_requests指标。而Promethus可以通过定期访问Pod的一个API来采集这个指标。 Kubernetes对容器日志的处理方式都叫做cluster-level-logging。容器默认情况下会把日志输出到宿主机上的一个JSON文件，这样，通过kubectl logs命令就可以看到这些容器的日志了。 Kuberentes提供了三种日志收集方案：（1）logging agent: pod会默认日志通过stdout/stderr输出到宿主机的一个目录，宿主机上以DaemonSet启动一个logging-agent，这个logging-agent定期将日志转存到后端。优势： 1)对Pod无侵入 2)一个node只需要一个agent 3）可以通过kubectl logs查看日志劣势：必须将日志输出到stdout/stderr （2) sidecar模式： pod将日志输出到一个容器目录，同pod内启动一个sidecar读取这些日志输出到stdout/stderr，后续就跟方案1）一样了。优势：1）sidecar跟主容器是共享Volume的，所以cpu和内存损耗不大。2）可以通过kubectl logs查看日志劣势：机器上实际存了两份日志，浪费磁盘空间，因此不建议使用（3）sidercar模式2：pod将日志输出到一个容器文件，同pod内启动一个sidecar读取这个文件并直接转存到后端存储。优势：部署简单，宿主机友好劣势：1）这个sidecar容器很可能会消耗比较多的资源，甚至拖垮应用容器。2）通过kubectl logs是看不到任何日志输出的。
2020-12-30
1
15
Hammer_T
想问一下老师，如果一个容器里的日志有很多种，都输出到 stdout，收集的时候还能分得清是哪个吗？
2019-01-02
2
15
includestdio.h
公司目前采用的方案三，promtail 以sidecar方式运行在应用Pod中，日志通过promtail发到Loki ，最后再用 Grafana 展示
2022-04-18

9
fraηz
filebeat作为sidecar容器采集主应用容器日志，然后发送到ELK存储日志，这样可行吗？
2019-11-07
7
9
hhhh
日志文件大小会很快增加，当时我到了nginx访问日志半小时就好几G，由于没给日志文件挂载存储，docker的文件目录会很快就增大了，引发了磁盘使用报警。
2019-12-03

7
姜戈
阿里的log-pilot是个不错的选择
2018-12-23
2
7
曹顺详
老师好，请教一下，在应用代码层就指定日志存储后端这种解决方案有没有示例说一下。优缺点是什么？比如说是不是会增加应用的资源消耗？
2020-06-02
1
6
昀溪
老师，我们遇到一个问题也和日志有关，我们的POD都设置了limits，但是由于K8S统计POD的内存是包含缓存的，我们的POD日志输出是输出到一个文件，该文件是通过挂载emptydir的方式来做，然后使用阿里云的日志服务来收集。这里就面临一个问题，日志虽然采集走了，但是日志文件还留在目录里，它也会被算在POD的内存使用量里面，这就很容易造成OOM，请问这个问题应该怎么来处理，有没有什么思路提供一下。当然我们也会清理日志目录，比如一天前的，但是当天的日志如果很大依然会被算在POD的内存里。
2020-08-28
3
5
王景迁
为什么第3种方案sidecar容器会消耗很多资源？
2019-05-17
5
4

收起评论