K8s环境下应用启动失败时，OTEL如何收集控制台日志？

针对你提到的K8s中应用启动失败（如配置验证崩溃）的stdout/stderr日志采集问题，以下是几种可行的方案：

1. 并行保留原有容器日志采集管道 #

无需完全替换现有日志采集流程（如Fluentd/FluentBit），可以继续用原有方式采集容器stdout/stderr日志，同时将OTEL作为新增链路处理应用主动上报的Trace、Metrics及结构化日志。

• 若希望统一存储到OTEL后端，可将原有采集工具的输出转发至OTEL Collector的otlp接收器，实现日志数据的统一汇聚。
• 这种方式能确保启动失败的日志仍通过成熟的管道被捕获，不会因OTEL SDK未初始化而丢失。

2. 使用OTEL Collector的kuberneteslogs接收器直接采集 #

OTEL Collector Contrib仓库中的kuberneteslogs接收器专门用于采集K8s容器日志，它支持两种采集方式：

• 直接读取节点上的容器日志文件（默认路径/var/log/containers/*.log）；
• 通过容器运行时接口（CRI）对接容器运行时（如containerd、Docker）获取日志。
• 该接收器无需应用集成OTEL SDK，不管应用是否启动成功，都能捕获其stdout/stderr输出，完美覆盖启动失败场景。
• 示例配置片段：

  receivers:
    kuberneteslogs:
      path: /var/log/containers/*.log
      operators:
        - type: regex_parser
          regex: '^(?P<time>.+) (?P<stream>stdout|stderr) (?P<logtag>.+) (?P<message>.*)$'
          timestamp:
            parse_from: attributes.time
            layout: '%Y-%m-%dT%H:%M:%S.%NZ'
  

3. 采用DaemonSet模式部署OTEL Collector #

将OTEL Collector以DaemonSet方式部署在每个K8s节点上，由节点级的Collector负责采集该节点所有容器的日志：

• 这种部署模式下，Collector直接访问节点的日志存储目录或CRI接口，不受Pod内应用状态影响，能确保所有容器（包括启动失败的短生命周期Pod）的日志被采集。
• 结合kuberneteslogs或filelog接收器，可高效完成节点级日志的统一采集。

注意：若采用Sidecar模式部署OTEL Collector，需警惕应用启动速度快于Sidecar的情况——此时应用启动失败的日志可能无法被Sidecar捕获，因此DaemonSet或原有采集管道的组合方案更可靠。

内容的提问来源于stack exchange，提问作者Morten Toudahl