统一观测丨使用 Prometheus 监控 Nginx Ingress 网关最佳实践

作者：凌竹

01 Nginx Ingress 网关简介

在 Kubernetes 集群中，咱们一般运用 “Nginx Ingress” 完结集群南北向流量的代理转发，Nginx Ingress 依据集群内 Ingress 资源装备生成具体的路由规矩。Ingress 资源负责对外揭露服务的办理，一般这类服务经过 HTTP 协议进行拜访。经过 Nginx Ingress + Ingress 资源能够完结以下场景：

一、经过 Nginx Ingress 将来自客户端的全部流量转发给单一 Service。

图：Nginx Ingress 作业形式介绍

二、经过 Nginx Ingress 完结更杂乱的路由转发规矩，将来自单一绑定 IP 地址的所有流量依据 URL 恳求途径前缀转发给不同的 Service。

图：依据 URL 恳求途径的转发

三、依据 HTTP 恳求头部带着的 Host 字段——一般由拜访的域名决定，将来自单一绑定 IP 地址的流量分发给不同后端 Service，完结依据称号的虚拟主机（Name-based Virtual Hosting）才能。

图：依据 Host 恳求头的转发

一般，围绕 Nginx Ingress 网关监控场景，咱们一般会重视两类中心方针数据：

1. 作业负载资源

即 Nginx Ingress Controller Pod 的负载状况，当 CPU 、内存等资源水位处于饱和或过载，会导致集群对外服务不稳定。针对“作业负载监控”，一般建议重视 “USE” 方针，即：运用率（Utilization）、饱和度（Saturation）、过错率（Errors）。对此，阿里云 Prometheus 监控供给了预置功能监控大盘，可参阅 **《作业负载功能监控组件接入》 [ 1] **完结数据收集与大盘创立。

2. 进口恳求流量

包含集群规模全局的流量、某个 Ingress 规矩转发的流量、某个 Service 的流量，以及对应的成功率/过错率、推迟，乃至恳求来历的地址、设备等信息的剖析与核算。针对“进口恳求流量监控”，一般建议重视 “RED” 方针，即：恳求速率（Rate）、恳求失败数（Errors）、恳求推迟（Duration）。可经过本文最佳实践完结接入。

02 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 方针一般以 _bucket命名，配合 _count 和 _count 一同运用。而且，其间包含常见剖析不会运用的方针， 如：

1. nginx_ingress_controller_request_size_bucket：对每个恳求体巨细的分桶采样；
2. nginx_ingress_controller_bytes_sent_bucket：对每个呼应体巨细的分桶采样。

默许状况下，假如不在 Prometheus 的 metric_relabel_configs 收集装备中履行 drop 操作，这些方针都会被抓取、上报，占用大量带宽与存储资源。

问题 2：Pull 形式拉取太多不活泼的时刻线

当第一个问题遇到 Prometheus Agent 的 Pull 形式，状况变得更加糟糕，假如某个拜访频率不那么高的微服务，前史只需发生过一次恳求，那么与它有关的所有时刻线会在 Nginx Ingress 露出的方针清单中一直出现。在每个抓取周期中，被不断收集、上报，资源糟蹋加剧。

这个现象背后的实质问题是一个计数器类型方针在调查周期内无改变时，如何防止上报？咱们发现经过 Pull 形式很难落地一个好的解决方案，后文会介绍新的思路。

问题 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）。但面对这张大盘首屏，假如站在剖析恳求流量的用户视角，它的布局或许信息结构显得不是那么合理：

1. 我不重视 Ingress Controller 的衔接数，这是 HTTP 恳求下层的概念
2. 我不重视 Controller 等级的成功率，我更重视贯穿 Ingress / Host、Service、URI 途径上的成功率
3. 我不重视 Ingress Controller 的装备被 Reload 了多少次
4. 我不重视 Ingress Controller 上一次装备拉取失败
5. 我不重视 Ingress 证书到期时刻
6. ……

因而，供给一张聚集、好用的大盘，也是完结 “Nginx Ingress 网关监控” 无法逃避的工作。

依据拜访日志核算

综上所述，依据 Nginx Ingress 原生的自监控方针在生产实践中存在许多问题，阿里云 Prometheus 监控供给的 “Nginx Ingress 网关监控” 则选用另一种——依据拜访日志核算的办法。

与开源版的 Nginx 类似，Nginx Ingress 会往它的 Ingress Controller Pod 规范输出中打印每一条恳求的日志，咱们称为拜访日志（Access Log）：

