本文目录
可直接引用的结论：指标用于聚合判断，单次请求明细应由日志和链路承载
本文面向维护 Prometheus、OpenTelemetry 或托管监控平台的研发、架构与运维负责人。每个指标名与一组标签值的唯一组合都会形成独立数据序列；把用户 ID、订单号、请求 ID、原始 URL、异常正文或任意 AI 工具参数写入指标，会让时序随业务对象持续增长。治理时先按指标、标签、服务和版本定位新增组合，再把标签分成固定枚举、受控集合与无界明细：前两类按查询价值保留，明细改由受权限和留存控制的日志或链路查询。基数上限是进程与采集链路的保护，不保证标签维度仍然完整；上线验收必须同时证明时序与资源回到预算、核心总量和分组告警仍准确、事件明细仍可通过稳定关联标识追查。
不同信息，应放在不同的可观测信号中
| 信息类型 | 建议承载方式 | 直接做指标标签的风险 |
|---|---|---|
| 固定业务维度 | 使用服务端定义的状态、方法、路由模板、区域或版本，并维护允许值集合 | 枚举失控或多个标签组合相乘，原本有限的维度仍可能快速膨胀 |
| 租户或客户分组 | 优先使用套餐、区域、风险等级等有限分组；确需逐租户指标时单独预算和隔离 | 全量 tenantId 随客户数、实例数、指标数和保留期共同放大 |
| 单次请求明细 | 在受控日志或链路中保存 traceId、请求 ID、订单号和脱敏上下文 | 把唯一标识写入指标后几乎每次请求都创建新序列，聚合价值很低 |
| HTTP 路径与错误 | 使用路由模板和有限错误类别，原始路径、查询串与异常正文留在日志或链路 | 路径参数、用户输入和动态错误文本使外部请求也能触发基数增长 |
适用边界：先区分高基数、采样过密和查询低效
高基数指一个指标流出现大量唯一标签组合，它会增加采集端聚合状态、后端时序、索引与查询范围。采集频率过高、保留时间过长、大量直方图桶或低效查询也会增加资源，但修复方式不同，不能把所有监控费用增长都归因于一个用户标签。
先把问题时间线与发布、自动埋点升级、路由变化、实例扩容、业务活动和保留策略调整对齐。分别记录活跃时序、每分钟新增序列、样本摄入、指标 SDK 或进程内存、采集队列、远端写入失败、存储与查询延迟；托管平台还要按其真实计费维度核对，不根据某个通用公式承诺费用降幅。
本文聚焦指标维度治理，不主张删除生产监控。若故障来自日志体积、链路采样或监控查询，需按对应信号单独处理。安全审计、财务对账和单笔业务追溯也不能只依赖聚合指标，应保留符合权限、留存与完整性要求的权威记录。
- 冻结问题窗口内的仪表盘、告警、采集配置和部署版本，保留可复核基线。
- 分别观察时序、样本、进程状态、采集链路、存储、查询与费用口径。
- 写明哪些告警与业务对账不能因成本治理被删除或改变语义。
从新增组合入手，定位指标、标签和值的责任来源
排查目标不是列出“标签值很多”，而是找出哪个指标从哪个版本开始，由哪个标签组合持续产生新序列。按指标名、服务、环境、实例、标签名和头部取值逐层缩小范围，并将自动埋点、业务自定义指标、采集器补充标签和后端重写规则纳入同一条链路。
Prometheus 官方命名指南说明，每一组唯一标签键值组合都会形成新的时序，并明确不应把用户 ID、邮箱等无界集合用作标签。Prometheus HTTP API 还提供 TSDB 基数统计入口；具体平台可能提供活跃时序、标签值数量或摄入排行，应在权限受控且不会给生产增加明显查询压力的范围内使用。只看最常见标签值不够，因为问题常来自不断出现、每个只存活很短时间的新值。
建立“指标 → 生产代码或库 → View/处理器 → Collector → 远端存储”的责任表。原始 URL 可能由 Web 框架埋点产生，Pod UID 可能由资源发现附加，完整异常正文可能来自业务代码，双发旧新语义约定则可能让序列重复。先确认来源再修改，避免只在仪表盘隐藏标签而采集与存储成本完全不变。
- 列出问题指标在各服务、环境和版本中的活跃与新增组合。
- 对每个高增长标签标记来源、允许值、业务用途、数据敏感性和负责人。
- 确认删除、重命名或聚合发生在产生端、采集端还是仅查询展示端。
建立标签契约与组合预算，不只限制单个标签值数量
标签评审应回答：这个维度支持哪条告警、容量判断或故障分组，允许值来自固定枚举、配置目录还是用户输入，最坏情况下会与哪些维度相乘。即使每个标签单独看都不大，路由、方法、状态、区域、版本、实例和租户交叉后仍可能产生大量组合。
为每个关键指标维护名称、单位、类型、标签清单、允许值来源、预计同时活跃组合、负责人和变更触发条件。预算以组合为核心，并在服务与环境层保留余量；不要把所有标签最大值简单相乘当作必然时序数，也不要只用当前样本推断永远安全。发布前用代表性路由、错误、租户与实例集合生成组合，比较新增时序速率和稳定后的活跃集合。
哈希、截短或加密用户 ID 并不会降低唯一值数量，只改变外观；把完整 URL 改名为 path 也不会自动去掉订单号和查询串。应把动态路径归一为服务端路由模板，把异常映射到有限错误类别，把版本保留在确实需要发布对比的指标上，并为未知值使用受控类别而不是把原始输入拼进 other。
- 每个标签都能对应明确查询或告警，并有可维护的值域来源。
- 预算覆盖标签组合、实例扩容、灰度双版本和自动埋点变化。
- 用户输入、唯一标识和自由文本不通过哈希或改名伪装成低基数标签。
把聚合维度与排障明细分层，用关联标识连接信号
指标保留能够快速回答“是否异常、影响哪类请求、从何时开始”的有限维度；单次请求、用户、订单、提示词、工具调用参数和完整异常堆栈进入访问受控的日志或链路。排障从异常指标缩小服务、路由模板、版本和错误类别，再用代表性 traceId 或时间窗查询明细。
OpenTelemetry HTTP 指标语义约定要求 http.route 使用低基数路由模板，不能用 URI 路径替代；当框架拿不到模板时，宁可不填该指标属性，也不要把原始路径写进去。状态码可按标准值保留，错误类型则应使用可预测的有限类别。小程序、APP 和 Web 请求中的页面参数、设备标识与用户输入同样不应成为无界指标属性。
AI 智能体尤其容易把会话 ID、提示词、工具参数、知识库文档 ID 或模型返回文本写进属性。指标只保留模型类别、工具类型、结果类别、是否超时等受控维度；委托人、会话、具体工具调用和脱敏输入输出放入审计日志或链路，并按权限和留存要求查询。关联标识本身也不应回写为指标标签，否则连接信号的手段会重新制造高基数。
- HTTP 使用服务端路由模板，未知路由与错误采用有限且可审计的分类。
- 指标、日志和链路共享可查询的时间与服务上下文，但唯一关联标识不做指标标签。
- AI、小程序与 APP 的用户输入、会话和业务对象明细按敏感数据规则留存。
基数上限是保护栏，不是保持所有分组准确的承诺
SDK、采集器或后端的基数限制可以防止意外维度无限占用资源，但达到上限后的行为会改变可查询结果。必须按实际语言 SDK、导出协议和平台版本核对，不应假设超限后只是安静丢掉一个多余标签。
OpenTelemetry Metrics SDK 规范建议支持按指标流配置基数限制，并在属性过滤之后执行限制；若没有 View 或 Reader 配置，规范给出默认值，但具体 SDK 的实现状态和配置入口仍需逐项确认。官方说明中的溢出数据点会合并超出限制的属性组合并标记 overflow：总量可以保留，而按状态、路由等属性筛选或分组的查询可能少算，因为原属性不再存在。
因此，发现溢出后不能只把上限调大。先判断是否存在原始路径、请求 ID、会话或异常正文等错误属性；能在 View 或产生端过滤就优先过滤。确实需要高基数维度时，写清同时活跃集合、聚合时态、进程数、后端总量、查询用途和费用边界，并为溢出本身告警。任何依赖属性分组的 SLO 或告警，都要在溢出场景下验证口径。
- 记录每个运行时、SDK、Reader、View、Collector 与后端的限制和超限行为。
- 溢出、拒绝、导出失败和远端写入积压有独立监测，不与业务失败混为一谈。
- 提高上限前先证明维度必要、活跃集合有界且后端容量能够承受。
实施步骤：影子计算新口径，再双看板灰度替换
第一步保存当前告警、查询、时序与费用基线；第二步按来源删除无界标签、归一路由并建立有限错误类别；第三步在测试或少量实例上输出新指标名或新版本流，与旧指标并行比较总量和关键分组；第四步迁移录制规则、仪表盘、SLO 与告警；第五步确认完整观察周期后停止旧流，并按平台能力等待或管理历史数据自然退出。
不要直接原地删除标签后假定所有查询自动等价。旧指标按 tenantId 分组，新指标按租户类型聚合时，业务含义已经改变；必须明确哪些问题转到日志或链路回答。双发期间时序会短期增加，应限定实例、时间和停止条件，避免治理验证本身扩大成本。告警切换记录最后一次旧规则评估和第一次新规则评估，避免无人监测窗口或同一故障重复通知。
回滚以配置、View、Collector 处理器和仪表盘版本为单位。若新口径使关键告警失真，先恢复已验证旧流或临时保留必要维度，同时限制无界来源；不要为追求费用目标继续上线不可信告警。历史时序是否立即删除、何时降低费用取决于存储和计费规则，治理报告只记录平台可验证结果，不承诺即时清零。
- 新旧口径的总量、分组、时间窗和缺失数据规则有逐项映射。
- 双发限定范围与期限，告警切换没有监测空窗并能整体回退。
- 删除旧流前更新仪表盘、录制规则、SLO、自动扩缩容和运维手册。
验收与风险：成本下降不能以告警漏报和隐私外泄为代价
验收在固定业务流量、实例数、采集间隔与保留策略下，对比活跃时序、新增序列速率、进程和采集器内存、导出队列、写入失败、查询延迟与实际账单口径。同时用已知故障和合成请求验证核心总量、状态、路由、版本与错误类别的告警是否按预期触发。
构造动态订单路径、大量不存在 URL、随机请求 ID、未知错误文本、租户突增、灰度双版本和实例重启，证明这些输入不会持续创建无界序列。再验证一个真实排障流程：从告警定位到服务与路由模板，进入日志或链路找到脱敏明细，并由稳定业务记录确认最终影响。若明细查询只能依赖已经删除且未在其他信号保存的字段，治理尚未完成。
主要风险包括：错误聚合掩盖单一大租户、溢出让属性告警少算、采集端删标签但后端已收到高基数流、双发导致短期容量超限、历史看板断档，以及把个人信息从指标迁到未受控日志。逐租户 SLO、监管审计或安全检测确需细粒度时，应建立隔离的指标流、访问控制、单独预算和保留策略，不能用一套低成本全局指标替代责任要求。
- 在同一负载和策略下比较资源、时序、查询与可核对的平台费用。
- 核心总量和分组告警通过故障注入，溢出或缺失不会造成静默少算。
- 排障明细可通过受控日志、链路和业务记录恢复，敏感字段与留存经过检查。
需求讨论中的问题
把用户 ID 哈希后放进标签，可以降低基数吗？
不能。若哈希仍近似一一对应，每个用户还是一个唯一值，时序数量没有实质下降。用户级明细应进入受控日志、链路或业务查询；指标使用套餐、区域、状态等有限且有聚合意义的维度。
设置基数上限后，告警就一定安全吗？
不一定。上限可以保护进程或指标流，但超限后的合并、丢弃或拒绝行为取决于实现。OpenTelemetry 溢出会影响按属性筛选与分组的结果，所以必须监测溢出并对核心告警做故障验证。
每个租户都需要独立 SLO，tenantId 是否一定不能做标签？
不是绝对禁止，但要证明业务必要，并核对同时活跃租户、聚合时态、实例数、后端序列总量、查询性能、费用和溢出行为。也可以按租户等级做全局指标，对重点租户使用隔离指标流或专门报表。
删除标签后，历史时序和账单会立即下降吗？
不一定。新样本不再产生该组合，但已有数据的保留、索引和计费周期由具体平台决定。治理报告应分别记录新增序列停止时间、活跃集合变化和账单生效周期，不能承诺即时清零。
AI 智能体的每次工具调用怎样既能统计又能追查？
指标按工具类型、结果类别、模型类别和是否超时等受控维度聚合；每次委托、会话、参数和结果在权限受控的审计日志或链路中用 traceId、operationId 关联。不要把会话 ID、提示词或文档 ID 写成指标标签。
高基数指标治理上线验收清单
可逐项勾选，辅助本次阅读；刷新页面后不保留。
参考资料
技术概念可进一步阅读以下资料；文中的业务场景与实施清单用于方案讨论。
- Prometheus Documentation · Metric and label naming
核验每组唯一标签值会形成新时序，以及不应把用户 ID、邮箱等高基数或无界值用作指标标签的官方建议。
- OpenTelemetry Specification · Metrics SDK
核验指标流基数限制、属性过滤后执行限制、View 与 MetricReader 配置优先级及规范默认行为；具体语言 SDK 支持情况仍需按部署版本确认。
- OpenTelemetry Semantic Conventions · HTTP metrics
核验 http.route 必须使用低基数路由模板、不能用 URI path 替代，以及部分外部可控属性可能触发基数限制的安全边界。
- OpenTelemetry · Metric cardinality limits in OpenTelemetry
核验溢出数据点、属性分组可能少算、SDK 上限不等于后端总基数上限，以及出现溢出时应先检查错误属性而非直接提高限制。
- Prometheus HTTP API · TSDB stats
核验 Prometheus 提供 TSDB 基数统计接口；生产使用时仍需控制查询权限、范围和自身资源开销。
需要评估现有系统的性能瓶颈？
提供关键业务路径、真实峰值、服务器与数据库配置，以及现有压测或故障记录，月弦科技可据此梳理优化顺序、实施范围和可验证的验收条件。