容器日志采集看起来只是把应用日志送到日志平台，真正落地时却会牵涉应用输出规范、容器运行时、节点采集器、Kubernetes元数据、日志解析、存储成本和排障效率。没有设计好的日志体系，问题发生时常见现象是：kubectl logs 能看到一部分，本地文件里还有一部分，日志平台字段不完整，按应用或版本检索不到，峰值流量时日志延迟严重。
在 Kubernetes 环境中，日志不应再依赖运维人员登录机器查文件。更合理的方式是让应用把关键日志输出到标准输出，由节点级采集器统一采集，并自动补充命名空间、Pod、容器、节点、镜像和标签等元数据。这样才能支撑多副本、滚动发布和动态调度下的排障。
标准输出是默认路径
容器环境推荐应用日志写到 stdout 和 stderr，而不是只写到容器内部文件。这样容器运行时可以统一接管日志，节点采集器也能通过标准路径采集。标准输出不是简单打印字符串，而是要保证日志格式稳定、级别明确、时间准确、关键字段可解析。
常见问题是应用仍沿用虚拟机时代的文件日志习惯，把日志写入容器文件系统。这样一旦容器重建，日志可能丢失；多副本场景也很难集中检索。如果确实有历史应用只能写文件，可以通过 Sidecar 或挂载卷过渡，但不应成为长期默认方案。
日志输出还要避免两个极端：过少会导致问题无法复盘，过多会推高采集和存储成本。生产日志应围绕业务关键路径、错误、延迟、外部依赖和安全事件设计，而不是把调试信息长期保留在高频日志中。
节点采集器适合大多数场景
Kubernetes 中常见日志采集方式是在每个节点运行 DaemonSet 采集器，例如 Fluent Bit、Filebeat 或 Vector。它们读取容器运行时日志文件，补充 Kubernetes 元数据，然后发送到 Elasticsearch、Loki、ClickHouse 或云日志服务。
节点采集器的优点是统一、轻量、对业务侵入小。业务容器不需要内置日志代理，也不会因为每个 Pod 都启动采集 Sidecar 而增加资源成本。对于大多数在线服务，这是优先推荐的方式。
节点采集器也有边界。它依赖节点文件路径、运行时格式和采集器稳定性。如果采集器资源不足、解析规则错误或输出端不可用，可能造成日志延迟或丢弃。因此平台团队要监控采集器本身，包括采集速率、发送失败、缓冲区、CPU内存和队列积压。
Sidecar模式什么时候需要
Sidecar 日志采集适合特殊场景，例如应用必须写文件、日志需要在 Pod 内做复杂转换、多日志文件需要独立处理、或某些合规场景要求与业务容器绑定采集。Sidecar 可以更贴近应用，但代价是资源开销更高、配置更复杂、Pod 结构更重。
如果每个业务都默认加 Sidecar，集群成本和运维复杂度会快速上升。平台应把 Sidecar 作为例外能力，而不是默认能力。对于大多数标准输出日志，节点 DaemonSet 已经足够。
过渡历史应用时，可以先使用共享卷让应用写文件，Sidecar 读取并转发；同时推动应用改造为标准输出。等改造完成后，再移除 Sidecar，回归统一采集路径。
日志字段比日志数量更重要
日志是否有价值，关键不在数量，而在字段能否支撑定位。建议至少包含时间、级别、服务名、环境、实例标识、请求ID、用户或租户维度、接口名称、错误码、耗时、外部依赖和版本信息。Kubernetes 元数据可以由采集器补充，但应用层业务字段需要研发主动输出。
结构化日志能显著提高检索效率。相比把所有信息拼成自然语言，JSON 或稳定键值格式更容易解析和聚合。即使不全面使用 JSON，也应保证错误码、trace id、订单号、任务ID等关键字段有固定格式。
日志字段设计要服务排障路径。例如一次发布后错误率上升，需要能按版本、Pod、节点、接口和错误码快速过滤；一次租户问题，需要能按租户ID或业务ID定位；一次依赖异常，需要能按外部服务名和耗时聚合。
日志与指标、链路要关联
日志不是孤立系统。一个告警触发后，运维人员通常先看指标确认影响范围，再看日志定位错误原因，必要时进入链路追踪分析调用路径。如果三者无法关联，排障会变成跨系统手工搜索。
建议在日志中保留 trace id 或 request id，并让指标、链路和日志平台可以通过同一标识互相跳转。发布系统也应把版本、镜像摘要和变更单信息注入到日志或元数据中，方便判断问题是否与发布相关。
对于平台团队，日志平台不只是存储系统，还应成为排障入口。常见查询模板、错误聚合、慢请求分析、异常发布对比，都可以沉淀成仪表盘或快捷查询。
成本治理不能最后再做
日志成本通常在业务规模增长后突然变成问题。高频访问日志、调试日志、重复异常堆栈、健康检查日志、批处理明细日志，都可能快速推高存储和检索成本。等成本失控后再治理，会影响研发排障体验。
建议从采集、传输、存储和保留周期四个层面治理。采集阶段过滤无价值日志，传输阶段控制缓冲和重试，存储阶段按冷热分层，保留周期按日志类型区分。错误日志、审计日志、核心业务日志和调试日志不应使用同一保留策略。
需要强调的是，成本治理不等于简单丢日志。核心错误、关键交易、审计事件和安全事件应保留足够时间；低价值高频日志可以采样或降级。平台应提供规则，让业务团队知道哪些日志必须保留，哪些可以优化。
常见问题
容器日志一定要输出到标准输出吗？
大多数场景建议输出到标准输出，因为这是 Kubernetes 最通用、最容易统一采集的方式。历史应用如果只能写文件，可以用 Sidecar 或共享卷过渡，但长期应尽量改造。标准输出配合节点采集器，能更好适应 Pod 重建和动态调度。
日志平台里为什么查不到某个Pod的日志？
可能原因包括采集器未运行、节点采集路径不匹配、Pod 生命周期太短、日志解析失败、命名空间过滤规则错误、输出端写入失败或索引延迟。排查时应先用 kubectl logs 确认容器侧是否有日志，再检查节点采集器状态和日志平台写入链路。
是否应该把所有日志都做成JSON？
结构化日志更利于检索和分析，但不一定所有日志都必须 JSON 化。关键是核心字段稳定可解析。对于错误、访问、审计和核心业务事件，建议使用结构化格式；对于少量辅助说明，可以保留自然语言，但要避免关键字段只存在于不可解析文本中。
如何降低日志成本又不影响排障？
优先治理低价值高频日志，例如健康检查、重复调试、无业务含义的循环输出。对访问日志可以按场景采样，对错误和审计日志保留完整。还可以按索引、冷热存储和保留周期分层，而不是所有日志使用同一策略。
结语
容器日志采集的目标不是把所有输出都堆到日志平台，而是让动态、多副本、频繁发布的 Kubernetes 应用仍然可观察、可检索、可复盘。标准输出、节点采集、结构化字段、元数据补充和成本治理结合起来，才能形成真正可用的生产日志体系。
转载请注明出处：https://www.cloudnative-tech.com/p/7479/
