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 模式适合特殊场景但开销大、管理复杂。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
-
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 自带轮转）。
