Higress 监控实战：从指标采集到告警调优，把网关状态摸透
【免费下载链接】higress🤖 AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress
Higress 是 AI 原生的云原生网关，流量一上来，最先要回答的问题往往不是"它能不能跑"，而是"它现在跑得怎么样"。这篇文章讲 Higress 监控怎么从 0 搭起来：Prometheus 指标采集怎么接、Grafana 面板看什么、告警阈值怎么定、大规模集群怎么给指标减负。读完你能在自己的环境里配出一套能落地的网关可观测性方案。
找到数据源：网关自带的 15020 指标端口
先说结论：Higress 网关底层是 Envoy，指标直接从它的 admin 端口拿，不用额外装采集组件。
整条数据流是这样的：Envoy 在 15020 端口暴露/stats/prometheus，Prometheus 侧的采集器按固定间隔拉取，数据再进 Grafana 展示、进 Alertmanager 触发告警。搞清楚这一点，后面所有排障思路都是顺着这条链路倒推。
部署完之后，先手动确认端点是通的：
kubectl exec -it <higress-gateway-pod> -n higress-system -- \ curl -s localhost:15020/stats/prometheus | head只要能看到一堆envoy_前缀的指标行，数据源就是好的，后面采集不到别的地方都可以先排除 Envoy 这一层。
接入 Prometheus：一个开关加一个 selector 🎯
helm/core/values.yaml 里gateway.metrics.enabled默认是 false，把它翻成 true 之后，Helm 模板才会渲染出采集资源：
gateway: metrics: enabled: true podMonitorSelector: release: kube-prome provider: monitoring.coreos.com关键是podMonitorSelector：它不是采集开关，而是标签过滤器。如果你用的不是 kube-prometheus-stack，或者 release 名不叫kube-prome，Prometheus 根本不会去采这个 Pod，后面所有面板都会是空的。provider决定渲染哪种 CRD：monitoring.coreos.com对应社区的 PodMonitor，operator.victoriametrics.com对应 VictoriaMetrics 的 VMPodScrape，两套监控栈都支持。
渲染出来的资源核心就这几行（见 helm/core/templates/podmonitor.yaml 模板）：
spec: selector: matchLabels: app.kubernetes.io/name: higress-gateway podMetricsEndpoints: - port: istio-prom path: /stats/prometheusinterval和scrapeTimeout不填就走 Prometheus 的全局默认值，一般不用特意设。改完helm upgrade一下，用kubectl get podmonitor -n higress-system确认资源存在，再去 Prometheus 的 Targets 页面看有没有出现 higress-gateway 这个 target。
Grafana 面板配置：盯住四组指标
仓库里带了一版监控面板效果，流量、成功率、延迟、资源占用都有覆盖，导入官方仪表盘模板后基本不用从零画：
自建面板的话，Higress Grafana 面板配置聚焦到四组指标就够用了：
- 请求流量：
http_requests_total，按cluster_name或route_name拆开看，哪个后端在吃流量一目了然； - 成功率：
1 - sum(5xx) / sum(total)，比裸看 QPS 更有诊断意义； - 延迟分布：
http_request_duration_seconds_bucket，P95/P99 分位才是网关真正该背的指标； - 资源使用率：
container_cpu_usage_seconds_total{pod=~"higress-gateway.*"}，和延迟放同一个 row 里，方便定位是不是资源瓶颈。
排查"指标缺失"按这个顺序走：PodMonitor 资源在不在 → selector 标签和网关 Pod 是否一致 → 15020 端点 curl 通不通。九成问题卡在前两步。
调告警阈值：别让"狼来了"吵醒你 ⚠️
原则一句话：盯比例，不盯绝对值。QPS 绝对值报警在高峰和低谷之间必然狼来了，错误率才是稳定信号。一组可以直接用的规则：
groups: - name: higress.rules rules: - alert: HighErrorRate expr: sum(rate(http_requests_total{status_code=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.01 for: 3m labels: severity: critical重点在for: 3m这行：瞬时毛刺（比如某个上游抖一下自己恢复了）不值得拉人，持续 3 分钟还在的 1% 5xx 才需要处理。延迟告警同理，用 P99 持续超阈值的写法，别用瞬时值。
大规模场景：给指标减负
集群里服务一多，Envoy 默认吐出的细粒度指标会让 cardinality 膨胀，Prometheus 的抓取耗时和内存都会跟着失控。两个配置值得打开：
global: liteMetrics: true proxyStatsMatcher: inclusionRegexps: - "http.*"liteMetrics会让网关只暴露精简后的指标集，在网关 Pod 里通过LITE_METRICS环境变量生效；proxyStatsMatcher在 Envoy 侧过滤统计项，默认.*全保留，只留http.*能砍掉一大截你用不上的连接级细节。再配合适当放宽采集间隔、给网关容器配好 requests/limits，监控开销能压到可以忽略的程度。
再往上的量级——上百服务、多集群——单机 Prometheus 扛不住就换 Thanos 或 VictoriaMetrics 集群做长期存储，把 retention 和聚合规则配好，别指望靠单机扩容硬扛。
监控搭得快不如用得对：先把四组核心指标和一条错误率告警跑起来，剩下的优化按需加。
【免费下载链接】higress🤖 AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