172.16.0.20 - [172.16.0.20] - - [24/Mar/2023:17:58:26 +0800] "POST /api/cart HTTP/1.1" 500 32 "-" "Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/3.0)" 475 0.003 [default-my-otel-demo-frontend-8080] 172.16.0.17:8080 32 0.003 500 8f4dafe7280e421e9f6ca01efeacaf2d my.otel-demo.com []
172.16.0.20 - [172.16.0.20] - - [24/Mar/2023:17:58:26 +0800] "GET /api/products/HQTGWGPNH4 HTTP/1.1" 200 758 "-" "Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/3.0)" 334 0.001 [default-my-otel-demo-frontend-8080] 172.16.0.17:8080 758 0.002 200 e90aa6e5ffb7dfc03c0d576eb145fa29 my.otel-demo.com []
172.16.0.20 - [172.16.0.20] - - [24/Mar/2023:17:58:26 +0800] "POST /api/cart HTTP/1.1" 500 32 "-" "Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/3.0)" 475 0.003 [default-my-otel-demo-frontend-8080] 172.16.0.17:8080 32 0.002 500 dd7b9f42dbe53e72efe8768b1811525a my.otel-demo.com []
172.16.0.20 - [172.16.0.20] - - [24/Mar/2023:17:58:26 +0800] "GET /api/products/L9ECAV7KIM HTTP/1.1" 200 752 "-" "Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/3.0)" 334 0.002 [default-my-otel-demo-frontend-8080] 172.16.0.17:8080 752 0.001 200 883fec15467ed2e243a22345a0df9ed9 my.otel-demo.com []
172.16.0.20 - [172.16.0.20] - - [24/Mar/2023:17:58:26 +0800] "POST /api/cart HTTP/1.1" 500 32 "-" "Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/3.0)" 475 0.007 [default-my-otel-demo-frontend-8080] 172.16.0.17:8080 32 0.008 500 08ae27b3de3e112c47572255f3702af0 my.otel-demo.com []
172.16.0.20 - [172.16.0.20] - - [24/Mar/2023:17:58:26 +0800] "POST /api/checkout HTTP/1.1" 200 315 "-" "Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/3.0)" 765 0.194 [default-my-otel-demo-frontend-8080] 172.16.0.17:8080 315 0.194 200 4ed16b7f57394004d1d90383ce43a137 my.otel-demo.com []
172.16.0.20 - [172.16.0.20] - - [24/Mar/2023:17:58:26 +0800] "GET /api/products/6E92ZMYYFZ HTTP/1.1" 200 493 "-" "Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/3.0)" 334 0.002 [default-my-otel-demo-frontend-8080] 172.16.0.17:8080 493 0.002 200 674e2ae6c941f48a0bcaf0a7c57821c1 my.otel-demo.com []
172.16.0.20 - [172.16.0.20] - - [24/Mar/2023:17:58:26 +0800] "GET /api/products/66VCHSJNUP HTTP/1.1" 200 515 "-" "Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/3.0)" 334 0.001 [default-my-otel-demo-frontend-8080] 172.16.0.17:8080 515 0.002 200 245e689b406613eed45937d56c11339e my.otel-demo.com []
172.16.0.20 - [172.16.0.20] - - [24/Mar/2023:17:58:26 +0800] "GET /api/products/0PUK6V6EV0 HTTP/1.1" 200 438 "-" "Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/3.0)" 334 0.001 [default-my-otel-demo-frontend-8080] 172.16.0.17:8080 438 0.002 200 b6d2416865d34f601c460a2b382806b7 my.otel-demo.com []
172.16.0.20 - [172.16.0.20] - - [24/Mar/2023:17:58:26 +0800] "POST /api/checkout HTTP/1.1" 200 321 "-" "Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/3.0)" 772 0.214 [default-my-otel-demo-frontend-8080] 172.16.0.17:8080 321 0.214 200 63d8d6405b0d9a0ee65d6c1a13342f10 my.otel-demo.com []

现在 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 方针施行监控的几大问题：

1. “露出太多不实用的 Histogram 方针”——制造一组精益方针，裁剪不需求的方针项，满意大部分核算剖析场景需求；
2. “Pull 形式拉取太多不活泼的时刻线”——扔掉计数器模型，运用滚动窗口核算 Gauge 方针，窗口间数据独立，运用 RemoteWrite 办法推送，防止前史堆积时刻线的重复上报；
3. “Ingress Path”不行扩展、下钻——预聚合逻辑可运用 CR 装备扩展，经过建立新的匹配规矩完结下钻；
4. “短少地舆、设备信息的剖析”——预聚合进程经过 GeoIP、UserAgent 剖析等手段完结数据富化；
5. “Kubernetes 官方 Grafana 大盘布局不够聚集”——建立新的进口观测大盘，优化布局与信息结构，提高大盘的价值与体会。

