业务正常，采集却失败了
一句话总结
标签不是附加说明的备注，而是时间序列的地址。样本上限可以守住采集预算，却不会替你判断丢失了哪些信息。
为什么需要它
改进支付服务时，我们给请求指标加上了用户标识符，原以为这样更容易查找特定客户的问题。 在小型开发环境中一切正常，但随着用户增加，监控目标开始显示为 down。服务的健康检查 地址返回 HTTP 200，支付进程也仍在运行。误以为是网络故障而重启后，看起来会暂时恢复， 但同样的标签组合再次积累，问题也会回来。必须先看清采集在哪个阶段被拒绝。
Prometheus 的一条时间序列由指标名称和完整标签集合区分。即使是同名计数器，只要 user_id 不同，就是不同时间序列。它们不会仅仅因为 route 相同而自动合计。人以为只是新增一列标签， 对存储系统而言却是地址数量的增长。不仅用户数，路径、状态码和实例之间实际出现的组合也很重要。 可能组合的乘积只是估算上限的起点，并不总是实际观测到的准确数量。
工作原理
本实验最多只使用十二个合成用户，既不收集真实个人信息，也不造成过度内存负载。基准 exporter 暴露四个用户的请求计数器和一个业务状态 gauge，一次响应包含五个样本。用户增至十二个后， 即使指标名称相同，也会有十二个计数器样本和一个 gauge，共十三个样本。另有一个固定对照目标始终输出相同值。
| 观测位置 | 本实验回答的问题 |
|---|---|
| exporter 的 /healthz 和 /metrics | 进程是否正常响应，提供哪些原始数据？ |
| 当前应用的 scrape 配置 | 实际使用哪些目标、限制和过滤器？ |
| 目标 API 的 health 和 lastError | 最近一次采集是否成功；若失败，原因是什么？ |
| 当前 PromQL 结果 | 以哪些标签和值读取已存储样本？ |
sample_limit 限制单次抓取可接受的样本数。metric relabeling 后数量超过上限时，整个抓取都会失败。 它不是只保存前八个、正常截断其余内容的分页大小。实验中把上限设为 8，含五个样本的基线可以通过， 含十三个样本的响应则会被拒绝。要把最近的超限错误与 up=0 联系起来，同时保留业务 HTTP 200 以及对照目标 up=1 作为对比。
把 sample_limit 提高到 16 后，这次小型响应会再次进入系统。这是缩小原因范围的有用实验， 却不证明计量设计变好了。当前请求时间序列仍有十二条。在用户持续增长的生产环境中，只提高限制 只能推迟抵达下一个上限的时间。8 和 16 是用于观察原理的实验数字，不是适用于所有服务的生产建议。 实际预算必须结合采集周期、目标数、指标种类、保留期和查询模式进行测量。
指标名称也传达信号单位。请求次数是累积 counter，名称为 pca_checkout_requests_total。 当前业务是否正常是 gauge pca_business_ok。累积计数器值的总和，在本实验中用于确认信息保存， 并非每秒吞吐量。计算每秒吞吐量时，需要先为每个计数器计算考虑 reset 的 rate，再进行聚合， 这是另一个问题。本设计刻意使用小型静态输入，以免混淆两个概念。
现场会遇到的情况
用户 ID、订单号、完整 URL 等值域不断增长的标签，看起来像方便的搜索功能。但指标与保存所有事件细节的 存储系统职责不同。应先设计路径模板、有限状态分类等回答运维问题所需的维度，再考虑通过适当的日志和追踪 关联单个事件上下文。敏感标识符进入指标后，访问控制以及保留、删除范围也会更复杂。本实验中的 u1 等 合成值并不表示可以放入真实个人信息。
故障报告不要只写 down。写成“业务 HTTP 正常、对照组采集正常、该 job 的原始响应为 13 个样本， 因已应用上限为 8 而抓取失败”，后续行动就会不同。这样才有依据判断该重启进程、调查网络，还是修正计量设计。 即使一次观测彼此吻合，也要同时查看确认时间和最近抓取时间，避免把旧结果误认为新变更的结果。
下一实验要做什么
先从正常基线开始，保留原始响应、已应用配置和采集结果。增加标签数量以观察超限拒绝，再暂时提高限制， 确认同一批原始数据确实能进入系统。之后比较两种错误修补方法与源端计量修正。所有服务都只绑定个人 VM 的 loopback，不触碰他人的监控服务器或生产配置。实验结束后 VM 和 TSDB 会被回收，因此需要的观测结果必须在到期前另行保存。
官方文档
- Prometheus 配置：阅读 sample_limit 的应用时点与失败范围。
- 计量指南：结合评估观测问题与标签维度成本。
- 指标与标签命名：确认用名称表达单位和含义的规则。