如何利用 Apache APISX 提高 Nginx 的可观测性

"可观测性"是一种度量手段，方便掌握基础设施、系统平台或者应用程序的运行情况。常见的手段是收集 metrics、logging 和 tracing 及 events 数据，能够帮助开发/运维人员检测、调查、预警和纠正系统问题。 ​ 本文将从 Nginx 可观测性、Apache APISIX 与 Nginx 的关系、Apache APISIX 可观测性，以及结合 Apache SkyWalking 进一步提高可观测性这些方面分享关于可观测性的方案与实践。 ​

Nginx 的可观测性

一、Nginx 常见监控方式

Nginx 在必定程度上可以作到可观测，如下罗列出 Nginx 的常见监控方式： ​

• ngx_http_stub_status_module。
• VTS module + [exporter] + prometheus + grafana。（若是 Nginx 版本比较低，须要引入 exporter ）
• Nginx Amplify SaaS。 ​

ngx_http_stub_status_module

ngx_http_stub_status_module 主要收集实例级别的统计信息。 ​

VTS module

VTS module 有三个比较明显的缺点。 ​

• 安装复杂 虽然 VTS module 可以采集指标，采集的指标类型也比较多，可是它的安装比较复杂。若是想要采用 VTS module，须要从新编译 Nginx，在编译 Nginx 以前加入 VTS moudle，完成编译后从新安装 Nginx 才能够正常使用 VTS。 ​
• 扩展能力弱 VTS 扩展能力分为两部分，一是在编译以前给 VTS 增长扩展；二是在编译以后增长扩展 —— 修改 nginx.conf 配置文件。经过修改 nginx.conf 文件来增长扩展会使 Nginx reload，生产环境直接 reload 或多或少会对业务产生一些影响。 ​
• 社区更新缓慢 VTS module 最新的一次更新是在 2018 年，已经停摆 3 年了。 ​

Nginx Amplify SaaS

Nginx Amplify 是一个 SaaS 服务，Nginx Amplify 在远端提供服务，在 Nginx 服务以外安装 Agent。 ​ 在 Nginx 以外安装采集模块，那么在采集指标上就会有限制，只能拿到 Nginx 暴露出来的信息，没有暴露的内部信息是拿不到的。 ​ 另外，这是一个 SaaS 服务，须要经过公网将采集到的数据传到服务端，这会带来一些安全隐患，同时把一些企业用户阻挡在外面。或许 Nginx Amplify 的目标群体是 Nginx plus 这样的企业用户，不是开源用户。 ​ Nginx Amplify SaaS 社区也不活跃，已经停摆 2 年。 ​

二、Nginx 自身 Events 缺陷

Nginx 在 Events 收集上自身有缺陷，这里列举出两个问题： ​ 1、Nginx 基于 nginx.conf 进行配置，修改后经过 reload nginx.conf 文件使配置生效。除 reload 事件外，没有其余 Events 可用，咱们没法得知每次修改文件的变化，如：起初只配置一个路由，修改文件增长十个路由，只有 reload 事件没法得知增长的十个路由是哪十个路由。 ​ 2、Nginx 开源产品缺乏主动健康检查。Nginx 是一个反向代理，真正的后端服务可能会出现重启、升级或者异常的状况，若是没有主动的健康检查，依靠被动检查，只能在流量出现异常的时候，才知道服务出了问题，这会丢掉不少 Events，致使上游 Events 事件信息不完整。 ​

三、Nginx 可观测性总结

Nginx 的开源版本没有提供很是好用的监控。虽然 Nginx 提供了一些监控工具，但这些工具的安装和配置很是复杂，几乎没有扩展性。可能这些工具的设计并非为了可观测性，只是为了能看到指标或统计数据，方便定位问题。如今有各类可观测性设置类的产品，可是很难集成到 Nginx 上。 ​ 另外，Nginx 社区停滞不前，致使 Nginx 迭代速度慢。 ​

Apache APISIX 概述

1. Apache APISIX 与 Nginx 的关系

