使用Prometheus监控Nginx Ingress网关

功能入口

功能入口一：集成中心

1. 登录Prometheus控制台。
2. 在左侧导航栏单击监控列表，进入可观测监控 Prometheus 版的实例列表页面。
3. 单击目标Prometheus实例名称，进入集成中心页面。

功能入口二：接入中心

1. 登录ARMS控制台。

2. 在左侧导航栏单击接入中心，然后在组件应用区域单击Nginx Ingress网关监控卡片的添加，然后在弹出的页面根据控制台指引完成组件接入。

方式一：实现ACK集群默认安装的Nginx Ingress网关监控

这里以从集成中心入口为例，介绍接入Nginx Ingress组件的操作，具体步骤如下。

1. 接入Nginx Ingress组件。

   • 若您初次安装Nginx Ingress类型的组件：

     在集成中心页面单击未安装区域Nginx Ingress 网关监控组件卡片的安装。

     说明

     单击该卡片，在弹出的面板中您可以看到关于Nginx Ingress网关监控常见的指标和大盘缩略预览效果图。这里列举出的指标只是常见的一部分指标信息，具体请参见下文Nginx Ingress网关监控指标模型。待您安装Nginx Ingress网关监控成功后，您将会查看到可观测监控 Prometheus 版监控Nginx Ingress网关监控的实际指标详情。

   • 若您已安装Nginx Ingress 网关监控类型的组件，需要再次添加该组件：

     在集成中心页面单击已安装区域Nginx Ingress 网关监控组件卡片的添加。

2. 在弹出的面板的STEP2区域的配置页签配置相关参数，并单击确定，完成组件接入。

   参数	说明
   采集配置名称	当前Nginx Ingress网关监控唯一命名。命名规范要求如下： 仅可包含小写字母、数字和短划线（-），且短划线不可出现在开头或结尾。 名称具有唯一性。 说明 默认名称由组件类型及数字后缀组成。
   Ingress Controller 标签选择器 Key	采集器通过标签选择器查找指定的Ingress Controller Pod，这里提供选择器的键名，如：app。
   Ingress Controller 标签选择器 Value	采集器通过标签选择器查找指定的Ingress Controller Pod，这里提供选择器的值，如：otel-demo-nginx，这样与上面的键名组合成查询表达式：app=otel-demo-nginx。
   Ingress Controller 命名空间	Ingress Controller所在的命名空间，如：otel-demo。
   Ingress Class 标识名	该Ingress Controller监听的目标Ingress Class标识，如：otel-demo-nginx-class。
   日志解析规则	填写日志解析规则。

   说明

   在STEP2区域的指标页签可查看监控指标。

   同时您也可以在集成中心页面的已安装区域，单击该组件卡片，在弹出的面板中快速查看Targets、指标、大盘、服务发现配置、Exporter等信息。集成中心的更多信息，请参见集成中心。

启用当前监控将会在您的K8s集群中部署一个采集器工作负载（DaemonSet），资源限制为0.5核/512 MB ，可以结合网关实际流量规模进行资源限制的调整，请通过kubectl edit daemonset -narms-prom arms-vector命令 进行变更。

方式二：实现自建/多套Nginx Ingress网关监控

如果您是自建Nginx Ingress网关，或者参照ACK官方文档部署多个Ingress Controller在当前K8s集群内部署了多套Nginx Ingress网关，可以通过以下步骤实现监控接入。

1. 接入Nginx Ingress组件。

   • 若您初次安装Nginx Ingress类型的组件：

     在集成中心页面单击未安装区域Nginx Ingress 网关监控组件卡片的安装。

     说明

     单击该卡片，在弹出的面板中您可以看到关于Nginx Ingress网关监控常见的指标和大盘缩略预览效果图。这里列举出的指标只是常见的一部分指标信息，具体请参见下文Nginx Ingress网关监控指标模型。待您安装Nginx Ingress网关监控成功后，您将会查看到可观测监控 Prometheus 版监控Nginx Ingress网关监控的实际指标详情。

   • 若您已安装Nginx Ingress 网关监控类型的组件，需要再次添加该组件：

     在集成中心页面单击已安装区域Nginx Ingress 网关监控组件卡片的添加。

