Kubernetes 集群接入炬鲸 OBSERVE：DaemonSet 采集日志 + OpenTelemetry 追踪

为什么用 DaemonSet 而不是 Sidecar

Kubernetes 里采集日志有两种主流方式：给每个 Pod 注入一个 Sidecar 采集容器，或在每个节点跑一个 DaemonSet 采集器。Sidecar 更贴近应用，但会让容器数量成倍增加，几十上百个 Pod 时几乎不可维护，还跟应用抢 CPU 和内存。

炬鲸 OBSERVE 推荐 DaemonSet 方案：每个节点一个采集器，读取 /var/log/containers 下的容器日志，按 Pod 标签自动归类到对应服务和命名空间。节点级故障不影响别的节点，采集器也跟应用生命周期解耦，升级时每个节点只需改一个组件。

第一步：添加 Helm 仓库并安装

helm repo add jjhub https://charts.jjhub.cn
helm repo update
helm install observe-agent jjhub/observe-agent \
  --set endpoint=https://ob.example.com \
  --set token=$OBSERVE_TOKEN \
  --set cluster=prod-k8s

安装完成后，每个节点会拉起一个 observe-agent DaemonSet，自动采集容器 stdout/stderr 日志、cAdvisor 指标和 Kubernetes 事件。endpoint、token、cluster 是必填项，其余参数都有合理默认值。

第二步：配置日志解析

DaemonSet 默认把整行日志作为 message 上报。要让日志可结构化检索，用 parser 配置按容器镜像匹配解析规则：

parsers:
  - name: nginx-json
    match: image=~"nginx"
    type: json
    time_key: time_local
  - name: java-stacktrace
    match: image=~"java"
    type: multiline
    pattern: '^\d{4}-\d{2}-\d{2}'

匹配到 nginx 镜像的容器日志按 JSON 解析；Java 应用则按时间戳开头识别多行堆栈，把异常堆栈合并成一条日志，而不是拆成几十行碎片。多行合并是排查 Java/Python 异常最容易被忽略、也最影响体验的一步。

第三步：注入 OpenTelemetry 链路

日志之外，要拿到调用链，需要在应用侧注入 trace 上下文。用 OpenTelemetry Operator 给工作负载自动注入：

kubectl apply -f https://github.com/open-telemetry/opentelemetry-operator/releases/latest/download/opentelemetry-operator.yaml

给命名空间打上 instrumentation.opentelemetry.io/inject: "true" 注解，Operator 就会自动给 Pod 注入 agent，把 trace 和日志关联信息一起上报到 observe-agent，再由它统一转发到炬鲸 OBSERVE。

排障清单

• 日志没上来：kubectl -n observe get pods 看 agent 是否 Running，再看 agent 日志里 endpoint 和 token 是否报错；
• 日志都在但没解析：检查 parser 的 match 是否命中了镜像名，镜像名要写完整仓库路径；
• 链路断了：确认注入注解打到了正确命名空间，且下游调用方也注入了上下文。

DaemonSet 采集加 Operator 注入，是 Kubernetes 环境下性价比最高的接入方式：一套配置，日志、指标、链路三类数据同时到位。