题目重点：分开日志持久采集、按时间与关键词查询、持续告警，处理重试和高基数。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 题目只给log scanner SD；练习支持按service/time及literal关键词查询，并独立订阅错误模式告警。实际parser、保留期、规模未给。
- 日志可能含敏感字段，需要在采集侧按规则脱敏；字面查询与regex查询有不同索引和执行成本。
解题路线
- agent给每条eventId、eventTime、service、host和序号，批量送持久队列；本地buffer有上限及丢弃/背压策略。确认接受不等于索引已经可查，API区分ingested/indexed位点。
- 原日志按日期/service分区压缩对象存储，近窗索引支持倒排和时间过滤。先粗筛service/time再查关键词，避免所有历史日志全文扫；索引丢失可由原流重建。
- 告警是流式规则状态，不等于定期重跑整个搜索。按规则key维护阈值/窗口、迟到政策、告警去重和恢复状态；再用通知outbox处理重试。
- schema evolution和高基数标签受预算控制，不能把userId等所有字段都放metrics标签。查询分页保留snapshot/游标，避免新增日志使同页重复/漏行。
手动走一遍
agent发出batch后ACK丢失，重发同eventId不产生双日志和双告警。error在索引前已入流，可触发告警但尚不可检索，界面显示索引延迟；冷日志搜索按日期扫描明确有更高延迟。
规模与取舍
假设1TB原日志/日、热窗7天则原量7TB，索引/副本/压缩系数分开；平均写量约11.6MB/s，峰值另测。查询成本由候选posting与扫描字节决定，不是固定O(log N)。
易错点与追问
容易失分的边界
- 把日志、metric与trace当同一schema存储。
- 无界本地buffer让故障反过来撑爆应用磁盘。
- 重复事件导致重复告警，没有恢复/抑制状态。
继续深挖
- 如何支持跨行stacktrace拼接而不吞掉下一事件？
- regex无倒排锚点时怎样限时、限范围或转冷查询？
