第 12 章：先约束标签，再讨论采集成本

12.1 用乘法看清维度

假设一个 HTTP 指标有 8 个稳定路由、3 类结果、10 个实例，理论组合是 240。若再添加每天一百万个不同订单号，维度乘积会跃迁到完全不同的量级；直方图还要为每组标签保存多个桶、sum 与 count。这是成本结构的推导，不是本书声称做过的一百万序列压测。

实验请求计数只保留 route 与 outcome，服务、版本和环境来自 Resource。验收查询全部 lab_requests_total，检查序列标签不包含 order_id 与 trace_id。订单标识仍能存在于 span 和日志中，exemplar 则以受限样本把指标观察关联到 trace，不需要把 trace ID 变成普通指标标签。

资源属性同样需要审查。启用 resource_to_telemetry_conversion 会让资源属性进入 Prometheus 标签，这对演示服务筛选很方便，却可能意外放大成本。不要把每次启动生成的长随机配置、客户信息或请求属性放进 Resource，只因为 exporter 会自动处理它们。

12.2 删除信息前先想好查询合同

限制基数并不等于所有细节都不记录。维护者确实可能需要按某个订单调查问题，只是不一定应该通过全量指标索引完成。常见分工是：指标回答群体变化，trace 和受控日志回答某次执行，业务数据库回答对象的权威状态。

在真正删除字段前，应说明查询还怎样完成。若团队依赖 tenant 维度判断影响范围，可以先把租户分组或将少量关键租户单独观察，而不是直接删除所有隔离信息。若要记录错误原因，也应考虑稳定的错误类别，避免把含动态文本的异常消息作为标签值。

本书的 ok/error 很粗，适合最小实验；生产可能需要有限的 HTTP 状态类别、操作类型与错误码。新增每个维度时，都应估计取值上限、组合关系与保留窗口，并用实际序列查询验证估计。

12.3 隐私与成本在同一条管线相遇

请求正文、认证头、URL 查询参数和消息正文可能含敏感信息。一次方便调试的全量记录，可能被复制到 Collector、日志后台、告警和共享截图。到达后端再脱敏，无法撤回此前已经经过的所有副本。

因此优先在产生信号的边界实施最小记录规则，再在 Collector 加第二层防护。实验使用合成订单号，并不记录完整请求正文或密钥。CI 证据包只有专用实验数据，不能把它的公开方式直接套在真实客户系统上。

练习。 设计一个“接口成功率”指标，给出不超过三个标签，并估计每个标签的取值上限。然后写出一次具体订单故障应怎样从该指标跳到 trace 或日志，说明哪些信息属于普通标签、exemplar 和事件字段。

命名与标签设计可参考 Prometheus 指标实践；度量数据模型见 OpenTelemetry Metrics。