​ Apache APISIX 基于 Nginx 实现，但只依赖 Nginx 的网络库，在 Nginx 基础上，Apache APISIX 实现了本身的核心的代码，并预留了扩展机制。 ​ 在表格中列出了 Apache APISIX 和 Nginx 的功能对比，Apache APISIX 既能够作反向代理，又能够作 Nginx 不支持的功能，如：主动健康检查、流量管理、横向扩缩容等，并且这些功能都是开源的。 ​

• API 设计：在 API 设计方面使用 Apache APISIX 更加简单。
• 开源Dashboard：在界面上就能把反向代理所有配置完。
• 主动健康检查：Apache APISIX 支持主动健康检查，能够结合 Events 完善可观测性。
• 流量管理：适合监测数据，或者在业务发布上线时使用。
• 横向扩缩容：Apache APISIX 支持横向扩缩容，这个特性得益于 Apache APISIX 的架构（见下图）。
• 插件扩展机制
• 插件编排：按照业务需求，将多个插件按照逻辑编排，组合起来使用
• 动态的证书管理 ​ ​

二、Apache APISIX 简介

Apache APISIX 是一个动态、实时、高性能的 API 网关，提供负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。Apache APISIX 也是全世界最活跃的开源 API 网关项目，是生产可用的高性能网关。全球已有数百家企业使用 Apache APISIX 处理关键业务流量，涵盖金融、互联网、制造、零售、运营商等等，好比美国航空航天局（NASA）、欧盟的数字工厂、中国航信、中国移动、腾讯、华为、微博、网易、贝壳找房、360、泰康等。 ​

三、Apache APISIX 解决方案

​ 上图左边，从上往下的是从单体服务到 SOA（面向服务的架构）到微服务的演进过程。 ​ 在 SOA 下，网关通常采用 Nginx 或者 HAProxy；在微服务架构下，网关使用 Nginx 作负载均衡。微服务架构有两个比较常见的解决方案：一个是基于 Java 技术栈实现，如 Spring Cloud 系列；另外一个是 Service Mesh。在这个演进过程当中，Apache APISIX 处于什么位置，能作什么呢?简单的说，左图中红色的部分（Nginx / HAProxy / Kong / Spring Cloud Zuul / Spring Cloud Gateway / Traefik / Envoy / Ingress Nginx）均可以替换为 Apache APISIX 的解决方案。 ​ 在 SOA 下有 Apache APISIX SLB 解决方案，在微服务架构下有 Apache APISIX Gateway，在 Kubernetes 部署有 Apache APISIX Ingress，在 Service Mesh 里部署有 Apache APISIX mesh。 ​ ​ 从业务请求的流量方面看，当客户端发起请求时会通过 LB，通过 Gateway，请求被分发到后端业务服务。红色的部分（LB / Gateway / Spring Cloud Gateway / K8s Ingress / Sidecar）均可以选择 Apache APISIX 做为解决方案。Apache APISIX 支持多语言开发插件，能够在 Java 体系下使用 Java 编写插件。 ​ Apache APISIX 是全流量的数据面，在 LB、Gateway、Ingress 和 sidecar 方面 Apache APISIX 都有相应的解决方案，他们是统一的解决方案，在可观测性方面也是统一的方案。当解决方案统一时，管理控制链也是很容易实现出来的。 ​

Apache APISIX 的可观测性

Apache APISIX 在可观测性上能够作哪些事情？Apache APISIX 可观测性上的优点在哪里？ ​

一、Apache APISIX 支持采集的数据类型

Apache APISIX 支持采集的数据类型： ​

• Tracing - 集成 SkyWalking
• Metrics - 集成 SkyWalking / Prometheus
• Logging - 集成 SkyWalking / other Logging Platforms ​ Apache APISIX 是一个网关类的产品，能够替代 Nginx 或者其余的网关；在可观测性上 Apache APISIX 能够集成多个 APM 或可观测性系统，如：Tracing 部分能够集成 SkyWalking，Metrics 指标上能够集成 SkyWalking 或 Prometheus，Logging 能够集成 SkyWalking 以及其余一些日志系统。 ​

