删除标签真的会聚合数值吗
一句话总结
删除标签不等于求和，up=1 也不能证明所需信息全部得到保留。必须对照原始数据的含义与查询结果。
为什么需要它
指标太多时，看起来只要删除用户标签就能解决。十二个计数器显示成一个，仿佛存储成本已经下降、工作也已完成。但在合计应为 78 的实验中，结果却变成了 1。目标状态仍是 up，最近错误字符串也为空。让页面变绿与保留运维人员要问的问题，是两个不同目标。在经过真正的采集器之前，很容易忽略这种差异。
工作原理
metric_relabel_configs 会修改已采集样本的标签，或排除部分样本。labeldrop 的作用是删除指定标签名称。如果从原本由不同 user_id 区分的样本中删除该标签，具有相同名称和其余标签的地址就会冲突。这不是把多个 counter 值相加的聚合运算。官方文档也提醒，删除标签后必须注意时间序列是否仍然保持唯一。
本实验的固定输入是每个用户的值从 1 到 12，总和为 78。在实际 Prometheus 3.14.0 探测中，删除 user_id 后，当前时间序列数为 1，查询总和也为 1；up 为 1，lastError 为空。不要把这个结果泛化为“发生冲突时总会保留第一个值”的 API 契约。在固定版本、输入和时刻的这次观测中，关键结论是 labeldrop 没有替我们合计出 78。其他输入或版本可能出现不同的错误或拒绝形式，因此必须直接检查原始响应和实际结果。
本实验最初的判定器假设只要冲突，up 就一定变成 0，因此失败了。实际结果与预期不同时，我们没有强行把服务器改成 down，而是保留当时的代码和只读观测，在新 VM 上重新对照输入与结果。好的验证不是制造自己期待的状态，而是解释实际发生的事情。测试错误时，测试的假设也需要修改。
下一种修补方式是 drop 整个问题请求指标。原始响应仍有 13 个样本，但采集后只剩一个业务 gauge，落在限制以内，up 也恢复正常。然而，请求计数器查询变成空向量。不能把这报告为请求数为 0。没有可观测信息，与存在一个值为 0 的样本，不是一回事。只看查询结果，可能很难区分过滤器的有意排除与故障造成的缺失。
| 变更 | 页面上看起来改善的地方 | 必须确认的损失 |
|---|---|---|
| 提高 sample_limit | 采集再次成功 | 高标签组合数仍然存在 |
| 删除区分标签 | 当前时间序列数减少 | 不保证不同值会被求和，也不保证语义得到保留 |
| 排除整个指标 family | 位于限制内且 up 正常 | 回答必要业务问题的指标可能消失 |
| 在源端设计维度并聚合 | 用较少时间序列暴露所需总和 | 无法再回答已删除细分维度的问题 |
最后，我们修改 exporter 的计量模型。不再暴露按合成用户划分的详细值，而是暴露按 route 聚合、值为 78 的计数器，从一开始就不输出 user_id 标签。一个请求 counter 加一个业务 gauge，原始响应只有两个样本。移除临时过滤器并把 sample_limit 恢复为 8 后，采集仍成功，请求总和仍为 78。这一步用于区分在过滤器后悄悄丢弃数据，与从源头设计必要维度。
现场会遇到的情况
仪表板中的 sum 只聚合查询结果。保存该查询，并不会从 TSDB 删除已经采集的按用户时间序列。实验中会并列查看当前时间序列数与过去求值时刻的查询。改进后当前只有一条时间序列，但指定曾提高限制、采集到 12 条序列的时刻，仍能确认当时的 12 条及总和 78。不能仅凭 series API 的标签列表断言当时确实存在样本，还要保留明确指定求值时刻的实际 PromQL 结果。元数据列表与时间序列样本不是同一种证据。
本实验不会启用 TSDB 删除 API，也不会删除数据，因为我们不能声称修改源端计量就会自动清除过去的敏感信息。生产环境处理保留策略或删除时，需要另外审查权限、备份、审计和影响范围。这里所有用户 ID 都是合成值，重点是安全地区分当前计量修正与历史数据保留这两个问题。
确认当前信息是否正确保留，也不能只看一个数字。我们会同时读取 exporter 原始响应、当前应用配置、最近抓取时刻、当前 counter 总和及独立对照组，并确认服务进程的运行标识未变化，从而记录并非通过重启来初始化状态。短期样本正常，与验证长期性能和损失率不同；这个小实验不能替代大规模负载测试。
下一实验要做什么
依次比较提高限制、删除冲突标签、排除指标和源端聚合。最终报告要说明：为何仅凭 up 不能保证信息保留；保留了哪些业务问题；有意丢弃了哪些细分维度；当前修正不会删除过去数据。“采集成功”与“观测语义正确”需要分别验证，这一习惯就是本实验的成果。
官方文档
- Relabel 配置：阅读 labeldrop 后关于唯一性的注意事项。
- Prometheus HTTP API：区分求值时刻与标签元数据 API。
- PromQL 聚合运算符：确认查询聚合的作用。