Keil MDK从安装到调试：STM32开发环境配置与避坑指南
2026/9/18 14:51:25
Higress 监控面板搭建指南：从指标采集到 Grafana 告警的完整路径
【免费下载链接】higress🤖 AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress
Higress 是一个 AI 原生的云原生 API 网关，而 Higress 监控面板是你在生产环境里确认"网关到底健不健康"最直接的手段。本文带你从零把网关接入 Prometheus，在 Grafana 里看到请求量、延迟与错误率，并配上第一条告警规则。全程不需要改网关源码，只改 Helm 配置和两条命令。
先说结论：这套方案能覆盖日常巡检（流量与成功率）、故障定位（延迟分位与 5xx 占比）和资源评估（CPU/内存水位）三类场景，且采集开销可控——因为指标端点复用网关自带的 Admin 端口，不额外起任何组件。
准备工作：先确认这 3 项前提
动手前把下表过一遍，缺任何一项都会让后面的步骤卡住：
| 类别 | 内容 | 说明 |
|---|---|---|
| 前提条件 | 已部署 Higress 网关（Helm release 存在） | 后文默认网关在higress-system命名空间，名字为higress-gateway（Helm 默认值） |
| 前提条件 | 集群里已有 Prometheus 监控栈 | 需要支持 PodMonitor CRD，即 kube-prometheus-stack 或 VictoriaMetrics Operator（Helm 配置里的provider字段就是用来二选一的） |
| 前提条件 | 有 Grafana 可登录 | 用于导入仪表盘和查看告警 |
| 所需组件 | 本地装有 kubectl 和 Helm | 一条命令都不用手工敲 YAML |
| 所需组件 | Higress 仓库 | git clone https://gitcode.com/GitHub_Trending/hi/higress，后文引用的配置都在 helm/core/ 目录下 |
| 预计耗时 | 30~60 分钟 | 取决于是否已有现成的 Grafana 实例 |
一个名词先交代清楚：PodMonitor 是"告诉 Prometheus 去哪抓指标"的声明——它写明选哪些 Pod、抓哪个端口哪条路径、多久抓一次。理解了这一点，本文所有配置改动你都能自己推断。
准备工作就绪后，搭建就按一条因果链推进：先让指标能从网关吐出来，再接面板看图，最后才配告警。顺序反了会白忙——面板没数据时你调再多阈值也没有意义。
搭建路径：先通指标 → 再连面板 → 后配告警
整条链路长这样，你做完每步都能用一条命令验证：
端点可达 → PodMonitor 生效 → Prometheus 出现 target → Grafana 有数据 → 告警规则开始评估第一步，确认指标端点可达。网关进程内置了 Prometheus 格式指标端点，地址在 15020 端口的/stats/prometheus路径上。进网关 Pod 验证一下：
kubectl exec -it deploy/higress-gateway -n higress-system -- curl -s localhost:15020/stats/prometheus | head看到requests_total、request_duration_milliseconds这类以# HELP开头的输出，就说明源头没问题。如果这一步就没数据，问题在网关自身，后面所有步骤都不用做。
第二步，用 Helm 生成 PodMonitor。打开 helm/core/values.yaml，在gateway.metrics段打开开关：
gateway: metrics: enabled: true podMonitorSelector: release: kube-prome # 需要匹配你监控栈的 release 标签，默认适配 kube-prometheus-stack改完执行helm upgrade higress ./helm/core -n higress-system。这一步会按 helm/core/templates/podmonitor.yaml 模板生成一个名为higress-gateway-metrics的 PodMonitor，选中的正是带app.kubernetes.io/name: higress-gateway标签的 Pod，抓istio-prom端口的/stats/prometheus。用kubectl get podmonitor -n higress-system能看到它，说明声明已落地。
第三步，等 Prometheus 侧出现 target。在 Grafana 或 Prometheus UI 的 Targets 页面搜higress，看到状态为 UP 的抓取任务，数据链路就通了。从helm upgrade到 target UP 通常只需一两个采集周期（默认 30 秒，PodMonitor 里可配interval缩短）。
第四步，连面板。在 Grafana 里导入 Higress 官方仪表盘模板（社区维护的 JSON，导入后无需再改数据源）。导入完成先别急着看全貌——切到"流量"页签，确认请求量曲线和刚才是否有流量对得上。看到曲线在上涨，就说明面板和 Prometheus 之间的查询也通了。
第五步，配第一条告警。告警规则加在你监控栈的 PrometheusRule 里即可，最小可用的一条是：
groups: - name: higress.rules rules: - alert: HigressHighErrorRate expr: | sum(rate(requests_total{response_code=~"5.."}[5m])) / sum(rate(requests_total[5m])) > 0.01 for: 3m labels: severity: critical含义：5 分钟窗口内 5xx 占比超过 1%，并持续 3 分钟才触发。for: 3m这个缓冲是刻意的——瞬时毛刺不值得半夜叫人。看到这条规则出现在 Prometheus 的 Rules 页面且状态为 OK，整条链路就闭环了。
面板和告警都就绪后，剩下的问题是"该看哪几个数"。下面按你实际会遇到的场景分组。
面板使用指南：三类场景对应哪几张图
别试图看懂仪表盘上每一张图。日常只需要盯住下面三组，出问题时再下钻。
日常巡检（每天瞟一眼）
| 指标 | 含义 | 阈值建议 |
|---|---|---|
requests_total | 网关处理的请求总数（带response_code、upstream_cluster等标签） | 突降 50% 以上关注业务侧异常 |
response_code聚合的 2xx/5xx 占比 | 成功率，巡检时看 5xx 是否恒为 0 | 5xx 占比 > 1% 持续 3 分钟即告警（同上一步规则） |
延迟 P99（request_duration_milliseconds分位） | 最慢 1% 请求的耗时 | 超过该服务正常基线的 2 倍需下钻 |
故障定位（告警响了之后）
| 指标 | 含义 | 阈值建议 |
|---|---|---|
按upstream_cluster拆分的 5xx | 区分是网关自身问题还是某个上游服务在挂 | 单个 cluster 占全部 5xx 比例 > 80% 时，锅在上游 |
上游连接/超时类计数（upstream_rq_*前缀） | 上游连接失败、重置的计数 | 从零开始非零增长即可告警 |
| 请求速率 × 错误率双图联动 | 判断错误是"流量放大导致"还是"无流量也错" | 无流量仍出 5xx，优先查网关配置推送 |
成本与性能（容量规划时）
| 指标 | 含义 | 阈值建议 |
|---|---|---|
网关 Pod 的 CPU / 内存用量（Kubernetes 侧container_*指标） | 评估要不要扩副本 | 内存持续接近 limit（默认 1024Mi）的 80% 就该扩容 |
| 每秒请求数（QPS）趋势 | 判断容量余量 | 峰值接近当前容量 70% 时规划扩容 |
判断依据都摆在表里了：哪条指标、什么阈值，照着配即可，不需要凭感觉。
常见坑：指标没出来的 3 个排查点
搭建过程中 90% 的卡点集中在下面三种情况，按"现象→原因→处理"对照即可：
| 现象 | 原因 | 处理 |
|---|---|---|
Prometheus 里完全没有higress-gateway-metrics这个 target | PodMonitor 没生成，或podMonitorSelector标签与监控栈对不上 | 先kubectl get podmonitor -n higress-system确认资源存在；再核对你监控栈的 release 名，把 values 里的release: kube-prome改成实际值 |
| PodMonitor 存在但 target 仍是 DOWN | 标签不匹配：PodMonitor 选中的是app.kubernetes.io/name: higress-gateway，如果你自定义过gateway.name，两边就不一致了 | 用kubectl get pod -n higress-system --show-labels核对实际标签，保证 selector 与 Pod 标签一一对应 |
| 指标全都有，但 Prometheus 存储量暴涨、查询变慢 | 高基数：upstream_cluster、路由类标签取值随服务数量线性增长，100+ 服务的集群尤其明显 | 在 helm/core/values.yaml 把global.liteMetrics设为true收窄指标面；或在global.proxy.proxyStatsMatcher.inclusionRegexps里从默认的".*"收紧为只保留http、tcp前缀的正则；再配合 PodMonitor 的metricRelabelings丢弃用不到的标签 |
还有一个低概率但值得记一笔的坑：端点能 curl 到、但 Prometheus 抓不到。此时先检查 Pod 的prometheus.io/scrape注解（网关 Pod 默认已带，见 values 中podAnnotations），如果手动删过注解，恢复即可，无需动 PodMonitor。
排查完这三点，绝大多数"没数据"的问题都能收敛。
总结：从看面板到自定义指标
回到开头的价值主张：这套"Prometheus + PodMonitor + Grafana + 告警规则"的组合，让你不新增任何组件就拿到了网关的全链路可观测性——流量、成功率、延迟、资源四类信号各有一张能直接下钻的图。
如果内置指标不满足需求，延伸方向是两条：
- 采集侧：通过 PodMonitor 的
metricRelabelings和global.proxy.proxyStatsMatcher.inclusionRegexps精细控制暴露哪些 Envoy 原始统计，这决定了指标的成本上限； - 定义侧：网关侧的代码都在主仓库中，指标与状态端点相关的实现集中在 pkg/ 目录（如 pkg/cmd/ 下的服务启动逻辑与 pkg/config/ 下的常量定义），想扩展自定义指标可以从这里入手。
监控不是装完面板就结束的事，阈值建议只是起点——跑两周后，用你的真实流量基线替换本文给的经验阈值，面板才算真正"长"在你的业务上。
【免费下载链接】higress🤖 AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考