统一观测丨使用 Prometheus 监控云原生网关，我们该关注哪些指标？

Metrics 指标在可观测体系的应用

可观测体系的概念由来已有，随着分布式微服务迅猛发展，对可观测体系的依赖也越来越深，可观测体系通常包括 Metrics、Tracing、Logging 三类数据，再外加报警机制，即可构成完整的监控报警机制，业界对可观测也有系统性说明，如下：

回到我们日常问题排查，基本路径大致分为 Detect（检测）、Troubleshoot（问题初步定位）、Pinpoint（精确定位）三个阶段，其分别对应可观测的三部分内容：Metrics、Traces、Logs，相信读到这里您已经理解 Metrics 指标的重要性了，它是我们发现问题的首要手段。

Metrics 指标的分类

我们希望使用指标来检测问题，首先我们要定义各种指标，指标的定义多种多样，不同的业务应用也都会有其符合自身要求的一些指标，但我们仍然可以对指标做一些粗粒度的分类，如下：

其中最受关注的无疑是核心业务指标，其重要性毋庸置疑，例如所有业务都会具备的三大核心指标：QPS、成功率、RT，其次是基础指标与其他指标。所以任何应用一定要保证核心业务指标准确与实时。同时，搭配基础指标才能对问题发现实现事半功倍的效果，尤其是程序运行期的一些问题。

Metrics 指标在网关场景的应用

聚焦于网关的可观测场景，网关的职责是高效的将符合某组特性的流量转发给目标服务，核心主要在于对网络流量的处理，三大核心指标：QPS、成功率、RT 依然是反映服务核心运行状况的核心指标。

值得说明的是，在网关场景中三大指标并不能完全真实反映网关实际运行状况，三大指标异常抖动常常跟后端服务抖动相关。因此，实际观测中我们将网关分为 Downstream 指标（观测 Client 侧的指标集合）、Upstream 指标（观测上游 Service 服务维度的指标集合)、路由指标（观测路由转发规则维度的指标集合）。同时，网关作为流量入口还有一些功能性指标，如解压缩 GZip、认证鉴权 Authz 等指标。

实际应用中还会有其他网络指标如接手、发送的数据量等，限于篇幅就不进行赘述。

MSE 云原生网关在可观测体系的实践

在虚拟化时期的微服务架构下，业务通常采用流量网关 + 微服务网关两层架构，流量网关负责南北向流量调度和安全防护，微服务网关负责东西向流量调度和服务治理。而在容器和 K8s 主导的云原生时代，Ingress 成为 K8s 生态的网关标准，赋予了网关新使命，使流量网关 + 微服务网关合二为一成为可能。MSE 云原生网关正是在这种背景下诞生，其基于阿里开源 Higress[1] 构建，在能力不打折的情况下将两层网关二合一，不仅可以节省 50% 的资源部署成本，还极大降低运维及使用成本。