2. 在弹出的面板的STEP2区域的配置页签配置相关参数，并单击确定，完成组件接入。

   参数	说明
   采集配置名称	当前Nginx Ingress网关监控唯一命名。命名规范要求如下： 仅可包含小写字母、数字和短划线（-），且短划线不可出现在开头或结尾。 名称具有唯一性。 说明 默认名称由组件类型及数字后缀组成。
   Ingress Controller 标签选择器 Key	采集器通过标签选择器查找指定的Ingress Controller Pod，这里提供选择器的键名，如：app。
   Ingress Controller 标签选择器 Value	采集器通过标签选择器查找指定的Ingress Controller Pod，这里提供选择器的值，如：otel-demo-nginx，这样与上面的键名组合成查询表达式：app=otel-demo-nginx。
   Ingress Controller 命名空间	Ingress Controller所在的命名空间，如：otel-demo。
   Ingress Class 标识名	该Ingress Controller监听的目标Ingress Class标识，如：otel-demo-nginx-class。
   日志解析规则	填写日志解析规则。

   说明

   在STEP2区域的指标页签可查看监控指标。

   同时您也可以在集成中心页面的已安装区域，单击该组件卡片，在弹出的面板中快速查看Targets、指标、大盘、服务发现配置、Exporter等信息。集成中心的更多信息，请参见集成中心。

监控多套Nginx Ingress网关会复用相同的采集器工作负载，它默认的资源限制为0.5核/512 MB ，请关注网关实际流量规模，进行相应的资源限制调整，您可以通过kubectl edit daemonset -narms-prom arms-vector命令进行变更。

查看网关监控大盘

在集成中心页面单击已安装区域的Nginx Ingress 网关监控组件卡片，然后在弹出的对话框中单击大盘页签可以查看该组件的大盘略缩图和超链接，单击超链接进入阿里云Grafana页面，查看对应观测大盘。

概览

服务统计-TopN

服务统计-趋势分布

服务统计-请求分析

服务统计最后一部分则是将贯穿Host/域名、Service、URI请求路径上的PV、成功率、4XX比例、5XX比例、延迟情况以表格形式详细呈现。它们的统计范围是当前顶部选择的时间段。如果希望下钻看到更细粒度的URI请求分析统计，需要扩展URI收敛规则，请参见下文Nginx Ingress网关监控进阶指南。

地理统计

• 访问省份

  • 各访问省份/地区的占比情况，统计范围是当前顶部选择的时间段。

  • 访问省份/地区的表格详情，统计范围是当前顶部选择的时间段。

• 访问城市

  • 各访问城市的占比情况，统计范围是当前顶部选择的时间段。

  • 访问城市的表格详情，统计范围是当前顶部选择的时间段。

• 访问时区

  • 各访问时区的占比情况，统计范围是当前顶部选择的时间段。

  • 访问时区的表格详情，统计范围是当前顶部选择的时间段。

设备统计

• 设备类型维度

  • 各设备类型的占比、具体数值，统计范围是当前顶部选择的时间段。

  • 设备类型的表格详情，统计范围是当前顶部选择的时间段。

• 操作系统维度

  • 各操作系统的占比、具体数值，统计范围是当前顶部选择的时间段。

  • 操作系统的表格详情，统计范围是当前顶部选择的时间段。

• 浏览器维度

  • 各浏览器的占比、具体数值，统计范围是当前顶部选择的时间段。

  • 浏览器的表格详情，统计范围是当前顶部选择的时间段。

Nginx Ingress网关监控指标模型

通用请求量指标（ingress_requests）

• 指标名：ingress_requests

• 指标类型：Gauge

• 聚合周期：30s

• 指标说明：表示一个聚合周期内在标签对应维度上被统计到的请求量数值。

• 指标标签：

  标签名称	说明	示例值
  ingress_cluster	Nginx Ingress控制器 （Controller）Deployment名称。	nginx-ingress-controller
  ingress_cluster_instance	Nginx Ingress控制器（Controller）Pod名称。	nginx-ingress-controller-6fdbbc5856-pcxkz
  ingress_cluster_namespace	Nginx Ingress控制器（Controller）所在命名空间。	kube-system
  host	请求头携带的Host名，可识别流量是从哪个Ingress路由规则进来的，如果是不合规的请求，该值为“_”。	my.otel-demo.com
  service	请求转发的后端服务名，如果是不合规的请求，该值为空。	default-my-otel-demo-frontend-8080
  uri	收敛后的URL路径。	/(.+)
  method	请求方法。	GET
  status_code	响应状态码。	200

