面试必问：通知平台的监控与告警怎么设计？这次彻底讲透

通知平台的监控与告警怎么设计？一次讲清发送成功率、渠道健康度、回执延迟与失败追踪

大家好，我是一名有 4 年工作经验的 Java 后端开发。
通知平台一旦做成基础设施，它最怕的往往不是“偶尔失败一条消息”，而是问题积累了很久都没人知道。
这篇文章我想系统聊一聊通知平台的监控与告警到底应该怎么设计。

🦅个人主页
🐼

一、为什么通知平台特别需要业务监控

因为通知系统最典型的问题通常不是：

• CPU 高
• 内存高

而是：

• 发送成功率下降
• 某个通道异常
• 某类消息堆积
• 回执延迟明显上升

如果只盯机器监控，很多问题会发现得很晚。

二、最关键的监控指标有哪些

我更建议至少看这些：

• 发送总量
• 发送成功率
• 发送失败率
• 各渠道耗时
• 各渠道回执延迟
• MQ 积压量
• 手工补发量
• 未读消息堆积量

这些比单纯 CPU、内存更有业务价值。

三、最关键的告警场景

例如：

• 短信成功率异常下降
• Push 通道回执明显延迟
• 某渠道大量失败
• MQ 消息堆积持续上升
• 模板渲染异常激增
• 未读消息同步失败

这些都应该有清晰的高优先级告警。

四、最容易踩的坑

4.1 只监控服务机器

业务问题根本看不出来。

4.2 只看失败数，不看成功率和趋势

很容易误判。

4.3 没有按渠道拆指标

后面不知道是哪条通道有问题。

4.4 告警没有分级

团队会很快疲劳。

实战案例：放到真实项目里会怎么跑

比如短信渠道某一分钟成功率从 99% 掉到 70%，平台最好在业务投诉之前就能先告警，而不是靠运营第二天看日报才发现。

1. 先按渠道、场景、供应商维度汇总发送成功率。
2. 再盯送达回执延迟和回执缺失率。
3. 某个窗口期成功率连续低于阈值就告警。
4. 告警文案要直接带上失败样本和最近错误码分布。

Java 代码示例

@Service@RequiredArgsConstructorpublicclassNotificationAlertService{privatefinalNotifyMetricRepositorymetricRepository;privatefinalAlertGatewayalertGateway;publicvoidscanChannelHealth(Stringchannel){NotifyMetricmetric=metricRepository.aggregateLastFiveMinutes(channel);if(metric.getTotalCount()<100){return;}doublesuccessRate=metric.getSuccessCount()*1.0/metric.getTotalCount();if(successRate<0.95){alertGateway.send("通知渠道告警",channel+" successRate="+successRate+", failCount="+metric.getFailCount());}}}

SQL 示例

SELECTchannel,COUNT(*)AStotal_count,SUM(CASEWHENstatus='SUCCESS'THEN1ELSE0END)ASsuccess_count,SUM(CASEWHENstatus='FAILED'THEN1ELSE0END)ASfail_countFROMnotification_send_logWHEREcreated_at>=DATE_SUB(NOW(),INTERVAL5MINUTE)GROUPBYchannelHAVINGSUM(CASEWHENstatus='SUCCESS'THEN1ELSE0END)/COUNT(*)<0.95;

五、面试中怎么回答

如果面试官问你：

通知平台的监控和告警一般怎么做？

你可以这样回答：

第一，我不会只监控通知平台的机器指标，而会更关注业务指标，比如发送成功率、渠道失败率、回执延迟、MQ 堆积和未读消息积压，因为这些才真正反映通知平台对业务的影响。

第二，我通常会把指标按渠道拆开看，比如短信、邮件、Push、站内信分别统计，这样一旦出现异常能更快定位问题在具体通道还是平台公共层。

第三，告警上我会特别关注发送成功率异常下降、回执延迟升高和消息积压这几类高优先级问题，因为它们通常意味着通知能力已经开始明显影响业务。

六、总结

通知平台监控真正难的，不是“有图表”，而是能不能及时知道：

• 哪个渠道坏了
• 哪批消息没发出去
• 哪种通知体验在变差

如果只记一句结论，我觉得可以记住这句：

通知平台真正有价值的监控，不是机器资源，而是“发送、回执、积压、用户感知”这条业务链路的健康度。

七、结尾

如果你觉得这篇文章对你有帮助，欢迎点赞、收藏、关注。
后面这个通知平台系列最后一篇我会从整体架构视角做总结收束。