二、Apache APISIX 在可观测性上的优点

2.一、高度扩展能力

Apache APISIX 能够经过插件扩展自身的能力，上面提到的三种数据类型，都是经过插件机制来实现的。 ​ 为何 Apache APISIX 扩展能力强？由于 Apache APISIX 支持自定义插件。Apache APISIX 支持多语言编写插件，默认采用 Lua 语言，也可使用 Java、Golang 等编程语言编写插件。 ​

2.二、灵活的配置能力

举三个例子来介绍下 Apache APISIX 灵活的配置能力。第一个例子是 Apache APISIX 能够在运行时修改 logging 的配置，如：增长 / 修改日志字段。修改日志字段是一个比较常见的需求，好比：业务刚开始上线时，配置好了日志字段，系统运行一段时间后，须要修改或者增长几个日志字段。若是使用 Nginx，经过修改 nginx.conf 文件实现需求，reload 使配置生效。Apache APISIX 只须要经过脚本把字段配置好，就会动态生效。 ​ 第二个灵活配置能力的例子是 Prometheus 的使用。在 Apache APISIX 里，想要建立 / 删除某一个 metric 或者扩展 metrics labels，只须要在 Prometheus 插件里新增一个 metircs 或者填写相关信息，Apache APISIX 有 hot reload 机制能够直接生效，不须要重启。 ​ 第三个灵活的配置能力体如今 Apache APISIX 的实现。Apache APISIX 把路由对象所有管理起来，在内存里有一套对象管理机制。在 Apache APISIX 里给某个 API 加插件，生效的级别能够细化到 API，每个 API 均可以绑定插件，也能够从 API 上把插件去掉。Apache APISIX 能够精细化控制到每个服务里面每个 API 的可观测性数据采集。换句话说，你能够只采集最关心的数据，并且这些配置都是动态生效的，能够随时调整。 ​

2.三、 活跃的社区

Apache APISIX 最重要的一个优点是有一个活跃的社区，一个活跃的社区可让产品快速迭代、变得愈来愈完善，让你们的需求获得知足。 ​ ​ 上图展现的是 Apache APISIX（绿色）、Kong（浅蓝）、mosn（黄色）、bfe （深蓝）贡献者增加曲线，Apache APISX 增加趋势最快，曲线最为陡峭。Apache APISIX 社区活跃度在同类型项目里面是最活跃的。 ​

结合 Apache SkyWalking，在可观测性上作进一步提高

Apache APISIX 与 Apache SkyWalking 结合能够作哪些提高？除了 SkyWalking tracing 插件，还能够将tracing、metrics、logging 和 events 汇聚到 SkyWalking，借助 SkyWalking 的聚合能力让数据实现联动。 ​

一、 SkyWalking Satellite

SkyWalking Satellite 由 Apache APISIX社区、Apache SkyWalking 社区、百度深度合做开发。 ​ ​ SkyWalking Satellite 按照上图步骤采集数据，SkyWalking Satellite 能够部署到更靠近产生数据的前端，以 sidecar 的形式存在。图中从上往下业务请求通过 Apache APISIX 代理到 Upsteam，Satellite 在 Apache APISIX 的旁边，以 sidecar 的形式部署，收集 Apache APISIX 的 tracing、metrics、logging 这三种数据类型的数据，经过 GRPC 协议发送给 SkyWalking。最重要的一点是：在这种部署方式下，Apache APISIX 不须要作任何改动就能够直接将三种数据类型集成到 SkyWalking。 ​

二、ALS 方案

