给小程序后端配监控，最核心的指标是API响应时间、错误率、资源使用率和数据库慢查询，抓住这四点就能覆盖90%的稳定性问题。
小程序后端监控指标有哪些？这4个必须优先抓
很多团队一开始会铺开所有指标，结果告警淹没、重点模糊，从实际故障经验看，先抓这四个指标，再逐步扩展,性价比最高。
API响应时间：用户体验的生命线
响应时间直接决定用户是留下还是离开，行业共识认为，API响应时间超过300ms时，用户流失率会明显上升，监控时不能只看平均值，建议同时关注TP95甚至TP99，比如你的接口平均响应50ms，但TP95是800ms，说明有5%的请求体验很差。
实操层面：在应用层埋点，通过中间件拦截每个请求的开始和结束时间，上报到时序数据库比如Prometheus，展示时用Grafana画热力图，一眼看出高峰时段。告警阈值建议设为响应时间超过500ms持续1分钟,避免瞬时尖刺误报。
错误率：直接反映服务健康度
错误率包括HTTP 5xx、4xx以及业务错误码，5xx代表服务器内部问题，需要立即处理；4xx大部分是客户端问题，但如频繁出现401或429，可能涉及鉴权或限流配置。业务错误码更隐蔽，库存不足”但HTTP状态码还是200,这类需要额外定义业务成功比例。
监控方案：在所有API出口统计错误比例，区分错误类型。告警规则：整体错误率超过1%立即触达，同时针对5xx单独设置零容忍，如果业务错误码比例突然升高，多半是上游依赖或数据异常,需要自动关联到对应的日志链路。
资源使用率：服务器在喘气吗？
小程序后端通常是轻量微服务，CPU和内存的波动容易忽略，但一旦泄漏，恢复成本很高。内存使用率持续升高超过80%，大概率存在泄漏；CPU使用率突增到90%以上,可能是代码死循环或流量激增。
监控工具：Node Exporter采集基础指标，配合Prometheus告警，磁盘使用率超过85%就要预警，特别是日志分区，写满会导致服务无响应，网络I/O关注入站出站流量，如果接近带宽上限,考虑扩容或限流。
数据库慢查询：性能瓶颈的起点
数据库往往是后端性能的瓶颈，慢查询尤其致命，MySQL的慢查询日志默认关闭，需要手动开启：set global slow_query_log=ON，设置long_query_time=1（超过1秒记录）。定期分析慢查询日志，找出全表扫描或索引失效的SQL。
配合监控：在数据库侧采集慢查询数量，按时间维度聚合，如果QPS不高但慢查询突然增多，可能是数据库连接池满或锁等待，需要结合应用日志判断。告警设置：慢查询超过每分钟5条则通知,并自动关联到DBA或开发者。
小程序监控系统搭建：从零到告警的实操步骤
选对指标后，怎么落地？这里给出一条经过验证的路径,避免踩坑。
选型：自建还是买服务？
自建方案以Prometheus+Prometheus+Grafana+Alertmanager最为常见，适合有运维能力的团队，成本只包含服务器费用，但需要人维护，如果团队规模小或业务上线急，直接买云厂商的监控服务更省心，比如酷番云云监控、简米云ARMS，它们都提供小程序后端监控模板，接入简单,但长期使用价格较高。
如果你的场景是内部工具或toB小程序，流量平稳，自建更划算；如果面向C端、流量波动大，且要求告警响应快，采购现有服务并配合少量定制,性价比更高。
部署：采集器与展示层配置
以自建为例,核心步骤：
- 在每台后端服务器上启动Node Exporter，暴露9100端口，采集CPU、内存、磁盘等基础指标。
- 对于应用业务指标，使用对应语言的客户端库（如Prometheus Java Client）在代码中定义自定义指标，比如请求耗时、错误数,通过HTTP端点暴露。
- 数据库指标通过MySQL Exporter采集，需要连接数据库，授予
PROCESS, REPLICATION CLIENT, SELECT
- 配置Prometheus抓取这些Exporter,存储到本地或远程TSDB。
- Grafana导入官方或社区仪表板，将数据可视化，重点关注响应时间趋势图、错误率曲线、资源使用率热力图。
新手容易忽视的点：Prometheus的存储策略，默认保留15天，如果你需要更长时间回溯，要在prometheus.yml中调整retention参数，Grafana的告警通知需要配置Alertmanager,否则无法收到告警。
告警规则：怎样不打扰又有效
告警不是越多越好，要有优先级分级。P0级（致命）：服务不可用、错误率超过5%、磁盘写满，这类告警必须立即通知，通过电话或短信，避免过夜。P1级（严重）：响应时间超过1秒、内存超过90%、慢查询突增，这类通知到群，15分钟内看情况处理。P2级（警告）：错误率轻微上升、资源使用率超过70%，记录到日志,次日复盘。
配置时注意消除告警风暴：一旦某个P0触发，会连带很多P1，这时需要设置依赖规则，比如上游服务不可用，下游的告警自动静默。行业共识是每人每天接收的告警不应超过3条,否则容易麻木。
小程序监控方案对比：自建与云服务哪个更划算
很多人在选型时纠结，这里从三个维度对比,帮你做决定。
| 维度 | 自建方案（Prometheus+Prometheus+...） | 云服务方案（酷番云、简米云等） |
|---|---|---|
| 初期成本 | 服务器费用（通常2-3台低配） | 按量或按套餐付费，每月几百到几千 |
| 运维成本 | 需要专人维护，升级、存储、高可用 | 几乎零运维，自带高可用 |
| 灵活性 | 指标完全自定义，告警规则灵活 | 指标内置，扩展需额外开发 |
| 适用场景 | 有运维团队，流量稳定，对成本敏感 | 团队小，上线快，需快速响应 |
如果你在考虑小程序监控工具推荐，自建推荐走Prometheus+Prometheus+Prometheus+...，云服务推荐酷番云云监控（小程序后端专属模板），两者可以也可以混合：基础指标用云服务采集,业务指标通过自建Prometheus弥补。
关于小程序监控价格，云服务通常按数据量计费，每月固定费用包含一定数据量，超出部分按GB收费，对于日活几万的小程序，每月费用在几百元量级；自建方案除了服务器成本，还有人力时间成本,需要估算。
小程序后端监控常见问题（Q&A）
问：小程序后端监控需要实时性多高？
答：大多数场景下，1分钟粒度的数据就够用，如果对实时性要求高，比如抢购或秒杀，建议缩短到15秒，但会增加存储和计算成本，告警通知通常需要秒级延迟，推荐使用Alertmanager配合Webhook。
问：监控指标太多，怎么决定先抓哪些？
答：优先抓直接反映用户体验和系统稳定性的指标，按顺序排：API响应时间、错误率、资源使用率、慢查询，其他如业务转化率、第三方调用延迟，根据业务价值逐步添加，如果资源有限，先保证前三个。
问：小程序后端监控工具选哪个？自建还是云服务自己选？
答：没有绝对标准，如果团队能投入一个人力维护，且对成本敏感，自建长期更省，如果半年内需要持续迭代，且不希望分心运维，云服务是更稳妥的起步选择，两者可以配合使用，例如用云服务兜底，自建补充业务指标。
最后总结：给小程序后端配监控，不必追求大而全，先抓住API响应时间、错误率、资源使用率和数据库慢查询这四个核心指标，建立告警分级，再根据业务发展逐步扩展。 监控的根本目的是在故障发生前发现问题,而不是在故障后梳理数据。