Amazon Metrics Monitoring：时间序列、查询和告警

题目重点：设计指标采集、窗口聚合、迟到处理与告警状态，控制高基数标签。

题意与假设

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

明确问metrics monitoring，无吞吐/保留期。练习支持counter/gauge、service标签、时间范围图表和阈值告警；histogram需要另外定义bucket schema。
指标通常容许有限延迟但关键告警有单独预算。缺测不等于数值0，不能把无数据当服务恢复。

采集sample含metricName、labels、eventTime、value和source序号，按seriesKey分区。校验类型/标签预算，counter reset、gauge瞬时值和histogram桶不能用同一sum处理。
TSDB按时间块存储，近窗细粒度、旧窗降采样；查询按series/时间定位块再聚合。降采样保存sum/count/min/max等所需统计，不把平均的平均当全局平均。
写重试按source/sequence或可替换timestamp合同去重；同timestamp多样本需定义替换还是合并。watermark控制迟到窗口修正，图表说明数据延迟，不让接收时间假装事件时间。
alert rule计算窗口并维护pending/firing/resolved，for持续时间、抖动hysteresis和通知抑制分开。通知outbox去重，恢复也要有证据，缺测按no-data策略报警/保留。
高基数标签使series数量爆炸，userId/requestId更适合trace/log。用摄入配额与schema治理限制新增series，监控平台自身队列、存储和告警路径，不能靠它唯一自证健康。

counter从100到5可能进程重启，差量不能当−95请求。CPU指标缺了两分钟不能当0%宣布恢复。一次规则firing重复通知重试用同alert instance键；resolved需实际恢复样本。

状态规模由活跃series S×sample频率×保留期决定：100万series每10s一次为10万samples/s，不是100万用户/日能替代估算。100B/sample裸payload约10MB/s，索引/压缩/副本另算。