短信平台的数据监控架构设计
在国际短信或验证码业务里，“能发出去”只是基础，“可观测、可追溯、可实时定位问题”才是平台稳定性的核心。很多短信平台真正拉开差距的，不是通道资源，而是数据监控体系的设计能力。
这篇从工程视角，拆一下短信平台的数据监控架构怎么做才算“能打”。
一、短信监控到底在监什么？
一个完整的短信生命周期，大致分为：
提交 → 网关接入 → 路由分发 → 通道发送 → 运营商回执 → 最终状态回传
监控体系需要覆盖三类核心数据：
1）链路状态数据（核心）
submit 是否成功
进入哪个路由
是否发送成功
运营商回执状态（DELIVRD / FAIL / UNKNOWN）
延迟（端到端耗时）
2）业务指标数据（经营层）
成功率（成功/提交）
到达率（DELIVRD/发送）
各国家/运营商维度表现
不同模板/业务线表现
3）异常与风控数据（稳定性）
突发失败率
黑名单拦截
通道抖动
重复提交 / 异常流量
二、整体架构：三层数据流设计
一个成熟短信平台的数据监控，一般是“三层结构”：
第一层：数据采集层（埋点层）
来源包括：
API 网关日志
短信路由服务日志
MQ 消息流（例如状态回执）
通道侧 callback
运营商回执推送
这里推荐统一用事件模型：
SmsEvent { msg_id app_id country operator channel status latency timestamp }关键点：所有数据必须围绕 msg_id 打通链路
第二层：实时计算层（核心大脑）
这一层通常用流式计算系统处理：
去重
状态聚合
实时成功率计算
延迟分位数计算（P95 / P99）
异常检测
常见技术组合：
Apache Kafka（承载事件流）
Apache Flink（实时计算）
典型处理逻辑：
5分钟窗口成功率
国家维度失败率突增检测
通道异常漂移检测
例如：
当某通道 5 分钟失败率 > 平均值 3 倍 → 触发告警
第三层：存储与分析层
这一层分两种数据用途：
1）实时监控（秒级）
用于大屏 & 告警：
Prometheus：采集指标
Grafana：展示大盘
常见指标：
TPS（每秒短信量）
成功率
延迟分布
通道健康度
2）离线分析（分钟~小时级）
用于运营分析 / 报表 / 优化：
ClickHouse：存储明细数据
Elasticsearch：日志检索
应用场景：
按国家分析短信成功率
按渠道对比成本与转化
历史趋势回溯
SLA 结算依据
三、关键设计点：短信监控的“坑位”
1）链路必须可追踪（Traceability）
很多系统的问题是：
“知道失败了，但不知道在哪一步失败”
解决方式：
msg_id 全链路贯通
每一步都打状态事件
形成完整时间线
最终可以还原：
提交 → 路由A → 通道B → 运营商 → FAIL（超时）2）状态一致性问题（最容易出事故）
短信状态常见冲突：
通道回调成功，但运营商失败
回执延迟（小时级）
重复回执
解决方法：
状态机设计（不可逆状态）
以最终回执为准
引入“迟到数据修正机制”
3）实时性 vs 成本的平衡
监控系统有两个目标冲突：
实时性（秒级告警）
成本控制（存储 & 计算资源）
实践方案：
热数据走 Flink + Prometheus
冷数据进入 ClickHouse
日志进入 Elasticsearch
分级存储（Hot / Warm / Cold）
4）异常检测不能只靠阈值
传统方式：
成功率 < 95% → 告警
问题：
不同国家基线不同
不同通道波动不同
进阶方式：
基于历史均值 + 标准差
分国家/运营商建模
引入滑动窗口对比
四、监控大盘设计（建议结构）
一个成熟短信平台大盘通常分四块：
1）全局概览
TPS
成功率
平均延迟
当前告警数
2）通道维度
各通道成功率排名
通道负载
通道健康评分
3）国家/地区维度
成功率地图
延迟热力图
失败集中区域
4）业务维度
验证码 / 营销短信分开统计
不同 app_id 表现
五、一个核心原则：监控不是看数据，是定位问题
很多团队把监控做成：
“看起来很全，但出了问题还是找不到原因”
真正有效的设计要满足三点：
1）能发现问题（Detection）
实时异常捕捉
2）能定位问题（Diagnosis）
定位到：
哪个国家
哪条通道
哪个时间窗口
哪个业务线
3）能复盘问题（Debug）
完整链路回放能力
六、总结
短信平台的数据监控，本质不是“展示指标”，而是构建一套：
从事件流 → 实时计算 → 存储分析 → 问题定位的闭环系统
真正成熟的架构一定具备：
全链路 trace
实时 + 离线双体系
多维度指标分层
异常检测智能化
可回放能力
如果只做 dashboard，而没有链路和计算体系，本质上只是“数据展示工具”，不是“通信监控系统”。