LinkedIn Metrics 平台：生产采集、任意粒度查询与外部可视化

题目重点：拆分 counter/gauge/分位数语义、细粒度与多级 rollup、查询边界和卡片 API；该轮不强加告警。

题意与假设

这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。

训练版指标带 tenant、metric_name、labels、event_time、value/type；题目未明确 QPS、租户数、保留期、维度基数、最大查询范围或时效 SLA。
‘任意粒度’解释为用户能指定窗口宽度和对齐方式；必须先问能否近似、最小粒度、迟到修正与分位数语义。不能承诺只存 1min 汇总还能精确回答任意 17 秒窗口。
外部可视化由拉取 API 或受控导出获取已授权的查询结果；不推定具体产品或协议。

先设计 metric contract：counter 单调累计/增量如何转换，gauge 是点采样还是时间加权平均，histogram/latency 分位数是原始样本还是可合并 sketch；标签集合与高基数上限需受控。
生产 SDK/agent 批量上报，入口认证、限流、校验时间戳和标签，再写持久缓冲；按 metric+tenant+时间分区聚合。原始或秒级数据保留短期，分钟/小时 rollup 保留更久，便于不同范围/成本的查询。
查询计划先按范围和精度选择原始细桶或 rollup；求和与计数可直接加，平均值须用 sum/count 加权，分位数不能平均两个 P95，应合并直方图或 sketch 后再估计。对未对齐的首尾时间段回读更细数据，或明确近似误差。
结果 API 返回点序列、对齐时区、窗口宽度、单位、缺失/迟到标记和数据新鲜度；外部仪表板按身份和标签权限访问。预防查询爆炸：时间范围、系列数与输出点数上限，过大的查询异步执行。
监控自身健康：采集 lag、丢弃率、标签爆炸、rollup 与 raw 对账；若后续新增告警，在相同指标语义上另建规则评估，但不把它强塞进该轮基础需求。

服务 A 每秒上报成功请求计数和延迟样本。5 分钟请求量是计数增量之和；两分钟平均延迟用 (sum₁+sum₂)/(count₁+count₂)，不能把两分钟平均值直接取算术平均；五分钟 P95 需合并延迟分布摘要。查询 [10:00:05,10:01:22) 不能只读整分钟桶就声称精确。

设每秒 S 个活跃时间序列、每序列写入率 R，摄入约 S×R 点/秒；标签笛卡尔积可能让 S 远大于服务数。保留 D 秒的原始数据约 O(SRD) 点，rollup 按聚合层级另计。查询扫描 B 个目标桶与 G 个系列，朴素约 O(BG)，实际受索引、压缩和分片合并影响；题目无数值，不填机器台数。