03 Nginx Ingress 网关监控方针模型

通用恳求量方针（ingress_requests）

方针名：ingress_requests

方针类型：Gauge

聚合周期：30s

方针阐明：表明一个聚合周期内在标签对应维度上被核算到的恳求量数值

方针标签：

1. 依据地舆的恳求量方针（ingress_geoip_requests）

方针名：ingress_geoip_requests

方针类型：Gauge

聚合周期：30s

方针阐明：表明一个聚合周期内在标签对应维度上被核算到的恳求量数值，标签中富化了地舆信息

方针标签：

注：咱们故意裁剪了标签中 URI、Method、Status Code 等几个维度信息，该方针常见的运用场景中，恳求途径的粒度至服务（Service）级即可满意，更细的粒度需求更贵重的存储，且运用价值较低。

2. 依据设备的恳求量方针（ingress_user_agent_requests）

方针名：ingress_user_agent_requests

方针类型：Gauge

聚合周期：30s

方针阐明：表明一个聚合周期内在标签对应维度上被核算到的恳求量数值，标签中富化了设备信息

方针标签：

注：咱们故意裁剪了标签中 URI、Method、Status Code 等几个维度信息，该方针常见的运用场景中，恳求途径的粒度至服务（Service）级即可满意，更细的粒度需求更贵重的存储，且运用价值较低。

3. 恳求推迟分桶方针（ingress_request_time）

方针名：ingress_request_time

方针类型：GaugeHistogram

聚合周期：30s

方针阐明：表明一个聚合周期内在标签对应维度上被核算到的恳求推迟分桶值

方针标签：

注：请留心当时方针类型并十分见的 Histogram 类型——每个桶的数值为计数器模型，而是 GaugeHistogram 类型——每个桶的数值为当时聚合周期内调查到的一种“瞬时值”，因而假如要对这种方针进行分位数核算，参阅表达式：histogram_quantile(0.95,sum(sum_over_time(ingress_request_time_bucket{…}[1m])) by (le))。

4. 入流量方针（ingress_request_size）

方针名：ingress_request_size

方针类型：Gauge

聚合周期：30s

方针阐明：表明一个聚合周期内在标签对应维度上被核算到的恳求报文总字节数

方针标签：

注：咱们故意裁剪了标签中 URI、Method、Status Code 等几个维度信息，该方针常见的运用场景中，恳求途径的粒度至服务（Service）级即可满意，更细的粒度需求更贵重的存储，且运用价值较低。

5. 出流量方针（ingress_response_size）

方针名：ingress_response_size

方针类型：Gauge

聚合周期：30s

方针阐明：表明一个聚合周期内在标签对应维度上被核算到的呼应报文总字节数——受 Nginx Ingress 完结约束，这儿只能核算到呼应体的字节数，不包含呼应头的巨细

方针标签：

注：咱们故意裁剪了标签中 URI、Method、Status Code 等几个维度信息，该方针常见的运用场景中，恳求途径的粒度至服务（Service）级即可满意，更细的粒度需求更贵重的存储，且运用价值较低。

04 Nginx Ingress 网关监控接入

办法一：完结 ACK 集群默许装置的 Nginx Ingress 网关监控

假如您在创立 ACK 集群时勾选了装置 Nginx Ingress 组件，那么在集群的 kube-system空间下会有一组默许的 Ingress Controller Pod 完结网关流量代理，可经过下列办法完结这个默许 Nginx Ingress 网关的监控接入：

第一步：进入阿里云 Prometheus 监控集成中心

进入阿里云 Prometheus 监控，找到您 ACK 集群对应的 Prometheus 实例，在首页集成中心找到 “Nginx Ingress 网关监控”：

图：挑选“Nginx Ingress 网关监控”

第二步：填写装置参数

图：装置参数

• 假如您在 ACK 集群创立后没有对 Nginx Ingress 履行任何改变操作（如：更改命名空间、IngressClass 标识名等），可在这步直接点击“确认”提交装置。
• 假如您正在接入的是自建、第 N 套 Nginx Ingress 网关，请拜见下文“完结自建/多套 Nginx Ingress 网关监控”进行接入。

注：启用当时监控将在您的 K8s 集群中布置一个收集器作业负载（DaemonSet），资源约束为 0.5 核/512MB ，能够结合网关实践流量规划进行资源约束的调整，请经过 kubectl edit daemonset -narms-prom arms-vector 指令进行改变。

第三步：检查 Nginx Ingress 网关监控大盘

