尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

给 Higress 网关装上 Prometheus 监控:从采集到告警的完整路径

给 Higress 网关装上 Prometheus 监控:从采集到告警的完整路径 给 Higress 网关装上 Prometheus 监控从采集到告警的完整路径【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress凌晨被上游接口超时率飙升吵醒登录网关却只能看到一句上游响应变慢。Higress 网关把请求转发得稳稳的可流量、延迟、错误率这些它自身运行的状态平时完全是黑盒。这篇把监控链路从什么都没有讲到能被告警叫醒全程基于仓库里的 Helm 模板和 values 参数不引入任何 Higress 之外的监控组件。监控链路长什么样网关只管吐指标Higress 的数据面是 Envoy开源服务网格里的代理进程负责实际转发流量它默认把运行时指标暴露在 Pod 内 15020 端口的/stats/prometheus上。整条链路只有四个角色Envoy 吐指标PodMonitorPrometheus Operator 的自定义资源相当于一张去哪采的声明单声明采集目标Prometheus 按声明执行抓取Grafana 展示。仓库的 helm/core/templates/podmonitor.yaml 模板负责生成这张声明单网关本身不跑任何监控组件。动手实操先让数据到 Prometheus开启指标采集最小闭环就是把采集开关打开。helm/core/values.yaml 默认enabled: false所以什么都不配时Prometheus 侧根本看不到网关# helm/core/values.yaml —— 打开后 helm 会生成网关的 PodMonitor gateway: metrics: enabled: true podMonitorSelector: release: kube-prome provider: monitoring.coreos.comhelm upgrade之后Kubernetes 里会多出一个名字带-metrics的 PodMonitor。selector 指向网关 Pod 的istio-prom端口也就是 15020路径写死为/stats/prometheus模板里没有留口子改。采集间隔改成 15 秒要动哪两个字段默认不填时 Prometheus 用全局 30 秒间隔生产环境通常想收到 15 秒。两个字段成对出现gateway: metrics: interval: 15s scrapeTimeout: 5s这里有个硬约束scrapeTimeout必须小于interval否则 Prometheus 会直接拒绝该采集配置。15 秒一次意味着/stats/prometheus的响应体每 15 秒被完整拉一遍响应体有多大取决于下一节调的指标范围。验证指标真的到位了分两步。先确认 Envoy 自己有没有吐指标kubectl exec -it gateway-pod -n higress-system -- \ curl -s localhost:15020/stats/prometheus | head有输出说明数据面正常没有输出问题出在网关 Pod 而不是 Prometheus。再确认 Prometheus 采到了istio_requests_total{destination_apphigress-gateway}这是 Istio 体系的请求计数指标destination_app标签对不上就换个标签名查但指标名本身一定存在。能查到时间序列闭环就通了。挂上 5xx 告警规则数据到位后最有价值的第一个告警是错误率。新建一个 PrometheusRule表达式基于istio_requests_total的response_code标签Envoy 指标里状态码就叫这个名字不是status_codegroups: - name: higress-gateway.rules rules: - alert: HigressHigh5xxRate expr: | sum(rate(istio_requests_total{response_code~5..}[5m])) / sum(rate(istio_requests_total[5m])) 0.05 for: 3m labels: severity: critical配到 5% 而不是 1%是因为网关出口偶发上游抖动很常见阈值太灵敏会被单实例故障反复打脸。进阶调优三个值得花时间的方向指标基数膨胀把正则从.*收窄现象服务多、集群多之后Prometheus 里网关相关序列数量涨得吓人抓取耗时和内存一起上去。根因在 helm/core/values.yaml 里proxyStatsMatcher.inclusionRegexps默认就是.*等于 Envoy 全量指标无差别放行。手段是把正则收窄成几类真正要看的pilot: env: proxyStatsMatcher: inclusionRegexps: - cluster.*upstream_rq.* - listener.*http.* - cluster.*upstream_cx.*效果立竿见影序列数量通常能砍掉一大半/stats/prometheus的响应体随之变小抓取的scrapeTimeout压力也降下来。注意它挂在pilot.env下和gateway.metrics不是一个层级。轻量模式liteMetrics 开关现象上面收窄之后指标还是嫌多。手段是把global.liteMetrics从默认false改成true这是 Higress 提供的轻量指标模式直接减少 Envoy 上报的指标集。效果和正则收窄是叠加的但两者都属于少即是多的操作改完务必确认 Grafana 里现有面板没有依赖被裁掉的指标否则图会突然空一块。大规模集群从采样侧降频现象上百个服务的集群里网关本身指标不多但抓取频率带来的存储量线性放大。手段是反过来调interval从 15 秒放回到 30 秒甚至 60 秒配合 Thanos 这类长期存储做降采样查询。牺牲的是分钟级的实时性换来的是同等存储容量下能多养几倍的采集目标。踩坑实录三个高频翻车点⚠️标签对不上采集静默丢失。PodMonitor 的 selector 匹配的是app.kubernetes.io/name: higress-gateway这类固定标签。改过gateway.name或手动覆盖过 labels 之后PodMonitor 还在、Prometheus 也正常但就是没有网关的序列——没有任何报错。排查顺序kubectl get podmonitor确认资源存在 → 检查 Pod 实际标签 → 对照模板里的 selector。⚠️provider 和实际部署的 CRD 不是一回事。默认provider: monitoring.coreos.com对应 kube-prometheus-stack 环境跑 VictoriaMetrics Operator 时要换成operator.victoriametrics.com模板渲染出来的是VMPodScrape而不是 PodMonitor。配错的表现是资源创建了但没人消费Grafana 里照样空。⚠️告警表达式照抄别的系统的status_code。很多网关告警规则模板写的是status_code500直接贴到 Higress 上永远不触发因为 Envoy 系指标的标签是response_code。改标签名之前先在 Prometheus 里istio_requests_total{}裸查一次把真实标签抄下来再写规则。从enabled: true到告警能叫醒人中间就三件事打开开关、验证 15020、对齐标签。想继续挖的话helm/core/templates/configmap.yaml 里的 access log 字段定义和gateway.metrics下的metricRelabelings是两个值得翻的入口——前者决定日志里能分析什么后者决定哪些指标能在入库前被重命名或丢弃。【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表