基于地理的请求量指标（ingress_geoip_requests）

• 指标名：ingress_geoip_requests

• 指标类型：Gauge

• 聚合周期：30s

• 指标说明：表示一个聚合周期内在标签对应维度上被统计到的请求量数值，标签中富化了地理信息。

• 指标标签：

  标签名称	说明	示例值
  ingress_cluster	Nginx Ingress控制器 （Controller）Deployment名称。	nginx-ingress-controller
  ingress_cluster_instance	Nginx Ingress控制器（Controller）Pod名称。	nginx-ingress-controller-6fdbbc5856-pcxkz
  ingress_cluster_namespace	Nginx Ingress控制器（Controller）所在命名空间。	kube-system
  host	请求头携带的Host名，可识别流量是从哪个Ingress路由规则进来的，如果是不合规的请求，该值为“_”。	my.otel-demo.com
  service	请求转发的后端服务名，如果是不合规的请求，该值为空。	default-my-otel-demo-frontend-8080
  country_codeC	请求来源IP所在国家编码。	CN
  country_name	请求来源IP所在国家名称。	China
  region_name	请求来源IP所在省份名称。	Zhejiang
  city_name	请求来源IP所在城市名称。	Hangzhou
  timezone	请求来源IP所在时区名称。	Asia/Shanghai

  说明

  这里刻意裁剪了标签中URI、Method、Status Code等几个维度信息，该指标常见的使用场景中，请求路径的粒度至服务（Service）级即可满足，更细的粒度需要更昂贵的存储，且使用价值较低。

基于设备的请求量指标（ingress_user_agent_requests）

• 指标名：ingress_user_agent_requests

• 指标类型：Gauge

• 聚合周期：30s

• 指标说明：表示一个聚合周期内在标签对应维度上被统计到的请求量数值，标签中富化了设备信息。

• 指标标签：

  标签名称	说明	示例值
  ingress_cluster	Nginx Ingress控制器 （Controller）Deployment名称。	nginx-ingress-controller
  ingress_cluster_instance	Nginx Ingress控制器（Controller）Pod名称。	nginx-ingress-controller-6fdbbc5856-pcxkz
  ingress_cluster_namespace	Nginx Ingress控制器（Controller）所在命名空间。	kube-system
  host	请求头携带的Host名，可识别流量是从哪个Ingress路由规则进来的，如果是不合规的请求，该值为“_”。	my.otel-demo.com
  service	请求转发的后端服务名，如果是不合规的请求，该值为空。	default-my-otel-demo-frontend-8080
  browser_family	请求来源的浏览器类型，如果无法正确识别，该值为“<null>”。	Chrome
  device_category	请求来源的设备类型，如果无法正确识别，该值为“<null>”。	mobile
  os_family	请求来源的操作系统类型，如果无法正确识别，该值为“<null>”。	iPhone

  说明

  这里刻意裁剪了标签中URI、Method、Status Code等几个维度信息，该指标常见的使用场景中，请求路径的粒度至服务（Service）级即可满足，更细的粒度需要更昂贵的存储，且使用价值较低。

请求延迟分桶指标（ingress_request_time）

• 指标名：ingress_request_time

• 指标类型：GaugeHistogram

• 聚合周期：30s

• 指标说明：表示一个聚合周期内在标签对应维度上被统计到的请求延迟分桶值。

• 指标标签：

  标签名称	说明	示例值
  ingress_cluster	Nginx Ingress控制器 （Controller）Deployment名称。	nginx-ingress-controller
  ingress_cluster_instance	Nginx Ingress控制器（Controller）Pod名称。	nginx-ingress-controller-6fdbbc5856-pcxkz
  ingress_cluster_namespace	Nginx Ingress控制器（Controller）所在命名空间。	kube-system
  host	请求头携带的Host名，可识别流量是从哪个Ingress路由规则进来的，如果是不合规的请求，该值为“_”。	my.otel-demo.com
  service	请求转发的后端服务名，如果是不合规的请求，该值为空。	default-my-otel-demo-frontend-8080
  uri	收敛后的URL路径。	/(.+)
  method	请求方法。	GET
  status_code	响应状态码。	200

  说明

  请留意当前指标类型并非常见的Histogram类型：每个桶的数值为计数器模型；而GaugeHistogram 类型：每个桶的数值为当前聚合周期内观察到的一种“瞬时值”，因此如果要对这种指标进行分位数计算，参考表达式：histogram_quantile(0.95, sum(sum_over_time(ingress_request_time_bucket{...}[1m])) by (le))。

