容器重启后日志全丢了？Kubernetes 日志采集的正确打开方式

摘要：

容器重启导致日志丢失是 Kubernetes 运维中的常见痛点。本文解析 K8s 原生日志机制的局限，介绍 DaemonSet 与 Sidecar 两种主流采集模式，并说明如何借助腾讯云日志服务 CLS 实现日志的持久化存储与秒级检索，帮助团队构建可靠的日志管理体系。

一、为什么容器重启后日志会丢失

在 Kubernetes 集群中，容器的生命周期是短暂的。当 Pod 被驱逐、节点故障或应用崩溃重启时，容器内产生的日志也随之消失。许多开发者习惯使用 kubectl logs 命令查看日志，但这条命令读取的是容器运行时写入宿主机的 JSON 文件，一旦容器被删除，这些文件便无法访问。

Kubernetes 官方将这种依赖容器生命周期的日志访问方式称为临时性日志。它适用于开发调试阶段的快速排查，却无法满足生产环境对日志持久化和集中管理的需求。当线上问题发生在深夜，而相关 Pod 已经在自动恢复过程中重建了数次，仅靠 kubectl logs 很难还原故障现场。

要解决这一问题，核心思路是将日志从短暂的 Pod 生命周期中解耦出来，通过独立的采集组件将日志实时转发到外部存储系统中。这样即使容器重启甚至节点宕机，日志数据依然完整可查。

二、DaemonSet 与 Sidecar 采集模式简述

Kubernetes 日志采集主要有两种模式：DaemonSet（节点级采集）和 Sidecar（应用级采集），它们在解决日志丢失问题上的作用如下：

• DaemonSet 模式：在每个节点上部署一个采集器，自动挂载 /var/log/containers/ 目录读取所有容器日志。零侵入、资源消耗固定，适合大多数标准输出日志的场景。
• Sidecar 模式：在每个业务 Pod 内额外部署一个采集容器，与主应用共享日志卷。隔离性强、可按应用定制采集策略，适合对日志有特殊处理需求的场景。

无论选择哪种模式，核心目标都是一致的——将日志从短暂的 Pod 生命周期中解耦出来，实时转发到外部持久化存储系统中。

三、CLS 在 K8s 环境中的落地实践

3.1 快速接入：TKE 一键开启集群日志采集

对于使用腾讯云 TKE（Tencent Kubernetes Engine）的集群，CLS 提供了最便捷的接入方式。在 TKE 控制台的"日志管理"页面中，选择目标集群并点击"开启日志采集"，系统会自动完成以下操作：

1. 在 kube-system 命名空间下以 DaemonSet 方式部署 LogListener 采集代理
2. 自动创建对应的 CLS 日志集和日志主题
3. 配置默认的采集规则，覆盖容器标准输出和常见日志路径

整个过程中无需手动编写 YAML 配置文件，也无需关心采集器的版本管理和健康检查。新增节点时，LogListener 会通过 DaemonSet 调度器自动部署到新节点上，实现无缝扩展。

对于自建 Kubernetes 集群或其他云平台的 K8s 集群，可以通过 Helm Chart 或 YAML 文件手动部署 LogListener DaemonSet。采集器支持通过环境变量指定 CLS 的接入地址和认证信息，适配多种网络环境。

3.2 精细化采集配置

在 CLS 控制台的日志主题页面中，可以对采集规则进行精细化配置：

