微服务接口成功率监控需明确定义“成功/失败”口径，统一采集http/rpc/业务层失败指标，用prometheus counter打标聚合，通过promql计算并告警，结合链路追踪验证根因。
监控微服务接口的成功率，核心是准确识别“成功调用”与“失败调用”，并在统一口径下持续采集、聚合、告警。它不是单点检查，而是贯穿调用链路的指标沉淀。
明确成功率的定义和统计口径
成功率 = 1 −（失败请求数 ÷ 总请求数）× 100%。但关键在于“失败”怎么判：
- HTTP 层失败：状态码 ≥ 400（如 404、500、503），需注意 4xx 中部分业务异常（如 401、403）是否纳入失败——应按业务语义区分，建议单独打标，不直接计入成功率分母
- RPC 层失败：超时、连接拒绝、序列化错误、服务不可达等底层异常，这类必须计入失败
-
业务层失败：如企业微信接口返回
{"errcode": 40013, "errmsg": "invalid user"}，属于业务逻辑错误，建议通过埋点打标为business_error_40013，可计入成功率，也可单独监控 - 避免将重试请求重复计数：一次用户请求触发 3 次重试，只应算作 1 次总调用 + 最终结果（成功/失败），而非 3 次独立调用
在服务端暴露标准化的成功率指标
使用 Prometheus 客户端（如 Java 的 Micrometer、PHP 的 client_php）定义指标：
- 用 Counter 类型分别记录：
http_requests_total{method="POST",path="/user/friends",status="200"}和http_requests_total{method="POST",path="/user/friends",status="500"} - 或更推荐：按结果分类打标，如
api_calls_total{api="get_friends",result="success"}、{result="timeout"}、{result="biz_error_40001"} - 确保每个微服务的
/metrics接口稳定输出，Prometheus 按固定间隔（如 15s）拉取
用 PromQL 计算并可视化成功率
在 Grafana 中配置面板，使用 PromQL 实时计算：
- 近 5 分钟成功率：
100 * (1 - rate(api_calls_total{result=~"error|timeout|fail"}[5m]) / rate(api_calls_total[5m])) - 按接口维度下钻：
100 * (1 - sum by (api) (rate(api_calls_total{result=~"error|timeout"}[1h]))) / sum by (api) (rate(api_calls_total[1h])) - 设置阈值告警：当某接口成功率连续 3 个周期低于 99.5%，触发钉钉/邮件通知
结合链路追踪交叉验证
仅靠指标可能掩盖根因。例如成功率骤降，但指标显示全是 200 —— 实际可能是下游返回了“假成功”（如空数据、默认兜底值）。此时需联动 SkyWalking 或 Jaeger：
- 筛选成功率下降时段的 Trace，查看各 Span 的 HTTP 状态码、业务返回码、耗时分布
- 对比「指标统计的成功率」和「链路中实际标记为 success 的 Span 比例」，若差异大，说明埋点逻辑或业务判断有偏差
- 重点看 error tag、logs 字段，定位是网关拦截、鉴权失败，还是下游服务静默吞错
成功率监控不是数字游戏，而是业务可用性的第一道防线。定义清晰、采集可靠、能下钻、可告警、可溯源，才算真正落地。