入流量指标（ingress_request_size）

• 指标名：ingress_request_size

• 指标类型：Gauge

• 聚合周期：30s

• 指标说明：表示一个聚合周期内在标签对应维度上被统计到的请求报文总字节数。

• 指标标签：

  标签名称	说明	示例值
  ingress_cluster	Nginx Ingress控制器 （Controller）Deployment名称。	nginx-ingress-controller
  ingress_cluster_instance	Nginx Ingress控制器（Controller）Pod名称。	nginx-ingress-controller-6fdbbc5856-pcxkz
  ingress_cluster_namespace	Nginx Ingress控制器（Controller）所在命名空间。	kube-system
  host	请求头携带的Host名，可识别流量是从哪个Ingress路由规则进来的，如果是不合规的请求，该值为“_”。	my.otel-demo.com
  service	请求转发的后端服务名，如果是不合规的请求，该值为空。	default-my-otel-demo-frontend-8080

  说明

  这里刻意裁剪了标签中URI、Method、Status Code等几个维度信息，该指标常见的使用场景中，请求路径的粒度至服务（Service）级即可满足，更细的粒度需要更昂贵的存储，且使用价值较低。

出流量指标（ingress_response_size）

• 指标名：ingress_response_size

• 指标类型：Gauge

• 聚合周期：30s

• 指标说明：表示一个聚合周期内在标签对应维度上被统计到的响应报文总字节数，受Nginx Ingress实现限制，这里只能统计到响应体的字节数，不包含响应头的大小。

• 指标标签：

  标签名称	说明	示例值
  ingress_cluster	Nginx Ingress控制器 （Controller）Deployment名称。	nginx-ingress-controller
  ingress_cluster_instance	Nginx Ingress控制器（Controller）Pod名称。	nginx-ingress-controller-6fdbbc5856-pcxkz
  ingress_cluster_namespace	Nginx Ingress控制器（Controller）所在命名空间。	kube-system
  host	请求头携带的Host名，可识别流量是从哪个Ingress路由规则进来的，如果是不合规的请求，该值为“_”。	my.otel-demo.com
  service	请求转发的后端服务名，如果是不合规的请求，该值为空。	default-my-otel-demo-frontend-8080

  说明

  这里刻意裁剪了标签中URI、Method、Status Code等几个维度信息，该指标常见的使用场景中，请求路径的粒度至服务（Service）级即可满足，更细的粒度需要更昂贵的存储，且使用价值较低。

Nginx Ingress网关监控进阶指南

编辑CR扩展URI收敛规则

由于访问日志中的请求路径这类明细数据是不可枚举的，直接放入Ingress请求指标的标签中将导致维度发散，存储成本急剧上升，甚至影响指标查询。

采集器会在第一次启用时扫描当前K8s集群的Ingress资源，并根据已有的路由规则提供的Path信息组装收敛规则。如果这部分配置无法满足您的分析、统计需要，请参照下列步骤进行扩展。

1. 执行命令 kubectl edit ingresslog -narms-prom ingresslog-<您的采集配置名>，进入这个自定义资源的编辑窗口，如：kubectl edit ingresslog -narms-prom ingresslog-default-ingress-nginx。

2. 找到spec.logParser.reduceUri.allowList字段，对其进行扩展。比如，它默认可能只有两条收敛规则：

       reduceUri:
         allowList:
           - pattern: ^/(.+)$
             reduced: /(.+)
           - pattern: ^/$
             reduced: /

   说明

   allowList字段为一个数组对象，它的每一个元素即表示一个收敛规则，每个收敛规则下的pattern字段表示匹配表达式，reduced字段表示收敛后文本。

