乐趣区

关于阿里云:统一观测丨使用-Prometheus-监控-Nginx-Ingress-网关最佳实践

jiezi

作者：凌竹

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] 实现数据采集与大盘创立。

  1. 入口申请流量

包含集群范畴全局的流量、某个 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]《工作负载性能监控组件接入》

https://help.aliyun.com/document_detail/445938.html

[2]《部署多个 Ingress Controller》

https://help.aliyun.com/document_detail/151524.htm

参考资料：

  • Kubernetes 官网文档
    • Ingress 介绍：https://kubernetes.io/zh-cn/docs/concepts/services-networking…
    • Ingress Controller 介绍：https://kubernetes.io/zh-cn/docs/concepts/services-networking…

<!—->

  • 阿里云 ACK 官网文档

<!—->

    • Ingress 概述：https://help.aliyun.com/document_detail/198892.html
    • Nginx Ingress 最佳实际：https://help.aliyun.com/document_detail/398740.html
退出移动版