4. 可观测性数据采集与治理

可观测性数据不是“采得越多越好”。在云原生平台里，Metrics、Logs、Traces、Events 四类信号的成本结构、查询方式和治理手段差异很大：Metrics 是聚合数值，写入量相对可控但标签基数会爆炸；Logs 是离散文本，单条便宜但总量巨大；Traces 是请求级链路，采样率直接决定成本；Events 是状态变更记录，量小但语义关键。本节围绕“采集规范—标签治理—采样策略—成本控制”这条主线，说明如何让四类信号既够用又不失控。

一、四类信号的采集规范

采集规范的核心是统一“谁采、采什么、怎么命名、带哪些标签”。建议在平台层约定：所有指标必须带 cluster、namespace、workload、service 四个基础标签；日志必须输出结构化 JSON，至少包含 ts、level、service、trace_id、msg；Trace 必须传播 W3C traceparent，并在入口网关注入 service.name；Event 必须带 reason、involvedObject、type。命名上遵循“域_对象_动作_单位”的约定，例如 http_server_request_duration_seconds，避免 req_time、latency 这类含义模糊的名字。

采集侧推荐使用 OpenTelemetry Collector 作为统一入口，通过 receiver 接收、processor 加工、exporter 输出。下面是一个 Collector 配置片段，演示如何对指标做标签裁剪、对日志做属性过滤：

processors:
  metricstransform:
    transforms:
      - include: http_server_request_duration_seconds
        action: update
        new_name: http_server_request_duration_seconds
  attributes/clean:
    actions:
      - key: pod_ip
        action: delete
      - key: node_name
        action: upsert
        value: ${NODE_NAME}
  batch:
    timeout: 5s
    send_batch_size: 8192

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [attributes/clean, batch]
      exporters: [prometheusremotewrite]
    logs:
      receivers: [otlp]
      processors: [attributes/clean, batch]
      exporters: [loki]

这段配置的关键点：attributes/clean 删除高基数且无查询价值的 pod_ip，同时把 node_name 统一为环境变量注入，避免同一节点因主机名变化产生重复时间线；batch 控制发送批次，降低远端写入压力。

二、标签治理：把基数关进笼子

标签治理的目标是“可枚举、可聚合、可下钻”。高基数标签是成本与查询性能的头号杀手。判断一个标签是否该保留，可以问三个问题：它的取值是否有限且稳定？它是否用于筛选或分组？它是否出现在告警或看板中？三者有其一才保留。典型应删除的标签包括 pod_ip、request_id、user_id、session_id、url 全路径。若确实需要按 URL 分析，应改为 route（如 /api/v1/orders/{id}）这类模板化标签。

下面这张图展示了从采集到存储的标签治理链路：原始标签经过白名单过滤、模板化改写、基数上限保护后，才进入长期存储；被拒绝的高基数标签会进入审计日志，供后续优化。

三、采样策略：Traces 与 Logs 的取舍

Trace 采样分头部采样与尾部采样。头部采样在请求入口决定是否记录，实现简单但可能丢掉慢请求；尾部采样在 Collector 中缓存完整 trace，按耗时、错误码、业务标签决定是否保留。生产上常用组合策略：基础采样率 1%，错误请求 100% 保留，P99 以上慢请求 100% 保留，核心交易链路 10%。下面是一个尾部采样策略的示例参数：

Logs 采样则更依赖“分级 + 限流”。DEBUG 日志在生产默认关闭，INFO 按服务限流（如每服务 500 行/秒），WARN 与 ERROR 全量保留但做去重聚合。对于高频重复日志，可在 Collector 中用 groupbyattrs 与 filter 合并相同 msg 与 trace_id 的记录，只保留首条与计数。

四、存储成本控制：从“采”到“存”的账

成本控制要算三笔账：写入量、存储量、查询量。以 Metrics 为例，假设某服务有 200 个指标，每个指标平均 8 个标签组合，采集间隔 15s，则每天时间线数约为 200 × 8 = 1600 条，每条每天写入 5760 个点，单服务日写入约 921 万点。若集群有 500 个服务，日写入约 46 亿点。此时若某个标签基数从 8 涨到 800，写入量直接放大 100 倍。因此，基数治理的收益远大于压缩算法优化。

Logs 的成本主要在索引与保留。建议热数据只索引 service、level、trace_id 三个字段，正文以压缩块存储；保留策略按“热 7 天、温 30 天、冷 90 天”分层，冷层用对象存储 + 按需加载。Traces 的成本与采样率线性相关，尾部采样可将写入量降低 60%～90%，但需要 Collector 具备足够内存缓存 trace。Events 量小，建议全量保留 30 天，并接入告警规则，例如 BackOff、FailedScheduling、OOMKilled 直接触发通知。

最后，治理不是一次性动作。建议每周输出一份“可观测性成本与基数报告”，包含各服务时间线数、日志写入量、Trace 采样率与存储费用，并对基数增长超过 20% 的服务发起整改。只有把采集规范、标签治理、采样策略和成本控制串成闭环，可观测性才能真正支撑云原生平台的可靠性，而不是成为新的成本黑洞。