3. 根据您实际的业务场景，可按如下参考示例进行改写：

       reduceUri:
         allowList:
           - pattern: ^/api/cart$
             reduced: /api/cart
           - pattern: ^/api/checkout$
             reduced: /api/checkout
           - pattern: ^/api/data$
             reduced: /api/data
           - pattern: ^/api/data/\?contextKeys=(.+)$
             reduced: /api/data/?contextKeys=(.+)
           - pattern: ^/api/products/(.+)$
             reduced: /api/products/(.+)
           - pattern: ^/api/recommendations/\?productIds=(.+)$
             reduced: /api/recommendations/?productIds=(.+)
           - pattern: ^/(.+)$
             reduced: /(.+)
           - pattern: ^/$
             reduced: /

   说明

   这里请按照顺序，将最短匹配路径的规则放到列表末，如：^/$。保存该配置后等待2~3分钟，即可在大盘看到根据URI收敛规则扩展后的进一步细化的指标数据。

扩展URI收敛规则会细化您的时间线，导致生成的指标数量上升，影响计费，请及时关注指标量的变化。

参考：Nginx Ingress网关监控实现方式

基于Exporter指标

nginx_ingress_controller_requests{canary="",controller_class="k8s.io/ingress-nginx",controller_namespace="kube-system",controller_pod="nginx-ingress-controller-6fdbbc5856-pcxkz",host="my.otel-demo.com",ingress="my-otel-demo",method="GET",namespace="default",path="/",service="my-otel-demo-frontend",status="200"} 2.401964e+06
nginx_ingress_controller_requests{canary="",controller_class="k8s.io/ingress-nginx",controller_namespace="kube-system",controller_pod="nginx-ingress-controller-6fdbbc5856-pcxkz",host="my.otel-demo.com",ingress="my-otel-demo",method="GET",namespace="default",path="/",service="my-otel-demo-frontend",status="304"} 111
nginx_ingress_controller_requests{canary="",controller_class="k8s.io/ingress-nginx",controller_namespace="kube-system",controller_pod="nginx-ingress-controller-6fdbbc5856-pcxkz",host="my.otel-demo.com",ingress="my-otel-demo",method="GET",namespace="default",path="/",service="my-otel-demo-frontend",status="308"} 553545
nginx_ingress_controller_requests{canary="",controller_class="k8s.io/ingress-nginx",controller_namespace="kube-system",controller_pod="nginx-ingress-controller-6fdbbc5856-pcxkz",host="my.otel-demo.com",ingress="my-otel-demo",method="GET",namespace="default",path="/",service="my-otel-demo-frontend",status="404"} 55
nginx_ingress_controller_requests{canary="",controller_class="k8s.io/ingress-nginx",controller_namespace="kube-system",controller_pod="nginx-ingress-controller-6fdbbc5856-pcxkz",host="my.otel-demo.com",ingress="my-otel-demo",method="GET",namespace="default",path="/",service="my-otel-demo-frontend",status="499"} 2
nginx_ingress_controller_requests{canary="",controller_class="k8s.io/ingress-nginx",controller_namespace="kube-system",controller_pod="nginx-ingress-controller-6fdbbc5856-pcxkz",host="my.otel-demo.com",ingress="my-otel-demo",method="GET",namespace="default",path="/",service="my-otel-demo-frontend",status="500"} 64
nginx_ingress_controller_requests{canary="",controller_class="k8s.io/ingress-nginx",controller_namespace="kube-system",controller_pod="nginx-ingress-controller-6fdbbc5856-pcxkz",host="my.otel-demo.com",ingress="my-otel-demo",method="GET",namespace="default",path="/",service="my-otel-demo-frontendproxy",status="200"} 59599
nginx_ingress_controller_requests{canary="",controller_class="k8s.io/ingress-nginx",controller_namespace="kube-system",controller_pod="nginx-ingress-controller-6fdbbc5856-pcxkz",host="my.otel-demo.com",ingress="my-otel-demo",method="GET",namespace="default",path="/",service="my-otel-demo-frontendproxy",status="304"} 15
nginx_ingress_controller_requests{canary="",controller_class="k8s.io/ingress-nginx",controller_namespace="kube-system",controller_pod="nginx-ingress-controller-6fdbbc5856-pcxkz",host="my.otel-demo.com",ingress="my-otel-demo",method="GET",namespace="default",path="/",service="my-otel-demo-frontendproxy",status="308"} 15709
nginx_ingress_controller_requests{canary="",controller_class="k8s.io/ingress-nginx",controller_namespace="kube-system",controller_pod="nginx-ingress-controller-6fdbbc5856-pcxkz",host="my.otel-demo.com",ingress="my-otel-demo",method="GET",namespace="default",path="/",service="my-otel-demo-frontendproxy",status="403"} 235
nginx_ingress_controller_requests{canary="",controller_class="k8s.io/ingress-nginx",controller_namespace="kube-system",controller_pod="nginx-ingress-controller-6fdbbc5856-pcxkz",host="e-commerce.

使用开源或阿里云Prometheus Agent配合服务发现策略即可完成指标抓取与上报，通过PromQL实现分析、告警配置，或通过Grafana实现指标数据可视化展现。但这种监控实现方式在生产实践中存在以下几点问题。

• 问题1：暴露太多不实用的Histogram指标

  对生产或测试集群中的Nginx Ingress进行一次抓取，会发现它所展现的指标清单中，Histogram类型指标占据非常多数量，Histogram指标一般以<metric_name>_bucket命名，配合<metric_name>_count和 <metric_name>_count一起使用。并且，其中包含常见分析不会使用的指标， 如：

  • nginx_ingress_controller_request_size_bucket：对每个请求体大小的分桶采样。

  • nginx_ingress_controller_bytes_sent_bucket：对每个响应体大小的分桶采样。

  默认情况下，如果不在Prometheus的metric_relabel_configs采集配置中执行drop操作，这些指标都会被抓取、上报，占用大量带宽与存储资源。

• 问题2：Pull模式拉取太多不活跃的时间线

  当第一个问题遇到Prometheus Agent的Pull模式，情况变得更加糟糕，如果某个访问频率不那么高的微服务，历史只要发生过一次请求，那么与它有关的所有时间线会在Nginx Ingress暴露的指标清单中一直出现。在每个抓取周期中，被不停采集、上报，资源浪费加剧。

  这个现象背后的本质问题是一个计数器类型指标在观察周期内无变化时，如何避免上报。

• 问题3：Ingress Path不可扩展、下钻

  一般体现HTTP流量的监控指标，URL Path是个很难处理的对象，如果直接将每个请求的URL Path加入到指标标签作为分析用途，将产生可怕的“维度爆炸”问题，可如果不加入这个信息，又无法实现指标细粒度的下钻分析。

  Nginx Ingress暴露的指标中，通过path标签记录Ingress规则中对应的请求路径字段，如“/(.+)”、“/login”、“/orders/(.+)”，避免了URL Path明细不可枚举问题。但当用户想实现更细粒度的下钻分析时，如希望看到“/users/(.+)/follower”、“/users/(.+)/followee”两个不同URL Pattern的统计数据，无法扩展，预置在Nginx Ingress实现中的这部分指标计算逻辑不可编程。

• 问题4：缺少地理、设备信息的分析

  通常，网站系统的运维人员更关注请求来源侧信息，如：

  • 访问网站的用户分布在全国哪几个省市，其中， Top10的城市是哪些。

  • 用户通过移动端还是PC端访问网站，其中，移动端有多少是iOS机型，有多少是Android机型。

  这些数据也是Nginx Ingress自身暴露的指标中所未体现的。

• 问题5：Kubernetes官方Grafana大盘布局不够聚焦

  虽然与Nginx Ingress暴露的指标无关，但用户一般会搭配Kubernetes官方提供的Grafana大盘进行数据可视化展现，所以也作为一个问题记录。如下图所示为Kubernetes官方提供的基于Nginx Ingress产出自监控指标的Grafana大盘。

  前面提到，在针对入口流量的监控场景中，我们一般关注“RED”指标：请求速率（Rate）、请求失败数（Errors）、请求延迟（Duration）。但面对这张大盘首屏，如果站在分析请求流量的用户视角，它的布局或者信息结构显得不是那么合理，因此，提供一张聚焦、好用的大盘，也是实现Nginx Ingress网关监控很重要的部分。

基于访问日志统计

综上所述，基于Nginx Ingress原生的自监控指标在生产实践中存在诸多问题，阿里云Prometheus监控提供的Nginx Ingress网关监控则采用另一种基于访问日志统计的方式。

与开源版的Nginx类似，Nginx Ingress会往它的Ingress Controller Pod标准输出中打印每一条请求的日志，这里称为访问日志（Access Log）。