题目重点：从异常事件入库到 oncall 的 Top K 视图，定义指纹、去重、时间窗、schema 与重算。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版 Top K 按指定时间窗口内同一错误指纹的事件数排序，支持 service/tenant/env 过滤；真实题目需要确认是次数、受影响用户、严重度还是最近增幅。
- 异常事件可能因重试被重复发送；服务端用 event_id 幂等去重，无法保证所有业务重复事件天然同 ID。
解题路线
- SDK/agent 在异常边界采集 event_id、tenant、service、env、event_time、exception_type、message_template、stack frames、release、trace_id 与可控标签；本地批量缓冲、限流和脱敏，入口认证并写耐久队列。
- 指纹要把动态 ID/时间戳从 message 归一化，结合异常类型和稳定 stack frame；不同版本栈行号变化要避免同一根因碎裂，也不能把所有错误粗暴合成一类。保存 fingerprint_version 便于重算。
- 原始事件按租户/时间分区存短期可查索引；聚合流按 window+fingerprint+service 更新计数与受影响用户估计，保留 event_time/watermark 处理迟到数据。
- 查询先由 `(tenant,service,env,window)` 找聚合，再排序或维护有限 Top K；oncall UI 显示数量、趋势、最近首见/末见、样例 stack 和指纹版本。高基数 message、trace_id 不直接进入聚合 key。
- schema 具体列含 raw_events(event_id,event_time,ingest_time,tenant,service,env,fingerprint,stack_ref,release,trace_id)、window_counts(window_start,window_size,tenant,service,env,fingerprint,count,updated_at)。原始 stack 放外部 blob 以免聚合表膨胀。
- 回放和对账用 raw 重建聚合；若未来要告警，规则评估可复用聚合，但不是本轮 Top K 基础题必需。
手动走一遍
同一个 NullPointerException 含不同订单 ID 的 message 被规范成同一 fingerprint；10 分钟内 1,200 次上报中 200 次是重复 event_id，计数 1,000。oncall 查该服务过去 10 分钟 Top K，看指纹、趋势和样例 trace。
规模与取舍
入口每秒 E 事件，raw 存储随 E×保留时间增长；活跃窗口有 F 个指纹，精确聚合 O(F) 状态，查询排序 O(F log F) 或以大小 K 的堆 O(F log K)。题目没有 E/F/K 数值，需问目标规模。
易错点与追问
容易失分的边界
- 只讲 heap Top K，不讲异常采集和 schema。
- 把完整 stack/message 作聚合键导致高基数爆炸。
- 重复 SDK 重试事件算多次。
- 迟到事件改变旧窗口却没有修正/水位策略。
- 把这个设计题与另一个 AlertMonitor Coding 的具体方法混题。
继续深挖
- 错误 message 含 PII 怎样脱敏？
- 部署新版本后 stack 行号变化，指纹如何保持稳定？
- Top K 按次数与按受影响用户数会怎样不同？
- 短时间突增但总量不高的异常如何发现？
