Higress 监控面板搭建与调优实战【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress凌晨两点后端同学被拉起来说网关变慢你打开 Grafana 却发现面板里连一条 Higress 流量曲线都没有只能逐台 Pod 手工 curl 指标口验证。其实 Higress 监控开箱就有数据面 Envoy 在 15020 端口暴露 Prometheus 指标默认只是没开采集。下面把网关 Prometheus 接入、调优到 Grafana 面板的完整链路走一遍。✅ 先让指标跑起来一个开关加两条命令先拿到仓库Helm Chart 就在helm/core里# 克隆 Higress 仓库并进入 Chart 目录 git clone https://gitcode.com/GitHub_Trending/hi/higress cd higress/helm/core核心开关在gateway.metrics改三个字段就够了# values.yaml只列出需要改的字段 gateway: metrics: enabled: true # 默认 false模板靠它决定是否生成 PodMonitor interval: 15s # 空值用 Prometheus 全局默认通常 30s scrapeTimeout: 5s为什么是 15s 和 5sEnvoy 计数是累积值Grafana 查询多用 5m 窗口15s 粒度足够看趋势再密只是白烧带宽超时 5s 是兜底全量/stats/prometheus响应有几十 MB慢一次不能让整条 scrape 卡死。PodMonitor 模板会把podMonitorSelector的标签打到 PodMonitor 的 metadata 上release: kube-prome是 kube-prometheus-stack 的默认 release 标签Operator 侧靠它认领这个采集任务——你如果装的是别的 release 名这里必须同步改这是最容易漏的一处。provider默认monitoring.coreos.com跑 VictoriaMetrics Operator 的环境要改成operator.victoriametrics.com后面踩坑部分细说。升级部署让配置生效# 生成 PodMonitor 并更新网关配置 helm upgrade --install higress ./core -n higress-system -f values.yaml部署完成后网关 Pod 上会多出istio-prom15020这个指标端口Prometheus 的目标列表里就能看到 higress-gateway。监控对象长什么样看这个路由与服务视图 从能采到采得精性能、告警与展示压低采集开销用 statsMatcher 和 liteMetrics 砍掉无效指标默认配置下inclusionRegexps是.*意味着 Envoy 每个统计项都采集。集群规模上来后一个网关 Pod 就能吐出上万条序列15s 一次采集对 Prometheus 的 TSDB 是持续压力。砍法有两层# values.yaml两层裁剪各管一段 global: liteMetrics: true # 换用精简 stats 模板指标数量级下降 proxy: proxyStatsMatcher: inclusionRegexps: - http.* # 保留 HTTP 下游/上游计数 - tcp.* # 保留 TCP 连接计数两者作用在不同层面inclusionRegexps走 mesh 配置 的 stats matcher按名字过滤liteMetrics直接替换 Envoy 的 stats 模板文件是更彻底的减项手段。取舍逻辑中小集群只开 matcher 就够百服务以上建议 liteMetrics 打底、matcher 兜底——但注意 liteMetrics 有副作用见踩坑部分。定好采集节奏间隔再密不增加诊断价值/stats/prometheus的体量随 cluster 和 route 数量线性增长。如果你的网关挂了 300 个上游集群15s 间隔下 Prometheus 每秒要处理的数据量是 5s 间隔的三倍而排障时你看的仍然是 5m rate 曲线。所以除非要做亚分钟级抖动分析保持 15s真要提速先开 liteMetrics 把响应体打小再动间隔。把告警写进规则用 5xx 占比提前发现问题指标暴露的是 Envoy 命名风格不是通用的http_requests_total——用错名字告警永远不会触发这是写规则前必须先确认的# Prometheus 规则指标名取自 /stats/prometheus 实际输出 groups: - name: higress.rules rules: - alert: HigressHighErrorRate expr: sum(increase(envoy_http_downstream_rq_5xx[5m])) / sum(increase(envoy_http_downstream_rq[5m])) 0.01 for: 3m labels: severity: criticalfor: 3m留了 3 分钟窗口避免瞬时毛刺直接拉你起来错误率阈值 1% 是网关场景的常用水位比单看绝对值更能反映上游劣化。让面板只讲重点云原生网关 Grafana 面板四组曲线面板不用堆图四组曲线覆盖 90% 的排障入口请求流量envoy_http_downstream_rq_2xx的 rate看总量和波峰成功率1 - envoy_http_downstream_rq_5xx / envoy_http_downstream_rq上游健康envoy_cluster_upstream_rq_5xx按 cluster 维度拆开定位是哪个后端在抽风延迟分布envoy_cluster_upstream_rq_time_bucketP99 突刺往往先于 5xx 出现 真实环境踩坑三个高频故障的四行式排查PodMonitor 资源存在但监控端一条目标都没有现象helm install成功PodMonitor 查得到Prometheus/VM 的 Targets 页却搜不到 higress。定位命令kubectl -n higress-system get podmonitor,vmpodscrape根因模板按provider生成资源默认monitoring.coreos.com建的是 Prometheus Operator 组里的 PodMonitor你如果跑的是 VictoriaMetrics Operator它只认自己组的 VMPodScrape建出来的资源等于无人认领。修复provider改为operator.victoriametrics.com后重新helm upgrade删掉旧的孤儿资源。exec 里 curl 15020 通集群外就不通现象kubectl exec -it pod -n higress-system -- curl -s localhost:15020/stats/prometheus正常返回换到节点或跨命名空间访问就是 connection refused。定位命令kubectl -n higress-system get svc输出里没有 15020 这个端口根因15020 只是 containerPort名为 istio-prom没有任何 Service 暴露它Envoy agent 也只监听 Pod 内回环——官方没专门写这点但所有从外部直接抓 15020的方案都会卡在这。修复别折腾 Service坚持 PodMonitor它进 Pod 内部抓需要外部调试时用kubectl -n higress-system port-forward pod/pod 15020:15020。开了 liteMetricsPod 根文件系统变成可写现象global.liteMetrics: true之后安全审计报容器根文件系统可写和之前只读基线对不上怀疑被改坏配置。定位命令kubectl -n higress-system get pod -o jsonpath{.items[0].spec.containers[0].securityContext.readOnlyRootFilesystem}根因liteMetrics 模式下 Envoy 启动时要替换 stats 配置模板文件Pod 模板 里对应跳过了readOnlyRootFilesystem是有意为之而非配置丢失。修复如果你的安全基线强制只读根文件系统退回liteMetrics: false改用inclusionRegexps收窄指标代价是序列数下降幅度小一些。回到凌晨那次的场景监控链路跑通后同样的网关变慢再来一次你只需要看面板上 P99 曲线和按 cluster 拆的 5xx 就能在 10 分钟内定位到具体上游而不是手工翻 Pod。想继续深入两处源码值得翻PodMonitor 生成逻辑 看采集任务怎么拼出来的Pod 模板 看 liteMetrics 如何改写容器环境插件侧自定义指标的扩展可以对照plugins/wasm-go/下的插件实现有环境差异或行为对不上直接去仓库的 Issue 区提。【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Higress 监控面板搭建与调优实战
Higress 监控面板搭建与调优实战【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress凌晨两点后端同学被拉起来说网关变慢你打开 Grafana 却发现面板里连一条 Higress 流量曲线都没有只能逐台 Pod 手工 curl 指标口验证。其实 Higress 监控开箱就有数据面 Envoy 在 15020 端口暴露 Prometheus 指标默认只是没开采集。下面把网关 Prometheus 接入、调优到 Grafana 面板的完整链路走一遍。✅ 先让指标跑起来一个开关加两条命令先拿到仓库Helm Chart 就在helm/core里# 克隆 Higress 仓库并进入 Chart 目录 git clone https://gitcode.com/GitHub_Trending/hi/higress cd higress/helm/core核心开关在gateway.metrics改三个字段就够了# values.yaml只列出需要改的字段 gateway: metrics: enabled: true # 默认 false模板靠它决定是否生成 PodMonitor interval: 15s # 空值用 Prometheus 全局默认通常 30s scrapeTimeout: 5s为什么是 15s 和 5sEnvoy 计数是累积值Grafana 查询多用 5m 窗口15s 粒度足够看趋势再密只是白烧带宽超时 5s 是兜底全量/stats/prometheus响应有几十 MB慢一次不能让整条 scrape 卡死。PodMonitor 模板会把podMonitorSelector的标签打到 PodMonitor 的 metadata 上release: kube-prome是 kube-prometheus-stack 的默认 release 标签Operator 侧靠它认领这个采集任务——你如果装的是别的 release 名这里必须同步改这是最容易漏的一处。provider默认monitoring.coreos.com跑 VictoriaMetrics Operator 的环境要改成operator.victoriametrics.com后面踩坑部分细说。升级部署让配置生效# 生成 PodMonitor 并更新网关配置 helm upgrade --install higress ./core -n higress-system -f values.yaml部署完成后网关 Pod 上会多出istio-prom15020这个指标端口Prometheus 的目标列表里就能看到 higress-gateway。监控对象长什么样看这个路由与服务视图 从能采到采得精性能、告警与展示压低采集开销用 statsMatcher 和 liteMetrics 砍掉无效指标默认配置下inclusionRegexps是.*意味着 Envoy 每个统计项都采集。集群规模上来后一个网关 Pod 就能吐出上万条序列15s 一次采集对 Prometheus 的 TSDB 是持续压力。砍法有两层# values.yaml两层裁剪各管一段 global: liteMetrics: true # 换用精简 stats 模板指标数量级下降 proxy: proxyStatsMatcher: inclusionRegexps: - http.* # 保留 HTTP 下游/上游计数 - tcp.* # 保留 TCP 连接计数两者作用在不同层面inclusionRegexps走 mesh 配置 的 stats matcher按名字过滤liteMetrics直接替换 Envoy 的 stats 模板文件是更彻底的减项手段。取舍逻辑中小集群只开 matcher 就够百服务以上建议 liteMetrics 打底、matcher 兜底——但注意 liteMetrics 有副作用见踩坑部分。定好采集节奏间隔再密不增加诊断价值/stats/prometheus的体量随 cluster 和 route 数量线性增长。如果你的网关挂了 300 个上游集群15s 间隔下 Prometheus 每秒要处理的数据量是 5s 间隔的三倍而排障时你看的仍然是 5m rate 曲线。所以除非要做亚分钟级抖动分析保持 15s真要提速先开 liteMetrics 把响应体打小再动间隔。把告警写进规则用 5xx 占比提前发现问题指标暴露的是 Envoy 命名风格不是通用的http_requests_total——用错名字告警永远不会触发这是写规则前必须先确认的# Prometheus 规则指标名取自 /stats/prometheus 实际输出 groups: - name: higress.rules rules: - alert: HigressHighErrorRate expr: sum(increase(envoy_http_downstream_rq_5xx[5m])) / sum(increase(envoy_http_downstream_rq[5m])) 0.01 for: 3m labels: severity: criticalfor: 3m留了 3 分钟窗口避免瞬时毛刺直接拉你起来错误率阈值 1% 是网关场景的常用水位比单看绝对值更能反映上游劣化。让面板只讲重点云原生网关 Grafana 面板四组曲线面板不用堆图四组曲线覆盖 90% 的排障入口请求流量envoy_http_downstream_rq_2xx的 rate看总量和波峰成功率1 - envoy_http_downstream_rq_5xx / envoy_http_downstream_rq上游健康envoy_cluster_upstream_rq_5xx按 cluster 维度拆开定位是哪个后端在抽风延迟分布envoy_cluster_upstream_rq_time_bucketP99 突刺往往先于 5xx 出现 真实环境踩坑三个高频故障的四行式排查PodMonitor 资源存在但监控端一条目标都没有现象helm install成功PodMonitor 查得到Prometheus/VM 的 Targets 页却搜不到 higress。定位命令kubectl -n higress-system get podmonitor,vmpodscrape根因模板按provider生成资源默认monitoring.coreos.com建的是 Prometheus Operator 组里的 PodMonitor你如果跑的是 VictoriaMetrics Operator它只认自己组的 VMPodScrape建出来的资源等于无人认领。修复provider改为operator.victoriametrics.com后重新helm upgrade删掉旧的孤儿资源。exec 里 curl 15020 通集群外就不通现象kubectl exec -it pod -n higress-system -- curl -s localhost:15020/stats/prometheus正常返回换到节点或跨命名空间访问就是 connection refused。定位命令kubectl -n higress-system get svc输出里没有 15020 这个端口根因15020 只是 containerPort名为 istio-prom没有任何 Service 暴露它Envoy agent 也只监听 Pod 内回环——官方没专门写这点但所有从外部直接抓 15020的方案都会卡在这。修复别折腾 Service坚持 PodMonitor它进 Pod 内部抓需要外部调试时用kubectl -n higress-system port-forward pod/pod 15020:15020。开了 liteMetricsPod 根文件系统变成可写现象global.liteMetrics: true之后安全审计报容器根文件系统可写和之前只读基线对不上怀疑被改坏配置。定位命令kubectl -n higress-system get pod -o jsonpath{.items[0].spec.containers[0].securityContext.readOnlyRootFilesystem}根因liteMetrics 模式下 Envoy 启动时要替换 stats 配置模板文件Pod 模板 里对应跳过了readOnlyRootFilesystem是有意为之而非配置丢失。修复如果你的安全基线强制只读根文件系统退回liteMetrics: false改用inclusionRegexps收窄指标代价是序列数下降幅度小一些。回到凌晨那次的场景监控链路跑通后同样的网关变慢再来一次你只需要看面板上 P99 曲线和按 cluster 拆的 5xx 就能在 10 分钟内定位到具体上游而不是手工翻 Pod。想继续深入两处源码值得翻PodMonitor 生成逻辑 看采集任务怎么拼出来的Pod 模板 看 liteMetrics 如何改写容器环境插件侧自定义指标的扩展可以对照plugins/wasm-go/下的插件实现有环境差异或行为对不上直接去仓库的 Issue 区提。【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考