本文介绍如何使用Prometheus监控Nginx Ingress网关。
功能入口
功能入口一:集成中心
登录ARMS控制台。
在左侧导航栏选择 ,进入可观测监控 Prometheus 版的实例列表页面。
- 单击目标Prometheus实例名称,进入集成中心页面。
功能入口二:接入中心
登录ARMS控制台。
在左侧导航栏单击接入中心,然后在组件应用区域单击Nginx Ingress网关监控卡片的添加,然后在弹出的页面根据控制台指引完成组件接入。
方式一:实现ACK集群默认安装的Nginx Ingress网关监控
这里以从集成中心入口为例,介绍接入Nginx Ingress组件的操作,具体步骤如下。
接入Nginx Ingress组件。
若您初次安装Nginx Ingress类型的组件:
在集成中心页面单击未安装区域Nginx Ingress 网关监控组件卡片的安装。
说明单击该卡片,在弹出的面板中您可以看到关于Nginx Ingress网关监控常见的指标和大盘缩略预览效果图。这里列举出的指标只是常见的一部分指标信息,具体请参见下文Nginx Ingress网关监控指标模型。待您安装Nginx Ingress网关监控成功后,您将会查看到可观测监控 Prometheus 版监控Nginx Ingress网关监控的实际指标详情。
若您已安装Nginx Ingress 网关监控类型的组件,需要再次添加该组件:
在集成中心页面单击已安装区域Nginx Ingress 网关监控组件卡片的添加。
在弹出的面板的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网关,可以通过以下步骤实现监控接入。
接入Nginx Ingress组件。
若您初次安装Nginx Ingress类型的组件:
在集成中心页面单击未安装区域Nginx Ingress 网关监控组件卡片的安装。
说明单击该卡片,在弹出的面板中您可以看到关于Nginx Ingress网关监控常见的指标和大盘缩略预览效果图。这里列举出的指标只是常见的一部分指标信息,具体请参见下文Nginx Ingress网关监控指标模型。待您安装Nginx Ingress网关监控成功后,您将会查看到可观测监控 Prometheus 版监控Nginx Ingress网关监控的实际指标详情。
若您已安装Nginx Ingress 网关监控类型的组件,需要再次添加该组件:
在集成中心页面单击已安装区域Nginx Ingress 网关监控组件卡片的添加。
在弹出的面板的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页面,查看对应观测大盘。
整个Nginx Ingress网关监控可视化大盘分为六个区域,详情如下:
概览
概览区域通过体现流量与服务质量/体验的仪表盘设计充分展示了 RED 指标定义的要素:请求速率(Rate)、请求失败数(Errors)、请求延迟(Duration)。
体现流量的仪表盘
说明这里用不同的颜色区分指标,便于您查看相关数据。
当同比、环比上涨时使用红色显示指标值。
当同比、环比下跌时使用绿色显示指标值。
这里展示的是与流量相关的数据。
分钟级访问PV
小时级访问PV
与一天前的同比
与一小时前的环比
一天级访问PV
与一周前的同比
与一天前的环比v
一周级访问PV
与四周前(月)的同比
与一周前的环比
体现服务质量/体验的仪表盘
展示请求成功率、错误请求数、延迟等指标信息。这里对成功的请求定义是响应码为1XX、2XX、3XX,如果是4XX、5XX 则被计算为失败/错误的请求。这里为您介绍几种常见的错误响应码。
404:当该数值异常升高时,需要排查是否应用配置错误导致被搜索引擎抓取的页面无法正确加载。
429:当该数值异常升高时,需要关注是否有客户端以超过正常的频率访问后端服务导致限流。
499:当该数值异常升高时,需要关注是否因为后端服务响应耗时过久导致客户端提前关闭连接。
500:当该数值异常升高时,需要关注是否有后端服务因业务逻辑未正确实现导致内部错误。
503:当该数值异常升高时,需要关注是否有后端服务因为升级等原因导致不可用。
504:当该数值异常升高时,需要关注是否有后端服务响应超过了Nginx Ingress承受范围导致超时。
如上图所示,数据的不同颜色表达的意义不同,具体说明如下:
请求成功率
当大于90%时表现为绿色。
当大于50%但小于90%时表现为黄色。
当小于50%时表现为红色。
5XX比例
当大于50%时表现为红色。
当小于50%但大于10%时表现为黄色。
当小于10%时表现为绿色。
各类错误请求数:在当前周期内大于0即表现为黄色。
各类延迟指标:
当小于200ms时表现为绿色。
当小于500ms但大于200ms时表现为黄色。
当大于500ms时表现为红色。
说明正确的请求和错误请求,它们的延迟指标差异较大,因此建议通过顶部下拉筛选,指定正常响应码或错误响应码来区别分析。
服务统计-TopN
该区域通过排序的方式,展示访问PV前10、请求耗时前10、5XX比例前10的Host/域名、Service、URI。
访问PV
说明这里可以通过顶部下拉筛选,指定响应状态码来区别正常请求访问和错误请求访问的排名。
请求耗时
当小于200ms时表现为绿色。
当小于500ms但大于200ms时表现为黄色。
当大于500ms时表现为红色。
说明正确的请求和错误请求,它们的延迟指标差异较大,因此建议通过顶部下拉筛选,指定正常响应码或错误响应码来区别分析。
5XX比例
当大于50%时表现为红色。
当小于50%但大于10%时表现为黄色。
当小于10%时表现为绿色。
服务统计-趋势分布
该区域分别展示了Host/域名维度和Service维度各RED指标变化的趋势,以及请求在响应状态码、请求方法、Ingress Controller Pod上的分布。
Host/域名维度的RED指标
各Host/域名分钟级的PV变化。
各Host/域名分钟级的请求成功率变化。
各Host/域名分钟级的出入流量变化。
各Host/域名分钟级的延迟变化。
其中,PV趋势和延迟趋势,受顶部下拉筛选的响应状态码变化控制,可以区分正常请求和错误请求的PV和延迟。
Service维度的RED指标
各Service分钟级的PV变化。
各Service分钟级的请求成功率变化。
各Service分钟级的出入流量变化。
各Service分钟级的延迟变化。
其中,PV趋势和延迟趋势,受顶部下拉筛选的响应状态码变化控制,可以区分正常请求和错误请求的PV和延迟。
请求分布
请求流量分布在各响应状态码的占比与具体数值。
请求流量分布在各请求方法的占比与具体数值。
请求流量分布在各Ingress Controller Pod的占比与具体数值。
说明统计范围是当前顶部选择的时间段。
服务统计-请求分析
服务统计最后一部分则是将贯穿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请求指标的标签中将导致维度发散,存储成本急剧上升,甚至影响指标查询。
因此,实现Nginx Ingress网关监控的采集器会根据一组URI收敛规则对请求路径做精简,每个收敛规则由两部分组成:
匹配表达式:一个正则表达式,如果当前URI匹配命中,则进行收敛,如:$/api/product/(.+)$。
收敛后文本:将URI收敛为另一个具备可读性的字符串,如:ProductItem。
采集器会在第一次启用时扫描当前K8s集群的Ingress资源,并根据已有的路由规则提供的Path信息组装收敛规则。如果这部分配置无法满足您的分析、统计需要,请参照下列步骤进行扩展。
执行命令
kubectl edit ingresslog -narms-prom ingresslog-<您的采集配置名>
,进入这个自定义资源的编辑窗口,如:kubectl edit ingresslog -narms-prom ingresslog-default-ingress-nginx
。找到
spec.logParser.reduceUri.allowList
字段,对其进行扩展。比如,它默认可能只有两条收敛规则:reduceUri: allowList: - pattern: ^/(.+)$ reduced: /(.+) - pattern: ^/$ reduced: /
说明allowList
字段为一个数组对象,它的每一个元素即表示一个收敛规则,每个收敛规则下的pattern
字段表示匹配表达式,reduced
字段表示收敛后文本。根据您实际的业务场景,可按如下参考示例进行改写:
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收敛规则会细化您的时间线,导致生成的指标数量上升,影响计费,请及时关注指标量的变化。
请您及时在本地备份URI收敛规则,因为在卸载当前Nginx Ingress网关监控能力后,对应的 IngressLog自定义资源默认会被删除。
请不要改动IngressLog自定义资源中的其他配置,否则将导致Nginx Ingress网关监控无法正常工作。
参考:Nginx Ingress网关监控实现方式
基于Exporter指标
Kubernetes基于开源Nginx实现的Nginx Ingress发行版一大特色是其每个进程都扮演着Exporter角色,实现遵循Prometheus协议格式的自监控指标,如:
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)。
目前ACK默认的Nginx Ingress所打印的访问日志包含以下信息:
请求时间
请求来源IP
请求方法,如:GET
请求路径,如:/api/cart
响应状态码
请求体长度
响应体长度
请求耗时
请求上游服务名,如:default-my-otel-demo-frontend-8080。
请求User-Agent,如:Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/3.0)。
请求头携带的Host / 域名,如:my.otel-demo.com,这有助于确定流量是从哪个Ingress路由规则进来的。
基于这些信息,只需在K8s环境里部署一个采集器,通过预聚合计算方式即可实现入口流量RED指标统计,并通过可控的技术手段规避基于Exporter指标实施监控的几大问题:
暴露太多不实用的Histogram指标:制作一组精益指标,裁剪不需要的指标项,满足大部分统计分析场景需要。
Pull模式拉取太多不活跃的时间线:抛弃计数器模型,使用滚动窗口计算Gauge指标,窗口间数据独立,使用RemoteWrite方式推送,避免历史堆积时间线的重复上报。
Ingress Path不可扩展、下钻:预聚合逻辑可使用CR配置扩展,通过建立新的匹配规则实现下钻。
缺少地理、设备信息的分析:预聚合过程通过GeoIP、UserAgent分析等手段实现数据富化。
Kubernetes官方Grafana大盘布局不够聚焦:建立新的入口观测大盘,优化布局与信息结构,提升大盘的价值与体验。
- 本页导读 (1)