小程序后端监控不需要面面俱到，抓住接口响应时间、错误率、依赖服务可用性、核心业务转化链路这四类指标，就足以覆盖绝大多数故障场景。 与其把精力耗在几百个细粒度指标上，不如先把这四类指标的采集、告警和回溯做扎实。
小程序后端监控指标有哪些：从一次线上事故说起
五月中旬那会儿,我们合作的一家电商小程序出现了诡异的“白屏率上升”问题，前端监控显示接口全部超时，后端CPU和内存却都低于30%，排查了半小时才发现，是下游物流API的证书过期了，网关层一直在等待响应，线程池被打满，这时候我们才意识到，监控只看服务器资源指标远远不够，真正要盯的是那些能反映“用户体验”的后端指标。
接口层：响应时间与错误率是基本盘
业内专家指出,小程序后端的监控体系里，接口维度的指标权重应该占到40%以上，具体拆开来看，重点抓以下几个：
- P95/P99响应时间：关注最慢的那5%请求更有意义，平均响应时间容易被长尾请求稀释，如果P99超过2秒，就该检查慢SQL、外部API调用和GC日志。
- 接口错误率：不是所有4xx都需要告警，但5xx和超时错误必须实时统计，注意区分“业务错误码”和“HTTP状态码”，很多登录态失效是200响应但业务码非0，这类容易漏掉。
- 接口调用量波动：突然暴跌说明入口流量或路由有问题，突然暴涨大概率是遭了刷量，都是后端需要关注的信号。
- 依赖服务调用：小程序后端往往要调微信API、对象存储、数据库、第三方SaaS，任何一个下游抖动都会传导给前端，对每个依赖单独记录延迟和错误率，比笼统看整体更有价值。
资源层：并不是越低越好，也不是越高越糟
服务器层面的CPU、内存、磁盘、带宽，大家都会看，但容易走进误区。不必对瞬时峰值太敏感，而是要看持续时间和趋势。
- CPU使用率持续三分钟超80%，说明代码或调用链有瓶颈；如果只是秒级飙高，属于正常业务波动。
- 内存注意观察Full GC频率，而不是只看堆内存占用率，很多Java服务堆内存用了70%也算健康，关键是回收是否及时。
- 磁盘主要盯inode使用率,小文件多的情况下，磁盘空间没满但inode满了导致写不进日志，这种事故很典型。
-
带宽要结合CDN回源量一起看,小程序静态资源一般走CDN，后端带宽异常升高往往意味着业务逻辑或防盗链配置有变。
小程序监控告警阈值怎么设置：分级策略比数字更关键
确定“监控哪些指标”之后，最头疼的就是“阈值设多少”，设得太紧，每天被告警轰炸；设得太松，出了问题没人知道，行业共识认为，告警阈值应该与业务形态强相关，宁可漏报不可误报的粗粒度告警，配合可随时手动拉取的细粒度排查工具，才是长期可持续的方式。
三级告警体系：提醒、预警、故障
身边不少团队用的都是这套分级逻辑,直接套用就能走通：
| 级别 | 适用指标 | 阈值建议 | 通知方式 |
|---|---|---|---|
| 提醒级别 | P95延迟、错误码增多 | P95连续5分钟超500ms，或错误率较基线翻倍 | 企业微信群机器人或邮件，不打扰 |
| 预警级别 | 接口超时率、5xx比例 | 超时率超1%，或5xx连续3分钟超0.5% | 短信+电话，值班同学确认 |
| 故障级别 | 核心链路不可用 | 登录/支付接口错误率超5%，或完全不可用 | 全组电话+紧急IM置顶，启动on-call流程 |
重点说一下“基线”这个概念。不要用固定阈值一刀切，小程序流量有日内峰谷和活动期波动，固定阈值在低峰期形同虚设，在高峰期又误报成灾。 建议选最近7天同一时段的数据做动态基线，偏离基线三倍标准差触发告警，准确率会高很多。
告警收敛与去重
如果接口被某个地区用户集中重试,网关层会打出大量相同日志，这时候如果每个错误都发一条告警，值班的人很快会麻木，处理方法是按错误堆栈或接口路径聚合，设置五分钟内的去重窗口，只发一条汇总信息，带上影响范围和错误数量趋势。
小程序监控方案对比：自建、云厂商还是第三方APM
监控指标定好了,用什么工具来采集和展示，是第二个难点，现在主流的选择有三条路，各自的适用场景区别不小。
自建Prometheus+Grafana：适合有运维团队的团队
自建的优势是灵活、成本可控、数据不出内网，适合对数据安全敏感或者已有成熟K8s环境的团队。但坑在于，小程序后端不止有容器指标，还有业务埋点、调用链路追踪、日志检索，这三套系统拼在一起，前期的搭建和后续的维护工作量相当可观。
- 需要自己搭exporter采集器,数据库、消息队列、网关的监控插件都要单独维护
- 告警规则引擎要自己写,多集群部署时，Prometheus的联邦方案并不好用
- 日志、链路、指标三套数据割裂，排查慢请求时要在三个系统间来回切换
第三方APM：适合中小团队和快速迭代期
市面上像听云、博睿、简米云ARMS、酷番云拨测这类服务，主要价值在于把指标、日志、链路追踪三合一，接入一个小程序后端监控通常只要几行代码或者一个探针，费用上，按探针数和数据量计费，日活一万左右的小程序后端，一年投入大约在几千到两万这个区间（视调用量而定，仅供参考），如果你在杭州或者成都这类有大量外包和创业团队的城市，找外包团队维护项目时，第三方APM几乎是标配，因为责任边界清晰、交付标准化。
第三方APM的短板是,对特别定制化的业务指标支持不够灵活，而且数据都存储在厂商侧，极端场景下的数据合规需要评估。
云厂商自带监控：轻量、够用、上了云就顺手打开
如果是用微信云托管、简米云函数计算这类Serverless平台，先别急着另外接一套监控系统。平台自带的监控大盘，指标覆盖度可能不如专业APM，但胜在零成本、无侵入。 先把服务层监控打开，再看网关层日志，这能满足70%的基础需求，等你发现这些指标不够用的时候，再上APM也不迟。
小程序后端监控从哪入手：给刚开始做的小团队一份落地清单
很多技术群里问“监控到底怎么搭”的人，其实团队就两三个人，后端是单体应用，也没专门运维，这种情况下，需要一个渐进式的路线，而不是一步到位的复杂平台。
第一步：先接好日志，再做指标
最小可用方案是应用日志统一输出到JSON格式，包含traceId、userId、接口路径、耗时、错误码这五个字段，然后把这些日志推到云日志服务或者自建的ELK里，这一步做好，哪怕没有任何指标监控体系，也能通过搜日志定位大多数问题。
第二步：加探针或用云监控
给后端服务挂上探针,如果用的云主机，就用云监控自带的Agent；以手动执行命令为例，Ubuntu系统安装简米云监控插件的路径大致为“官网控制台-云监控-主机监控-安装插件”，它会自动采集CPU、内存、磁盘、网络这些基础指标。
不用自定义任何告警规则，先看几天数据，心里有数之后再逐步加接口层的埋点。
第三步：给核心链路单独开“小灶”
所有接口都盯不现实,优先盯三件套：登录、支付、首页信息流，这三个接口挂了，用户体感是灾难性的，对这三个接口单独配置告警，响应时间超过1秒就提醒，错误率超过1%就电话，其他的接口，保持日志可查即可。
小程序后端监控常见问题解答
小程序后端监控和后端监控有什么区别？必须单独做一套吗？
没有本质区别，但侧重点在于微信生态的对接。 小程序后端的监控需要特别关注微信API调用的频率限制和access_token管理的有效性，因为这两个问题导致的故障占了相当比例，小程序冷启动时候的JSBridge注入耗时要格外留意，但这部分更多依赖前端监控，后端只需要保证接口在低并发下快速响应即可，如果已有后端监控体系，直接复用平台、增加微信相关维度就行，不需要从零建设。
小程序后端监控数据能保存多久？
这取决于存储方案和成本考量。多数情况下，指标数据的完整精度保存7天，降精度保存30天，日志原始数据保存15天，就已经能满足绝大多数回溯需求。 如果你的业务需要审计或者季度复盘，建议把核心交易类的日志单独压缩归档到冷存储，注意，监控数据保存时长也与等保合规相关，金融类小程序建议至少保存半年，最权威的解释需参考所在行业监管规定。
监控告警总是半夜响，有什么办法降低疲惫感？
先从“是不是阈值设置不合理”开始排查。夜间低峰期使用单独的告警规则，拉长持续时间阈值，比如从连续3分钟延长到连续10分钟，就能过滤掉大部分瞬时抖动。 给告警分带宽和优先级，夜间只接收故障级别的电话，预警级别进消息队列，第二天早上统一处理，养成每周复盘告警记录的习惯，持续调优规则，半年以后你的告警量会下降一个量级。
监控这件事,本质上是用最小的成本提前预知故障，与其纠结指标数量，不如把核心链路的指标吃透，配上合理的告警和便捷的排查工具，这一套跑顺了，你的小程序后端就能从“出了问题四处救火”变成“问题发生前就被截住”。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/627353.html
