题目重点：Phone 面经明确要求设计云服务指标系统；本文用训练负载推导采集、聚合、保留、告警与高基数防护。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版采集 counter/gauge/histogram，标签含 tenant/service/region/instance，样本使用 event time；服务支持近实时 dashboard、范围查询与告警。
- 设 50 万实例，每实例 200 条活跃时序、每 10 秒一个样本，约每秒 1,000 万样本；保留原始 7 天、分钟聚合 90 天。这只是估算场景。
- 同一 series+timestamp 重试写应可去重；高基数任意 userId/requestId 不能直接当指标标签，应转日志或 trace。
解题路线
- Agent/SDK 本地聚合短窗口并批量发送，入口验证 schema、租户配额和标签长度，将样本按 tenant+series hash 分区写 durable log；传输重试附批次 ID。
- 流处理器按 event time 聚合 counter rate、histogram bucket 与分钟 rollup，处理迟到样本的修正窗口；raw 与 rollup 分不同保留层。
- 时序索引由 metricName+规范化标签集合生成 seriesId，查询计划先过滤标签再扫描时间块；热 series 分片写入后查询合并，避免单一实例的热点。
- 高基数预算在接入时测量每租户新增 series 数，超限拒绝或抽样，并给可解释诊断；不要靠压缩算法替代基数控制。
- 告警规则在流上增量计算并持久化评估状态，使用持续时间、抖动抑制、静默和缺失数据策略；通知发送需去重与重试。
- 设计 SLO 时同时量测接入延迟、样本丢失率、查询 p99、基数、告警时延与误报；故障回放从 durable log 重建聚合。
手动走一遍
service=api、region=us-east 的 request_count 每 10 秒上报。入口按 seriesId 分片，1 分钟窗口求每秒速率并保留 rollup；告警规则要求 5 分钟 error_rate>2%。若 20 秒后补到迟到错误样本，窗口允许修正并重新评估，但通知用 alert fingerprint 防重复。
规模与取舍
训练假设下 50 万×200/10≈1,000 万样本/秒；若每样本连标签与索引平均 100B，原始写入约 1GB/s、每天 86.4TB 未压缩，必须量化聚合、压缩和保留成本。查询成本随匹配 series 数 S 与时间块数 B 增长，不能只报 O(1)。
易错点与追问
容易失分的边界
- 把 userId 放进指标标签导致 series 爆炸。
- counter 直接对两个绝对值平均，而不是算增量并处理重启归零。
- 用处理时间替代事件时间又不交代迟到数据。
- 只设计写入，忽略范围查询、rollup 与长期保留费用。
- 告警每个采样点直接发通知，造成抖动和风暴。
继续深挖
- 直方图分位数怎样合并，为什么不能平均各节点 p99？
- 跨区域链路断开后，样本回补与重复去重怎样做？
- 多租户 noisy neighbor 如何限流但保住关键指标？
- 日志/trace 与 metrics 的关联如何实现？
