10 分钟接入：Kubernetes 集群日志与指标采集配置指南

Kubernetes 上做可观测，第一步是把日志和指标稳定地采出来。这篇给出从零接入炬鲸 OBSERVE 的完整配置，覆盖 DaemonSet 部署、过滤、字段规范和几个高频坑。

部署采集器：一个 DaemonSet 管全集群

采集器用 DaemonSet 部署，每个节点跑一个副本，负责采集本节点的容器 stdout/stderr 日志、cAdvisor 指标和 Kubernetes 事件。用 Helm 安装，两步完成：

helm repo add jjhub https://charts.ob.jjhub.cn
helm upgrade --install ob-collector jjhub/ob-collector \
  --set endpoint=ob.example.com:4317 \
  --set tenant=platform \
  --set token=$OB_TOKEN

安装后确认所有节点的 Pod 都在 Running，再确认后端能收到数据。一个常见的误区是只把日志采到本地，没配好上报 endpoint，导致采了一堆却查不到——先看采集器自己的日志里有没有上报成功的记录。

过滤与标签：别把噪声全采进来

默认全采会带来两个问题：数据量暴涨、检索变慢。我们建议按命名空间过滤，排除掉系统级的 kube-system 和测试用的临时命名空间，只采集业务命名空间：

namespaceFilter:
  include: ["prod-*", "staging"]
  exclude: ["kube-system", "kube-public"]

同时给每条日志自动打上 K8s 元数据标签：namespace、pod、container、node、labels 和 annotations。这几个标签是后面检索和告警路由的基础，缺一个都会让"按服务查日志"变得困难。自定义的业务标签（比如 team、tier）从 Pod 的 labels 里透传，命名要提前定好规范，避免后期改造成本。

字段规范：结构化日志才可检索

采集端要把日志解析成结构化字段，而不是整条塞进一个 message。对 JSON 格式的应用日志，采集器自动解析成字段；对普通文本日志，用正则解析器把时间戳、级别、trace_id 提取出来。建议应用侧直接输出 JSON 日志，采集端零解析成本最高、最稳定。

两个必做项：一是统一时间字段，用采集时间还是日志自带时间要定清楚，否则跨容器排序会乱；二是把 trace_id 定义成独立字段并建索引，为后面日志链路关联铺路。

多行日志与资源限制

Java 的堆栈、Python 的 traceback 都是多行日志，直接按行采集会被拆碎。采集端需要配置多行合并规则，用起始行的正则把后续行拼回来：

multiline:
  pattern: '^\d{4}-\d{2}-\d{2}'   # 以日期开头视为新一条
  maxLines: 200

资源限制同样要设。采集器在节点上是常驻进程，要给 CPU 和内存设上限，否则高负载节点上它自己会抢资源。推荐起步值 200m CPU / 512Mi 内存，观察稳定后再按需调整，并给日志落盘加大小和保留策略，防止磁盘被写满。

常见报错排查

• 上报失败：查 endpoint 和 token，看采集器日志里的连接错误；
• 日志查不到：确认命名空间过滤没把目标排除，确认时间字段解析正确；
• 多行被拆碎：检查 multiline 正则是否匹配实际日志的起始行；
• 数据量异常大：检查是否误采了系统命名空间或高噪声容器，按标签关掉。

采得稳、标得准、结构清，是 Kubernetes 可观测的地基。地基打好了，后面的检索、告警、链路才有意义。