ALS （Access Log Service）将通过 Apache APISIX 的访问日志发送出来，在普通的 access log 上增长特殊的字段，如：增长关键字段便于生成拓扑图，同时聚合出 metrics。 ​ ALS 方案最大的好处是能够直接经过 access log 方式分析和聚合出拓扑图、metrics 和 logging 这三种类型的数据。 ​ 在使用 Prometheus 时，若是配置了 URI 级别的 metrics 指标的统计，会致使整个 metrics 急剧膨胀。由于 URI 级别的服务可能有几十个，每一个 metrics 后面可能有许多 labels，这会下降网关性能，增长 metrics 获取难度。使用 ALS 方案，经过流的方式将数据发送给 SkyWalking，把计算的事情交给 SkyWalking，后续也方便查询，不会出现每隔几秒钟拉取一次很是庞大的数据的状况。 ​

三、将 Events 整合到 SkyWalking

经常使用的 Events 包括：配置分发、集群变化和健康检查。 ​

• 配置分发：在配置 API 分发时，可能会新增 / 修改 / 删除路由、增长插件。 ​
• 集群变化：集群发生变化时，须要知道集群里的服务数。如：扩容时 IP 会发生变化，变化体如今网关收到消息的时候。每一个过程都是一个事件，这些事件都须要被暴露出来。 ​
• 健康检查：主动探测是否健康。如：业务请求失败率忽然变高，事件探测到业务服务不健康，此时能够快速定位到问题。 ​

延伸阅读

问：Apache APISIX 的扩展机制是怎么实现的，扩展这个功能是否对 Apache APISIX 自己稳定性有影响？ 。 ​ 答：Apache APISIX 扩展机制得益于它的架构，能够在各个 phases （rewrite / access / header_filter / body_filter / preread_filter / log）增长业务逻辑。稳定性方面， Apahce APISIX 已经开源了近 50 个插件，每个插件都会有端到端的测试，这些插件都是通过验证的、是稳定可用的。可是自定义插件要遵循必定的规范，虽然很简单，可是你们也不能太随意。自定义插件的稳定性保证，须要由业务方本身来保证。 ​ 问：Nginx 的 nginx.conf 文件里面可能配置了不少规则，后面的规则可能被前面的规则拦截，不清楚后面的规则是否生效，Apache APISIX 是否有什么方法知道哪些规则已生效？ ​ 答： Nginx 的 nginx.conf 文件配置越多，配置服务越复杂，这个文件越难以维护。 ​ 可是在 Apache APISIX 里配置文件是固定的，Apache APISIX 官方提供的配置就是在大多数场景下的最优配置，其余路由的配置是经过 API 的方式配置进去的，路由配置都是在内存里面的。在管理方式上，能够经过多种组织方式管理你的路由，如：能够经过 Dashboard 来管理。 ​ 举例说明，好比有一个服务叫 ABC，在这个服务下面可会有各类路由定义，路由定义经过列表的方式进行查看，路由里有一个字段叫优先级，能够经过配置路由的优先级字段，让类似的路由规则按照优先级依次匹配。另一种路由查看方式是在 dashboard 中给 API 打上标签，可让路由的管理变得更加人性化，便于按照标签过滤查询路由列表。 ​

关于做者

金卫，Apache APISIX PMC 和 Apache SkyWalking committer ​ ​

关于 Apache APISIX

Apache APISIX 是一个动态、实时、高性能的开源 API 网关，提供负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。Apache APISIX 能够帮忙企业快速、安全的处理 API 和微服务流量，包括网关、Kubernetes Ingress 和服务网格等。 ​ 全球已有数百家企业使用 Apache APISIX 处理关键业务流量，涵盖金融、互联网、制造、零售、运营商等等，好比美国航空航天局（NASA）、欧盟的数字工厂、中国航信、中国移动、腾讯、华为、微博、网易、贝壳找房、360、泰康、奈雪的茶等。 ​ 200 余位贡献者，一同缔造了 Apache APISIX 这个世界上最活跃的开源网关项目。聪明的开发者们！快来加入这个活跃而多样化的社区，一块儿来给这个世界带来更多美好的东西吧！ ​

• Apache APISIX GitHub：github.com/apache/apis…
• Apache APISIX 官网：apisix.apache.org/
• Apache APISIX 文档：apisix.apache.org/zh/docs/api…