尧图网站建设 
Higress 网关监控实战从一个指标开关到会抢跑的 5xx 告警【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress流量突增时你说不清哪条路由在持续返回 500P99 延迟翻倍却不知道是网关本身还是上游的问题。这篇 Higress 监控实战带你顺着网关内部的数据链路把指标采集、面板解读、告警规则和低成本采集一次性配到位。让指标先流动起来网关原生就有缺的只是一个开关Higress 网关的数据面由 Envoy 构成istio-agent 默认就会在 15020 端口的/stats/prometheus上把 Envoy 统计转成 Prometheus 格式输出网关 Pod 上也已经带好了prometheus.io/scrape这类注解。也就是说指标一直在往外冒真正缺的是 Prometheus 侧的发现配置。在 values.yaml 里打开指标开关打开 helm/core/values.yaml把gateway.metrics.enabled置为 true并告诉它你的监控组件是谁gateway: metrics: enabled: true podMonitorSelector: release: kube-prome # 换成你的 kube-prometheus-stack 的 release 标签 provider: monitoring.coreos.com再执行一次helm upgrade模板会替你渲染出 podmonitor.yaml 对应的 PodMonitor选中app.kubernetes.io/namehigress-gateway的 Pod按 15 秒默认间隔抓取istio-prom端口的/stats/prometheus。如果集群里跑的是 VictoriaMetrics把provider改成operator.victoriametrics.com即可渲染出来的是 VMPodScrape。 让面板真正看得懂看哪些指标以及为什么看导入官方 Grafana 面板Higress 官方提供预置仪表盘模板导入后请求流量、成功率、延迟分布这些核心视图直接可用不用从零拖图表先盯住四类指标面板再漂亮真正值得反复看的是下面四类每类一句为什么请求量rate(istio_requests_total[1m])。流量突增或骤降是大部分异常的起点按route_name拆分能直接看出是哪条路由在扛量。成功率sum(rate(istio_requests_total{response_code!~5..}[5m])) / sum(rate(istio_requests_total[5m]))。网关视角的 5xx 是业务受损最直接的信号。延迟分布histogram_quantile(0.99, sum(rate(istio_request_duration_milliseconds_bucket[5m])) by (le, route_name))。看 P99 而不是平均值平均值会被大量快请求稀释。资源水位rate(container_cpu_usage_seconds_total{pod~higress-gateway.*}[5m])加内存 working set。Envoy 对内存敏感网关 OOM 是网关层最常见的事故类型。让监控替你先报警告警规则与低成本采集写一条能抄的 5xx 告警规则把下面这条规则加进你的 Prometheus Rule 里1% 的 5xx 比例持续 3 分钟就触发 critical 级别告警groups: - name: higress-gateway rules: - alert: GatewayHigh5xx expr: sum(rate(istio_requests_total{response_code~5..}[5m])) / sum(rate(istio_requests_total[5m])) 0.01 for: 3m labels: severity: criticalfor: 3m是刻意为之瞬时毛刺不值得半夜叫醒人持续 3 分钟才说明问题真的存在。用 liteMetrics 和 proxyStatsMatcher 压低采集成本集群规模上来后全量 Envoy 统计的 cardinality 会成为 Prometheus 存储的大头Higress 给了两个收窄的开关global: liteMetrics: true # 网关只上报轻量级指标指标数量大幅下降 proxy: proxyStatsMatcher: inclusionRegexps: - http.* # 只保留 HTTP 相关统计默认是 .* 全量⚠️ 开liteMetrics后 Pod 会注入LITE_METRICSon模板会自动处理根文件系统与运行用户的调整适合对成本敏感的大规模部署小规模环境默认全量指标通常够用。同时可以把gateway.metrics.interval、scrapeTimeout调到15s/5s控制抓取压力。指标缺失时这样查现象 → 原因 → 一条命令Grafana 面板全空→ PodMonitor 根本没渲染enabled还是 false→kubectl get podmonitor -n higress-systemPodMonitor 存在但 Prometheus targets 里没有网关→ selector 标签没匹配上检查你的 release 标签 →kubectl get pods -n higress-system -l app.kubernetes.io/namehigress-gatewaytarget 有但抓取报错→ 15020 端口的/stats/prometheus不通 →kubectl exec -it gateway-pod -n higress-system -- curl -s localhost:15020/stats/prometheus | head数据有了但存储暴涨→ 指标没做收窄 → 先用kubectl exec -it gateway-pod -n higress-system -- curl -s localhost:15020/stats/prometheus | wc -l看规模再回头开liteMetrics这套数据链路式的监控搭好后网关的流量、错误、延迟就都变成了你能实时看见、且会主动叫你的东西。想继续往深处定制采集范围helm/core/templates/podmonitor.yaml 和 helm/core/values.yaml 就是入口想理解网关整体的指标产生机制可以从 docs/architecture.md 顺着架构图往下看。【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Higress 网关监控实战：从一个指标开关到会抢跑的 5xx 告警
Higress 网关监控实战从一个指标开关到会抢跑的 5xx 告警【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress流量突增时你说不清哪条路由在持续返回 500P99 延迟翻倍却不知道是网关本身还是上游的问题。这篇 Higress 监控实战带你顺着网关内部的数据链路把指标采集、面板解读、告警规则和低成本采集一次性配到位。让指标先流动起来网关原生就有缺的只是一个开关Higress 网关的数据面由 Envoy 构成istio-agent 默认就会在 15020 端口的/stats/prometheus上把 Envoy 统计转成 Prometheus 格式输出网关 Pod 上也已经带好了prometheus.io/scrape这类注解。也就是说指标一直在往外冒真正缺的是 Prometheus 侧的发现配置。在 values.yaml 里打开指标开关打开 helm/core/values.yaml把gateway.metrics.enabled置为 true并告诉它你的监控组件是谁gateway: metrics: enabled: true podMonitorSelector: release: kube-prome # 换成你的 kube-prometheus-stack 的 release 标签 provider: monitoring.coreos.com再执行一次helm upgrade模板会替你渲染出 podmonitor.yaml 对应的 PodMonitor选中app.kubernetes.io/namehigress-gateway的 Pod按 15 秒默认间隔抓取istio-prom端口的/stats/prometheus。如果集群里跑的是 VictoriaMetrics把provider改成operator.victoriametrics.com即可渲染出来的是 VMPodScrape。 让面板真正看得懂看哪些指标以及为什么看导入官方 Grafana 面板Higress 官方提供预置仪表盘模板导入后请求流量、成功率、延迟分布这些核心视图直接可用不用从零拖图表先盯住四类指标面板再漂亮真正值得反复看的是下面四类每类一句为什么请求量rate(istio_requests_total[1m])。流量突增或骤降是大部分异常的起点按route_name拆分能直接看出是哪条路由在扛量。成功率sum(rate(istio_requests_total{response_code!~5..}[5m])) / sum(rate(istio_requests_total[5m]))。网关视角的 5xx 是业务受损最直接的信号。延迟分布histogram_quantile(0.99, sum(rate(istio_request_duration_milliseconds_bucket[5m])) by (le, route_name))。看 P99 而不是平均值平均值会被大量快请求稀释。资源水位rate(container_cpu_usage_seconds_total{pod~higress-gateway.*}[5m])加内存 working set。Envoy 对内存敏感网关 OOM 是网关层最常见的事故类型。让监控替你先报警告警规则与低成本采集写一条能抄的 5xx 告警规则把下面这条规则加进你的 Prometheus Rule 里1% 的 5xx 比例持续 3 分钟就触发 critical 级别告警groups: - name: higress-gateway rules: - alert: GatewayHigh5xx expr: sum(rate(istio_requests_total{response_code~5..}[5m])) / sum(rate(istio_requests_total[5m])) 0.01 for: 3m labels: severity: criticalfor: 3m是刻意为之瞬时毛刺不值得半夜叫醒人持续 3 分钟才说明问题真的存在。用 liteMetrics 和 proxyStatsMatcher 压低采集成本集群规模上来后全量 Envoy 统计的 cardinality 会成为 Prometheus 存储的大头Higress 给了两个收窄的开关global: liteMetrics: true # 网关只上报轻量级指标指标数量大幅下降 proxy: proxyStatsMatcher: inclusionRegexps: - http.* # 只保留 HTTP 相关统计默认是 .* 全量⚠️ 开liteMetrics后 Pod 会注入LITE_METRICSon模板会自动处理根文件系统与运行用户的调整适合对成本敏感的大规模部署小规模环境默认全量指标通常够用。同时可以把gateway.metrics.interval、scrapeTimeout调到15s/5s控制抓取压力。指标缺失时这样查现象 → 原因 → 一条命令Grafana 面板全空→ PodMonitor 根本没渲染enabled还是 false→kubectl get podmonitor -n higress-systemPodMonitor 存在但 Prometheus targets 里没有网关→ selector 标签没匹配上检查你的 release 标签 →kubectl get pods -n higress-system -l app.kubernetes.io/namehigress-gatewaytarget 有但抓取报错→ 15020 端口的/stats/prometheus不通 →kubectl exec -it gateway-pod -n higress-system -- curl -s localhost:15020/stats/prometheus | head数据有了但存储暴涨→ 指标没做收窄 → 先用kubectl exec -it gateway-pod -n higress-system -- curl -s localhost:15020/stats/prometheus | wc -l看规模再回头开liteMetrics这套数据链路式的监控搭好后网关的流量、错误、延迟就都变成了你能实时看见、且会主动叫你的东西。想继续往深处定制采集范围helm/core/templates/podmonitor.yaml 和 helm/core/values.yaml 就是入口想理解网关整体的指标产生机制可以从 docs/architecture.md 顺着架构图往下看。【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考