您能够打开 “Nginx Ingress 网关监控” 集成卡片侧边栏，在“大盘” TAB 页签找到名为 “Universal Ingress Observability Dashboard” 的大盘，点击跳转 Grafana 检查数据。

图：“大盘” TAB 页签

在您完结第二步装置后，且 Nginx Ingress 网关有真实流量数据的状况下，一般 2-3 分钟即可在大盘看到收集、上报的方针数据。

办法二：完结自建/多套 Nginx Ingress 网关监控

假如您是自建 Nginx Ingress 网关，或许参照 ACK 官方文档 **《布置多个 Ingress Controller》 [ 2] **在当时 K8s 集群内布置了多套 Nginx Ingress 网关，经过本节内容完结监控接入。

接入进程其他坚持不变，在 “Nginx Ingress 网关监控” 的装置页依据实践状况调整参数：

图：自定义装置参数

这儿需求重视的五个参数介绍如下：

• 收集装备称号：作为当时收集装备的唯一 ID 进行设置，如：otel-demo-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

注：监控多套 Nginx Ingress 网关会复用相同的收集器作业负载，它默许的资源约束为 0.5 核/512MB ，请重视网关实践流量规划，进行相应的资源约束调整，请经过 kubectl edit daemonset -narms-prom arms-vector 指令进行改变。

05 Nginx Ingress 网关监控可视化大盘

整个 Nginx Ingress 网关监控可视化大盘分为六个区域：

• 概览：表现首屏亟需重视的方针信息
• 服务核算 – TopN：以 TopN 视角展现 Host / 域名、服务、URI 的拜访 PV、耗时、成功率等信息
• 服务核算 – 趋势散布：展现 PV、收支流量、恳求成功率、推迟等趋势，以及状态码、恳求办法、Ingress Pod 恳求数等散布
• 服务核算 – 恳求剖析：以表格形式出现贯穿 Host / 域名、Service、Uri 恳求途径上的 PV、成功率、4XX 份额、5XX 份额、推迟状况
• 地舆核算：以占比视角和表格明细分别出现依据地舆信息的恳求状况
• 设备核算：以占比视角和表格明细分别出现依据设备信息的恳求状况

1. 概览

概览区域经过表现流量与服务质量/体会的仪表盘规划充沛展现了 RED 方针定义的要素：恳求速率（Rate）、恳求失败数（Errors）、恳求推迟（Duration）。

① 表现流量的仪表盘

图：PV 与流量

在 Nginx Ingress 网关监控可视化大盘的首屏顶部，即出现最重要的与流量相关的数据：

• 分钟级拜访 PV
• 小时级拜访 PV

• • 与一天前的同比
  • 与一小时前的环比

• 一天级拜访 PV

• • 与一周前的同比
  • 与一天前的环比

• 一周级拜访 PV

• • 与四周前（月）的同比
  • 与一周前的环比

一起，经过 Grafana 强壮的可视化才能，咱们用不同的色彩区别方针是否需求重视的现实，下文能够看到不止一处应用了这一实践：

• 当同比、环比上涨时运用赤色显现方针值
• 当同比、环比跌落是运用绿色显现方针值

② 表现服务质量/体会的仪表盘

图：成功率、过错数、推迟

概览区域同样表现了十分重要的恳求成功率、过错恳求数、推迟等方针信息。这儿对成功的恳求定义是呼应码为 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 时表现为赤色

此外，需求注意到，正确的恳求和过错恳求，它们的推迟方针差异较大，因而建议经过顶部下拉挑选，指定正常呼应码或过错呼应码来差异剖析。

2. 服务核算 – TopN

服务核算 – TopN 区域经过排序的办法，陈设拜访 PV 前 10、恳求耗时前 10、5XX 份额前 10 的 Host / 域名、Service、URI。

① 拜访 PV

图：拜访 PV 排名

这儿能够经过顶部下拉挑选，指定呼应状态码来差异正常恳求拜访和过错恳求拜访的排名。

② 恳求耗时

图：恳求耗时排名

这儿的色彩改变战略是：

• 当小于 200ms 时表现为绿色
• 当小于 500ms 但大于 200ms 时表现为黄色
• 当大于 500ms 时表现为赤色

此外，正确的恳求和过错恳求，它们的推迟方针差异较大，因而建议经过顶部下拉挑选，指定正常呼应码或过错呼应码来差异剖析。

③ 5XX 份额

图：5XX 份额排名

这儿的色彩改变战略是：

• 当大于 50% 时表现为赤色
• 当小于 50% 但大于 10% 时表现为黄色
• 当小于 10% 时表现为绿色

3. 服务核算 – 趋势散布