日志源类型：支持容器标准输出、容器文件路径和节点文件路径三种来源。可以按需选择全量采集或增量采集，并通过通配符灵活指定日志文件路径，例如 /var/log/containers/*.log。

结构化解析：LogListener 支持单行全文、多行全文、分隔符、JSON 和正则表达式五种解析方式。对于 Spring Boot 应用的多行堆栈日志，可以选择多行全文模式并配置起始行正则（如 ^\d{4}-\d{2}-\d{2}），确保完整的异常堆栈被作为一条日志处理。

黑名单过滤：可以在采集阶段就排除不需要的目录或文件，减少无效数据的传输和存储成本。例如排除 kube-system 命名空间中健康检查探针产生的高频低价值日志。

元数据附加：采集器会自动为每条日志附加 Pod 名称、命名空间、容器名称、节点 IP 等 Kubernetes 元数据字段。这些字段在后续检索和 SQL 分析中可以作为过滤和分组维度使用。

3.3 索引与检索配置

日志写入 CLS 后，需要在控制台开启索引才能进行检索分析。CLS 提供两种索引类型：

• 全文索引：将日志内容按分词切分建立倒排索引，适合模糊搜索场景。亿级数据量下关键词检索秒级返回。
• 键值索引：针对特定字段（如 pod_name、namespace、status_code）建立精确索引，适合聚合分析和范围查询。

建议对常用的 Kubernetes 元数据字段和业务关键字段建立键值索引，这样可以在 SQL 分析中获得更好的性能表现。

四、容器日志检索与故障排查实战

4.1 快速定位重启事件的上下文日志

当发现某个 Pod 发生重启后，可以在 CLS 控制台的检索框中输入以下查询语句，快速定位重启前后的关键日志：

# 查看指定 Pod 最近 1 小时的日志（按时间倒序）
kubernetes.pod_name:"order-service-7d8f9c6b5-x2k9m" AND __time__:[now-1h TO now] | select * order by __time__ desc limit 100

如果需要查看 OOM Kill 相关的系统事件，可以结合节点的系统日志进行联合检索：

# 检索包含 OOM 或 killed 的日志
"killed" OR "out of memory" OR "OOM" AND kubernetes.namespace:"production"

4.2 统计各命名空间的错误日志分布

通过 SQL 分析可以快速了解集群中哪些服务出现了异常：

SELECT kubernetes.namespace, kubernetes.pod_name, count(*) AS error_count
FROM log
WHERE level = 'ERROR' OR status_code >= 500
GROUP BY kubernetes.namespace, kubernetes.pod_name
ORDER BY error_count DESC
LIMIT 20

这条查询会返回过去一段时间内错误日志最多的前 20 个 Pod，帮助运维人员快速锁定问题服务的优先级。

4.3 追踪请求链路中的异常环节

在微服务架构中，一个请求可能经过多个服务。通过 trace_id 可以将分散在不同 Pod 中的日志串联起来：

# 根据 trace_id 追踪完整调用链
kubernetes_labels.trace_id:"a1b2c3d4e5f6" | select kubernetes.pod_name, body, __time__ order by __time__ asc

即使相关 Pod 已经重启多次，这些日志依然完整地保存在 CLS 中，可以随时回溯分析。这正是将日志从容器生命周期中解耦出来的核心价值所在。

4.4 仪表盘监控关键指标

CLS 支持将常用的检索和 SQL 分析结果固化为可视化仪表盘。针对 Kubernetes 集群，建议创建以下监控图表：

• Pod 重启次数趋势：按命名空间分组统计 kubernetes_reason 字段
• API Server 响应延迟 P99：基于 duration_ms 字段的百分位计算
• 各命名空间错误日志量：按 kubernetes.namespace 分组的柱状图
• Top 10 高频错误信息：对 body 字段中包含 ERROR 的日志做词频统计

仪表盘支持定时订阅推送功能，可以按日/周/月自动发送到团队成员的邮箱或企业微信，让相关人员随时掌握集群健康状态。

五、告警配置：让问题主动找你

日志持久化存储只是第一步，更重要的是在异常发生时能够第一时间收到通知。CLS 的告警功能支持基于关键词检索和 SQL 分析两种方式设置触发条件：

关键词告警：适合检测特定的错误模式。例如当检测到 "OOM" 或 "killed" 关键词时立即触发告警：

kubernetes.pod_name:"order-service-*" AND ("OOM" OR "out of memory" OR "killed")

SQL 告警：适合检测聚合层面的异常。例如当某个命名空间在 5 分钟内的错误日志数量超过阈值时触发：

SELECT kubernetes.namespace, count(*) AS error_count
FROM log
WHERE level = 'ERROR'
GROUP BY kubernetes.namespace
HAVING error_count > 100

CLS 支持秒级告警触发，可以配合静默窗口避免重复通知。通知渠道覆盖电话、短信、邮件、微信、企业微信、钉钉、飞书和自定义 Webhook 回调，可以根据告警级别灵活搭配——P0 级故障通过电话+企业微信并发通知，P1 级通过企业微信推送，P2 级仅需邮件提醒即可。

对于有值班排班需求的团队，可以通过 Webhook 将 CLS 告警接入第三方运维管理平台，由平台负责按值班表自动路由到当前负责人。

六、总结与建议

容器重启导致日志丢失的根本原因是将日志的存储与 Pod 的生命周期绑定。解决这一问题的核心思路是通过独立的采集组件（DaemonSet 或 Sidecar）将日志实时转发到外部持久化存储中，使日志数据脱离容器的生命周期独立存在。

在 Kubernetes 环境中落地日志管理方案时，建议遵循以下步骤：首先选择合适的采集模式并部署 LogListener 采集器；其次配置结构化解析规则确保日志可被高效检索；然后建立关键指标的仪表盘和告警规则，实现从被动排查到主动发现；最后根据合规要求和成本预算设置合理的日志保留策略，利用 CLS 的日志沉降功能将历史数据从标准存储迁移到低频存储，降低长期保存成本。

构建可靠的容器日志管理体系不仅能大幅提升故障排查效率，还能为安全审计、性能优化和业务分析提供坚实的数据基础。建议在集群上线初期就规划好日志采集方案，避免后期因日志缺失而导致问题无法追溯。

想要为容器集群搭建 CLS 日志采集体系，新用户开通即可领取 10U × 3 个月 免费资源包用于体验，首单特惠最低至 0.8 折起；新老用户购买资源包常规档位最低可享 6.3 折优惠。如需了解更多详情或领取优惠，可访问 腾讯云 CLS 产品页 及 特惠活动页。