直接暴露 http_requests_total 无法准确反映网关真实 qps，因其默认标签（method、version）缺失 endpoint 和 department，导致路由聚合、部门下钻、灰度比对失效；需新增 gateway_http_requests_total countervec，按 method/endpoint/department/status 打点，并用 rate()[1m/5m] 计算 qps，结合 alertmanager 路由按 department 分流告警，grafana 数据异常需排查抓取目标、指标注册及中间件打点时机。
直接暴露 http_requests_total 并不能准确反映网关真实 QPS，尤其在路由聚合、多版本共存、部门维度下钻等场景下，指标结构、标签设计和 PromQL 聚合方式必须匹配业务分组逻辑——否则 Grafana 看板全是平直线条，告警永远滞后。
为什么 http_requests_total 默认结构不适合网关 QPS 监控
你代码里用的 httpRequestsTotal 是 CounterVec，带 method 和 version 标签，这在单服务场景够用，但网关典型特征是：大量动态路由（如 /v1/order/create）、多租户/多研发部门流量混跑、同一接口可能被北京/上海团队同时调用。默认标签没包含 endpoint 或 department，导致：
- 无法按
/api/user/info路由聚合 QPS，只能看到所有 GET 请求堆在一起 - 无法区分北京团队调用
/v2/payment和上海团队调用同一路由的流量，部门级看板无从实现 -
version标签粒度太粗（比如全服务只用v1），起不到灰度或版本比对作用
解决办法不是删掉旧指标，而是新增一层更细粒度的网关专用计数器：
var gatewayRequestsTotal = prometheus.NewCounterVec(
prometheus.CounterOpts{
Name: "gateway_http_requests_total",
Help: "Total HTTP requests processed by gateway, labeled by endpoint and department",
},
[]string{"method", "endpoint", "department", "status"},
)
并在中间件中解析 req.URL.Path 提取规范路由（如截断参数、归一化 /user/123 → /user/{id}），再通过环境变量或请求头（如 X-Team: beijing）注入 department 标签。
PromQL 计算网关 QPS 的三个关键写法
QPS 不是原始计数，是单位时间内的增量速率。Prometheus 必须用 rate()，且窗口要合理：
- 监控大盘实时趋势：用
rate(gateway_http_requests_total[1m])—— 1 分钟滑动窗口，响应快，适合 Grafana 每 15s 刷新 - 告警判定（如“QPS > 10”）：必须用
rate(gateway_http_requests_total[5m])—— 避免毛刺误报，5 分钟内持续超标才触发 - 部门维度下钻：加
by (department)，例如sum(rate(gateway_http_requests_total[1m])) by (department)，才能喂给 Grafana 的变量或面板
注意：irate() 虽然响应更快，但它只看最近两个样本点，网关若因负载高导致 scrape 间隔抖动（如本该 15s 一次，实际拉到 22s + 8s），irate 会剧烈跳变，不适用于稳定性要求高的生产告警。
钉钉告警分级发送的配置要点
Prometheus Alertmanager 不支持“根据 label 值发不同群”，必须靠路由（route）+ 标签匹配 + receiver 组合实现：
- 先在指标打点时确保
department标签值固定为beijing或shanghai（别用中文、空格、大小写混用） - Alertmanager 配置里定义两个 receiver：
dingtalk-beijing和dingtalk-shanghai，分别对应不同 webhook 地址 - 路由规则写成：
route: group_by: [alertname, department] routes: - match: department: beijing qps_level: high receiver: dingtalk-beijing - match: department: shanghai qps_level: high receiver: dingtalk-shanghai - 对应的 alert rule 中，用
labels注入qps_level: high，并用expr区分阈值：expr: sum(rate(gateway_http_requests_total[5m])) by (department) > 100 for: 2m labels: qps_level: critical severity: warning
真正容易漏的是：Alertmanager 的 group_wait 和 group_interval 必须设小（如 30s），否则北京团队 QPS 突破 10 触发告警后，上海团队 5 秒后也突破 10，会被合并成一条消息——结果运维只收到一条“某部门 QPS > 10”，根本不知道是哪个部门。
Grafana 面板里看不到数据？先查这三处
常见现象是 Go 服务 /metrics 能 curl 出来，但 Prometheus Targets 显示 DOWN 或查不到 gateway_http_requests_total：
- 检查 Prometheus 抓取配置中的
targets：K8s 内部署的服务，targets不能写localhost:8080，得用 Pod IP 或 Service DNS 名（如gateway-svc.namespace.svc.cluster.local:8080） - 确认指标已注册：在
init()里调了prometheus.MustRegister(gatewayRequestsTotal)，且没被多次调用（重复注册 panic） - 验证标签是否真被写入：curl 服务
/metrics后搜索gateway_http_requests_total，看输出行是否含department="beijing"这类 label；如果只有{method="GET"}，说明中间件没正确 setLabelValues
最隐蔽的问题是：Gin 中间件里调用 Inc() 的时机。如果放在 c.Next() 之后，那 500 错误请求根本不会进计数器——因为 panic 或提前 return 导致后续代码不执行。务必把 gatewayRequestsTotal.WithLabelValues(...).Inc() 放在 c.Next() 之前，用 defer 捕获状态码再更新 status 标签。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
