解读

国内生产环境普遍采用“日志→告警→短信→值班”链路，短信费用按条计费且易触发运营商限流。性能测试工程师不仅要压出瓶颈，还要在结果治理阶段把“海量告警”变成“可行动信息”。题目把“日志聚类”作为前提，意味着已经通过 Flink CEP、ELK 聚类插件或自研算法把原始日志切成 N 类，现在要在“类内”再做一层“合并”，把 1000 条短信压到 50 条，降幅 95%，同时保证不丢核心故障信号。面试官想考察的是：

1. 对“告警风暴”根因的理解（重复、抖动、依赖叠加）；
2. 对“合并”策略的量化设计（窗口、维度、阈值、衰减）；
3. 对“ SLA 与用户体验”的权衡（延迟 vs 去重率）；
4. 对国内常用监控生态（夜莺、蓝鲸、阿里云 SLS、企业微信机器人）的落地经验。

知识点

1. 告警维度模型：WHO（集群、应用、接口）、WHAT（错误码、Exception 类）、WHERE（机房、可用区）、WHEN（时间戳、版本）。
2. 相似度算法：余弦相似度（TF-IDF）、Jaccard（日志模板 ID 集合）、Levenshtein（模板文本）、SimHash（长日志）。
3. 合并窗口：滑动时间窗（Tumbling/Sliding）、计数窗（每 N 条合并）、会话窗（静默 30s 断开）。
4. 抑制策略：
   递增抑制（exponential backoff）：2 的 n 次方条或分钟级倍增；
   梯度抑制（severity 升级）：同模板 INFO→WARN→ERROR 只升不降；
   依赖抑制（因果链）：下游 502 因上游 504 引起，只发根因。
5. 性能测试专属场景：
   压测期间同一“并发阶梯”产生的同类告警应归并到“阶梯标记”上，方便回溯 TPS 与 RT 曲线；
   容量告警（CPU>90%）与业务告警（RT>2s）需分层合并，避免“资源类”淹没“业务类”。
6. 国内合规：短信内容≤70 汉字，含签名，变量需占位符，否则会被运营商拒收。
7. 可观测闭环：合并后的“代表告警”必须携带“首次/末次时间、出现次数、影响样本 traceId”，方便值班人员一键下钻。

答案

整体思路是“先聚类、再合并、最后采样”，分四步落地：

第一步：统一告警模型
把聚类结果映射成五元组（app_id, template_id, error_code, az, version）作为“合并键”。template_id 由日志模板算法生成，确保“相似”日志落到同一 ID。

第二步：双层窗口合并

1. 快速滑动窗（30s）：同合并键的告警在 30 秒内只发一条“代表”，携带 count=1；后续每新增一条 count++，但不发短信，只在监控系统内部累加。
2. 慢速阶梯窗（5min）：若 30s 窗内 count 达到 10 或持续时间跨 5 分钟，则再发一条“升级短信”，内容模板：
   【网易严选】性能压测-支付接口502异常，template=tmpl_123，近5min共87次，最新traceId=acbd，请查看。
   这样既保证实时性，又把 87 条原始告警压缩成 2 条短信。

第三步：抖动过滤
对“瞬间自愈”类告警（如 Full GC 单次 3s 后恢复）增加“最小持续阈值”：只有连续两个周期（1min）仍存活才触发短信；否则只记日志，不告警。经验表明可再降 30% 短信。

第四步：采样与权重兜底
设置“单日短信预算”=50 条，采用“令牌桶”算法：

• 致命（P0）告警无限令牌；
• 高优（P1）每秒生成 1 个令牌；
• 普通（P2）每 10 秒生成 1 个令牌；
• 低优（P3）只走邮件/IM，不发短信。
  压测期间提前把“P2 以下”全部降级到企业微信群，确保短信通道只留给“容量爆表、线程池耗尽”等关键项。

通过以上四步，我们在最近一次双 11 全链路压测中把 1 万条原始告警聚类成 1200 类，再经双层窗口+抖动过滤+令牌采样，最终发出 48 条短信，达成“1000→50”目标，且 P0 故障无漏报，平均告警延迟 <35s，满足 SLA。

拓展思考

1. 如果业务方坚持“每条告警都必须可查”，可引入“告警链”追踪：把合并后的代表告警 ID 写入 Trace 系统，值班点击短信里的 traceId 即可展开所有被合并的原始事件，实现“压缩率”与“可审计”双赢。
2. 在多云架构下，不同云厂商的短信通道延迟差异大（国内主通道 35s，备用通道 1530s）。性能测试阶段可模拟“通道降级”场景，验证合并逻辑在极端延迟下是否仍按窗口触发，避免“窗口过期导致雪崩式补发”。
3. 未来可接入“生成式 AI 摘要”：把同一模板下的 200 条日志丢给私有化部署的大模型，自动生成 30 字中文摘要，替换固定模板，进一步降低短信长度，提高值班阅读效率。