Ingress 流量监控体系：从零到全景

K8s 里所有外部流量都过 Ingress，它天生是"全站流量的观测点"。搭一套 Ingress 流量监控，等于给全站装了一个仪表盘：请求量、延迟、错误率、哪个上游在抖，一屏全看。

一、指标来源：Ingress-Nginx 自带

Ingress-Nginx Controller 默认暴露 Prometheus 指标端点（:10254/metrics），核心指标：

n n n n g g g g i i i i n n n n x x x x _ _ _ _ i i i i n n n n g g g g r r r r e e e e s s s s s s s s _ _ _ _ c c c c o o o o n n n n t t t t r r r r o o o o l l l l l l l l e e e e r r r r _ _ _ _ r r i r e e n e q q g s u u r p e e e o s s s n t t s s s _ _ e d u _ u p s r s i a t z t r e i e o a n m # _ _ s l 请 e a 求 c t 数 o e （ n n 带 d c s y h _ o s s e t # c / o i 请 n n 求 d g 耗 s r 时 e （ s 直 # s 方 / 图 上 s ） 游 e 延 r 迟 v i c e 标 签 ）

这些指标天然带标签：ingress、namespace、service、status——不需要应用埋点，就能按服务/域名维度切流量。

二、采集：ServiceMonitor

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: ingress-nginx
spec:
  endpoints:
  - port: metrics
    interval: 15s
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx

配好 Prometheus 自动抓取，无需 agent。注意开 enable-ssl-chain-completion 之外，还要确认 controller 启动参数带 --metrics-per-host 和 --metrics-per-service，否则指标是全局聚合的，没法按服务看。

三、核心指标设计：四个必看面板

1. 请求量（QPS 趋势）

s u m ( r a t e ( n g i n x _ i n g r e s s _ c o n t r o l l e r _ r e q u e s t s { c o n t r o l l e r _ c l a s s = " n g i n x " } [ 5 m ] ) ) b y ( i n g r e s s )

2. 延迟（P50/P95/P99）

直方图算分位：

1
2

histogram_quantile(0.99,
  sum(rate(nginx_ingress_controller_request_duration_seconds_bucket[5m])) by (le, ingress))

3. 错误率

s s u u m m ( ( r r a a t t e e ( ( n n g g i i n n x x _ _ i i n n g g r r e e s s s s _ _ c c o o n n t t r r o o l l l l e e r r _ _ r r e e q q u u e e s s t t s s { [ s 5 t m a ] t ) u ) s = b ~ y " 5 ( . i . n " g } r [ e 5 s m s ] ) ) ) b y ( i n g r e s s )

4. 上游健康（哪个 Pod 在抖）

n g i n x _ i n g r e s s _ c o n t r o l l e r _ i n g r e s s _ u p s t r e a m _ l a t e n c y _ s e c o n d s

告警规则（3 条就够）：

规则 表达式 阈值
5xx 率突增 错误率 > 5% 持续 5m warn
P99 超时 延迟 P99 > 1s 持续 10m warn
单服务 5xx 持续 某 ingress 5xx > 10% 持续 5m critical

四、Grafana 大盘布局

我按"入口 → 出口"顺序排面板：

第 第 第 第 一 二 三 四 行 行 行 行 ： ： ： ： 总 按 T 上 览 o 游 （ I p 延 总 n 迟 g 慢 分 Q r 接 布 P e 口 S s s / / （ 服 T 总 务 o 错 ） p 误 维 率 度 5 表 x / 格 x — P — 接 9 Q 口 9 P S 全 、 局 P ） 9 9 、 错 误 率 、 趋 势 s p a r k l i n e

最有价值的是第二行：一个表格按服务列出 QPS/P99/错误率，任何异常一眼可见。配上 Grafana 变量（$ingress 下拉），点进去看单服务详情。

五、踩坑记录

坑 1：指标没按服务拆分

早期 controller 没开 --metrics-per-service，面板上只有全局 QPS，服务一多根本没法看。改启动参数后重装，才能按 service 维度切。

坑 2：Ingress 没有 namespace 标签歧义

两个 namespace 下同名 ingress，指标标签会打架。用 namespace + ingress 组合建变量，别只用 ingress 名。

坑 3：直方图 bucket 覆盖不足

默认 bucket 上限 10s，P99 1s 内的服务分位估算不准。加长尾 bucket（2s, 5s, 10s），分位才可信。

坑 4：404 也算请求

status=404 也会进 requests 计数，恶意扫描会让"错误率"面板虚高。看错误率只统计 5xx，4xx 单独面板（能看出扫描/爬虫）。

六、收益

  • 上线即用：不改一行业务代码，全站流量视图就有了
  • 排障提速：告警直接指到"哪个服务 5xx 了"，不用再猜
  • 容量规划：QPS 趋势 + 分位延迟，扩容有数据依据
  • 发布监控：每次发版盯错误率面板，回滚有依据

总结

Ingress 流量监控是最划算的可观测投资：

  1. Ingress 自带指标，配好 ServiceMonitor 就有数据
  2. 按服务维度看：QPS / P99 / 错误率三件套
  3. 告警要收敛：3 条规则比 30 条更有效
  4. 面板从入口到出口：总览 → 服务 → 接口 → 上游

入口流量是系统的第一道仪表盘，比埋点快、比日志直观，先搭它。