备案站点的监控指标基数治理与采样

监控系统自己挂了，往往是被一个标签打死的

某天监控面板开始加载不出来、查询超时、存储磁盘暴涨。排查下来根因常常很朴素：有人给某个指标加了一个标签，值是用户 ID，或者请求 URL 里带了随机参数。每一个不同的标签值都会产生一条独立的时间序列，几百万条序列足以把监控系统压垮。

讽刺的是，这类故障发生时，你恰好失去了排查其他故障的能力。

关键要点

• 基数是各标签取值数的乘积，不是加和——三个各 100 取值的标签就是一百万条序列。
• 用户 ID、订单号、原始 URL、完整错误消息、时间戳这类无界字段绝不能做标签。
• 三类数据分工明确：指标看趋势、日志查明细、追踪看链路，别用指标承载明细。
• 采样不是均匀丢弃，错误和慢请求必须全量保留，否则等于丢掉故障现场。

基数是怎么炸的

标签组合	取值数	产生的序列数
接口路径（50）	50	50
＋状态码（10）	10	500
＋实例（20）	20	10000
＋用户 ID（10 万）	100000	10 亿

前三个维度完全合理，加上第四个就彻底失控。判断一个字段能不能做标签，只需问一句：它的取值集合是有界且稳定的吗？有界就可以，无界就不行。

常见的无界标签来源：用户与会话标识、订单号与交易流水号、未做模板化的原始 URL（/order/12345 应归一成 /order/{id}）、完整异常消息（应只留异常类型）、精确到毫秒的时间、未归一化的 User-Agent 字符串。

三类数据的分工

类型	适合回答	成本特征	不该用来做什么
指标	趋势、比例、告警	与序列数强相关	查某一笔具体请求
日志	明细、上下文、根因	与数据量相关	画长期趋势曲线
追踪	跨服务的调用链与耗时分布	与采样率相关	全量统计

「想按用户 ID 查某次请求」是日志和追踪的活，不是指标的活。把它塞进指标标签，是基数爆炸最常见的动机。日志侧的字段规范见 日志规范与集中检索，链路追踪的上下文透传见 可观测性建设。

分位数指标的额外代价

延迟分位数通常靠直方图实现，而直方图的每个区间都是一条独立序列——它的基数是普通计数器的若干倍。两条经验：区间划分要贴合业务实际的延迟范围（都落进同一个区间等于没有分辨率），以及避免在直方图上叠加高基数标签，那是基数的乘法叠加。

另一个常被忽略的点：分位数不能跨实例简单平均。把各实例的 P99 求平均得到的数字没有统计意义，正确做法是合并原始直方图后再计算。

采样：保住故障现场

追踪数据全量采集成本很高，但采样策略选错会让采样等于自欺欺人。

• 头部采样（请求开始时决定）：实现简单、开销低，但故障请求大概率被丢掉——正常请求和错误请求被一视同仁。
• 尾部采样（请求结束后决定）：可以做到「错误全留、慢请求全留、正常请求按低比例留」，代价是需要临时缓存完整链路。

实践上的推荐是混合策略：正常请求低比例采样，错误与超阈值慢请求全量保留。日志侧同理——成功请求可以按比例采样，错误日志必须全量。

一个容易被忽视的细节是采样一致性：同一条链路上的所有服务必须做出相同的采样决定，否则会拿到一堆残缺链路，比不采样还难排查。

存储：降采样与保留分级

原始精度的数据没必要长期保留。典型分层是：近期保留原始精度用于排障，稍早的数据按分钟聚合用于周报与对比，长期只保留小时或天级聚合用于容量趋势与同比。

用途	需要的精度	保留策略
故障排查	秒级原始	数天到数周
周期对比与复盘	分钟级聚合	数月
容量趋势与年度规划	小时/天级聚合	长期

降采样时要注意聚合方式：计数类可以求和，分位数不能简单平均，应保留合并后的分布。指标存储的成本要纳入整体盘点，见 服务器资源与成本治理；保留期限的制定方法见 数据生命周期与归档清理。

治理动作清单

• 定期查看序列数最多的指标排行，新增的高基数指标通常一眼可见。
• 给指标上线加评审门槛：新增标签要说明取值范围与上界。
• 在采集端设置基数上限与丢弃策略，超限时丢弃新序列并告警，而不是把存储写爆。
• URL、异常、枚举值一律先归一化再打标签。
• 把监控系统自身纳入监控：写入速率、查询延迟、序列总数、存储用量，告警接入见 备案网站监控告警体系。
• 压测期间的指标要能按压测标识区分，否则容量基线会被污染，见 全链路压测与影子环境。

常见坑

• 把用户 ID 或订单号当标签：序列数直接失控。
• URL 不做模板化：每个路径参数都产生一条新序列。
• 异常消息全文入标签：消息里带变量，基数无上界。
• 直方图叠加高基数标签：成本是乘法级增长。
• 对 P99 求平均：得到一个没有意义的数字并据此决策。
• 均匀采样：错误请求被丢掉，故障时无链路可查。

常见问题

指标基数到多少算危险？

没有绝对数值，取决于存储方案与资源配额。更实用的判断是看趋势：序列数持续单调上涨且没有收敛迹象，就说明存在无界标签，应当在压垮系统之前定位并治理。

已经上线的高基数指标怎么处理？

先在采集端停止上报该标签止血，再做归一化改造（URL 模板化、异常只留类型），最后清理历史序列。直接删历史数据而不修上报，过几天会再涨回来。

采样率设多少合适？

正常请求可以很低（例如百分之一甚至更低），关键是错误与慢请求必须全量保留。比采样率更重要的是采样策略：尾部采样能在低成本下保住所有故障现场。

监控数据能不能也存到业务数据库里？

不建议。指标是典型的时序写入，与业务数据库的访问模式冲突，量大后会拖累在线业务，见 数据库运维与高可用。应使用专门的时序存储。

资料来源

主流时序监控与链路追踪系统（如 Prometheus、OpenTelemetry）官方文档中关于标签基数、直方图、采样策略与降采样的公开说明。本文为通用运维说明，仅供参考，具体以实际监控方案与资源配额为准。