LinuxKubernetes日志方案教程_容器日志收集与分析

kubernetes日志需构建统一采集流水线：容器stdout/stderr经节点DaemonSet（如Fluent Bit）采集→注入Pod元数据→缓冲后推送至Loki/ES等中心存储；禁用应用内文件日志，强制UTC时区，避免硬编码traceID。

容器日志收集与分析在 Kubernetes 环境中不能只靠 kubectl logs 临时查看，必须建立统一、可靠、可扩展的日志流水线。核心思路是：让日志从容器流出 → 被节点层采集 → 汇聚到中心存储 → 支持检索与告警。

理解容器日志的默认行为

docker 和 containerd 默认将容器 stdout/stderr 输出重定向为 jsON 文件，存放在 /var/log/containers/（软链接到 /var/log/pods/）。每个文件名包含 Pod 名、容器名、容器 ID 和时间戳。注意：日志是纯文本流，无结构；轮转靠 kubelet 配置（--container-log-max-size、--container-log-max-files），不自动压缩。

• 避免应用自行写文件日志到容器内路径（如 /app/logs/），这会导致日志丢失或难以采集
• 若必须写文件日志，需用 hostPath 或 emptyDir 挂载到宿主机，并确保采集器监控对应目录
• 所有日志应使用 UTC 时区输出，避免时序错乱

主流采集方式对比：DaemonSet vs Sidecar

在节点上部署日志采集器最常用的是 DaemonSet 模式，Sidecar 模式适合特殊场景但开销大、管理复杂。

• DaemonSet（推荐）：每个节点运行一个采集进程（如 Fluent Bit / Filebeat），监听 /var/log/containers/*.log，天然支持多容器、低资源占用、易升级
• Sidecar：为每个 Pod 启一个日志代理容器，适合需要按应用定制解析逻辑或隔离敏感日志的场景，但会显著增加 Pod 数量和资源消耗
• 不建议用 node 上的全局 syslog 或 rsyslog 转发 —— 容器日志无进程上下文，标签（Namespace/pod/container）极易丢失

结构化日志与元数据注入

原始日志只是字符串，必须补全 Kubernetes 元信息才能有效归因。Fluent Bit 和 Promtail 等工具可在采集时自动注入：

• Pod 名、命名空间、节点名、容器名、容器 ID
• 通过 Pod annotation（如 Logging.fluentbit.io/parser）动态指定日志格式解析规则
• 对 json 格式日志（如 go 的 log.JSON()），启用自动解析并提升字段为 top-level 字段，便于查询（如 level == "Error"）
• 避免在日志行开头硬编码 traceID —— 应由采集器统一添加 trace_id 字段（配合 OpenTelemetry Collector 可实现）

落盘、传输与存储选型要点

日志不是指标，不可丢，但也不必强一致。关键取舍点在于可靠性、查询延迟和运维成本：

• 缓冲层：Fluent Bit 建议开启内存 + 文件双缓冲（storage.type Filesystem），防止节点重启或网络抖动导致日志丢失
• 传输协议：优先选 gRPC（Loki/prometheus Remote Write）或 http+gzip（elasticsearch），避免纯 TCP（无重试、无压缩）
• 后端选型：
  • Loki：轻量、低成本、适合标签过滤，但不支持全文检索和复杂聚合
  • Elasticsearch：功能全、生态成熟，但资源消耗高，需调优 jvm 和分片策略
  • 云厂商方案（如阿里云 SLS、AWS CloudWatch Logs）：免运维，但绑定平台、冷数据成本可能上升

不复杂但容易忽略：日志采集链路要加健康检查（如暴露 /metrics）、设置采集器资源限制（防 OOM）、定期清理节点上的旧日志文件（logrotate 或 kubelet 自带轮转）。