服务核算 – 趋势散布区域分别展现了 Host / 域名维度和 Service 维度各 RED 方针改变的趋势，以及恳求在呼应状态码、恳求办法、Ingress Controller Pod 上的散布。

① Host / 域名维度的 RED 方针

图：Host 维度 RED 方针

这部分仪表盘展现了各 Host / 域名的 RED 方针要素：

• 各 Host / 域名分钟级的 PV 改变
• 各 Host / 域名分钟级的恳求成功率改变
• 各 Host / 域名分钟级的收支流量改变
• 各 Host / 域名分钟级的推迟改变

其间，PV 趋势和推迟趋势，受顶部下拉挑选的呼应状态码改变操控，能够区别正常恳求和过错恳求的 PV 和推迟。

② Service 维度的 RED 方针

图：Service 维度 RED 方针

这部分仪表盘展现了各 Service 的 RED 方针要素：

• 各 Service 分钟级的 PV 改变
• 各 Service 分钟级的恳求成功率改变
• 各 Service 分钟级的收支流量改变
• 各 Service 分钟级的推迟改变

其间，PV 趋势和推迟趋势，受顶部下拉挑选的呼应状态码改变操控，能够区别正常恳求和过错恳求的 PV 和推迟。

③ 恳求散布

图：呼应状态码、恳求办法、Ingress Controller Pod 散布

这部分仪表盘用饼图展现了恳求流量在各维度上的散布：

• 恳求流量散布在各呼应状态码的占比与具体数值
• 恳求流量散布在各恳求办法的占比与具体数值
• 恳求流量散布在各 Ingress Controller Pod 的占比与具体数值

它们的核算规模是当时顶部挑选的时刻段。

4. 服务核算 – 恳求剖析

图：恳求剖析表格

服务核算最终一部分则是将贯穿 Host / 域名、Service、Uri 恳求途径上的 PV、成功率、4XX 份额、5XX 份额、推迟状况以表格形式具体出现。它们的核算规模是当时顶部挑选的时刻段。假如期望下钻看到更细粒度的 URI 恳求剖析核算，需求扩展 URI 收敛规矩， 请参阅进阶攻略部分的“修改 CR 扩展 URI 收敛规矩”。

5. 地舆核算

图：依据地舆信息的核算

地舆核算区域供给了各维度的占比状况和对应的表格：

• 拜访省份

• • 各拜访省份 / 地区的占比状况，核算规模是当时顶部挑选的时刻段
  • 拜访省份 / 地区的表格概况，核算规模是当时顶部挑选的时刻段

• 拜访城市

• • 各拜访城市的占比状况，核算规模是当时顶部挑选的时刻段
  • 拜访城市的表格概况，核算规模是当时顶部挑选的时刻段

• 拜访时区

• • 各拜访时区的占比状况，核算规模是当时顶部挑选的时刻段
  • 拜访时区的表格概况，核算规模是当时顶部挑选的时刻段

6. 设备核算

图：依据设备信息的核算

设备核算区域供给了各维度的占比状况和对应的表格：

• 设备类型维度

• • 各设备类型的占比、具体数值，核算规模是当时顶部挑选的时刻段
  • 设备类型的表格概况，核算规模是当时顶部挑选的时刻段

• 操作系统维度

• • 各操作系统的占比、具体数值，核算规模是当时顶部挑选的时刻段
  • 操作系统的表格概况，核算规模是当时顶部挑选的时刻段

• 浏览器维度

• • 各浏览器的占比、具体数值，核算规模是当时顶部挑选的时刻段
  • 浏览器的表格概况，核算规模是当时顶部挑选的时刻段

一镜到底效果图

06 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 收敛规矩会细化您的时刻线，导致生成的方针数量上升，影响计费，请及时重视方针量的改变。

注 1：请您及时在本地备份 URI 收敛规矩，由于在卸载当时 Nginx Ingress 网关监控才能后，对应的 IngressLog 自定义资源默许会被删去。

注 2：请不要改动 IngressLog 自定义资源中的其他装备，否则将导致 Nginx Ingress 网关监控无法正常作业！

相关链接：

[1]《作业负载功能监控组件接入》

help.aliyun.com/document_de…

[2]《布置多个 Ingress Controller》

help.aliyun.com/document_de…

参阅资料：

• Kubernetes 官方文档

• • Ingress 介绍：kubernetes.io/zh-cn/docs/…
  • Ingress Controller 介绍：kubernetes.io/zh-cn/docs/…

• 阿里云 ACK 官方文档

• • Ingress 概述：help.aliyun.com/document_de…
  • Nginx Ingress 最佳实践：help.aliyun.com/document_de…