题干与适用场景
一个服务准备接入 OpenTelemetry，团队想把 userid、requestid 和 URL 全部作为指标属性。请设计基数预算，说明哪些字段保留、超限时如何处理，以及如何证明告警仍然有用。
OpenTelemetry 指标由属性组合形成时间序列；SDK 的 cardinality limit 是每个指标在一次收集周期内可追踪的指标点上限。高基数字段会放大内存、导出、存储和查询成本，因此预算必须同时保护成本与诊断价值。
面试官考察点
面试官会看你是否能区分指标、日志和 trace 的适用维度，理解属性组合而非单字段数量，设计硬上限和降级策略，并用服务图、告警、采样和脱敏约束证明方案可运营。
回答前需要澄清的问题
先确认指标用途、查询窗口、告警延迟、租户规模、端点数量、采集周期、后端保留期限和预算。再确认是否已有 trace/log 关联字段、哪些身份字段受隐私限制，以及超限时更重视新值、旧值还是聚合准确性。
30 秒回答框架
“我先按指标用途定义允许的维度，而不是把所有上下文都塞进指标。保留稳定、低基数且能分组告警的字段，例如服务、区域、路由模板和状态类；userid、requestid 和原始 URL 放到 trace 或日志。为每个指标设置 cardinality limit、成本告警和超限观测，选择有解释性的聚合或丢弃策略。最后用历史流量回放验证告警召回、误报、查询成本和隐私要求。”
分步骤深入解答
第一步：定义指标问题
先写出要回答的问题：错误率是否升高、哪个路由受影响、某区域是否退化，还是某个用户的单次请求细节。前几类适合指标，最后一类通常应由 trace 或日志提供。
第二步：估算组合基数
基数是属性组合形成的唯一集合，而不是每个属性的取值数量简单相加。估算服务、区域、路由模板、状态码、方法和租户等级的乘积，并用真实分布、长尾和突发流量校正。
第三步：建立字段分层
保留稳定且可聚合的字段；把用户、请求和完整 URL 放入 trace/log；对高基数租户标识采用分桶、哈希或抽样，前提是仍能满足访问控制和调查需求。不要用原始路径参数制造无限新序列。
第四步：配置 SDK 与后端预算
在 SDK、Collector、时序后端和查询层分别设置预算，避免只在最后一层截断。OpenTelemetry 的指标 cardinality limit 是硬上限，具体保留哪些属性集合必须在实现和告警中可观察。
第五步：设计超限行为
明确超限时保留哪些属性组合、是否回退到溢出桶、是否丢弃新集合，以及如何计数。策略要稳定、可解释，并向运维发出“预算耗尽”信号，不能静默丢数据。
第六步：把关联性放到正确信号
用 traceid 关联单次请求，用日志保存原始 URL 或 userid，并通过 exemplars 或链接从指标跳转到样本。指标负责趋势和告警，不能替代逐请求诊断。
第七步：管理服务图与成本
服务图和自动仪表化可能产生多组指标。为边、客户端、服务端和异常状态设定单独预算，控制导出频率、保留期和高基数属性。成本报表应按服务和指标归因，而不是只看总量。
第八步：验证告警质量与隐私
用历史回放和故障注入比较有无预算时的召回、误报、延迟和查询成本。检查脱敏、访问控制、删除请求和跨租户隔离，验证超限事件、配置变更和数据丢失都可追踪。
高质量示范回答
我会先把问题分成趋势告警和单请求调查。服务、区域、路由模板、方法和状态类通常稳定且低基数，适合作为指标属性；userid、requestid 和带参数 URL 不放在指标中，而通过 trace、日志和 exemplars 关联。估算属性组合的乘积并用真实长尾修正，为 SDK、Collector 和后端配置 cardinality limit 与成本预算。超限时采用明确的溢出或丢弃规则，记录预算耗尽指标，不能静默失败。服务图边、客户端和异常状态单独设预算，控制采集频率与保留期。上线前用历史流量回放和故障注入比较告警召回、误报、查询成本、隐私和跨租户隔离，确认预算不会掩盖关键故障。
常见错误
只计算单字段取值数量
指标序列由属性组合形成，多个中等基数字段相乘后也可能爆炸。必须估算组合、长尾和突发，而不是逐列看起来都可接受。
把 user_id 放进所有指标
用户级调查更适合 trace 和日志。把身份标识放进指标会增加成本、隐私风险和查询噪声。
超限时静默丢弃
静默丢失会让告警看似正常。要记录预算耗尽、保留规则和配置版本，并验证降级后的诊断能力。
延伸追问与参考答案
路由模板和完整 URL 应如何区分？
指标使用规范化路由模板，避免每个路径参数产生新序列；完整 URL 放到受控日志或 trace，并按隐私策略脱敏。
cardinality limit 触发时应保留旧值还是新值？
取决于告警目标和聚合器，但必须固定、可解释且可观测。记录溢出计数，避免不同实例采用不一致规则。
如何关联指标、trace 和日志？
使用 traceid、spanid 或 exemplars 链接样本；指标保留稳定维度，日志和 trace 承担逐请求上下文，并在权限边界内跳转。
服务图为什么需要单独预算？
自动生成的边、客户端和异常维度会成倍增加序列。按边类型、采集频率和保留期拆分预算，避免服务图挤占业务指标。
如何证明预算没有隐藏故障？
回放真实流量并注入高基数、错误峰值和租户长尾，比较预算前后的召回、误报、延迟和查询结果，同时观察预算耗尽事件。
什么时候应增加日志而不是指标？
当问题需要单次请求、原始输入或用户级上下文时，增加受控日志或 trace；指标只承载可聚合的趋势和告警维度。