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

"可观测性"是一种度量手段，方便掌握基础设施、系统平台或者应用程序的运行状况。常见的手段是收集metrics、logging和tracing及events数据，可以帮助开发/运维人员检测、调查、预警和纠正系统问题。

本文将从Nginx可观测性、ApacheAPISIX与Nginx的关系、ApacheAPISIX可观测性，以及结合ApacheSkyWalking进一步提升可观测性这些方面分享关于可观测性的方案与实践。

Nginx的可观测性

1.1Nginx常见监控方式

Nginx在一定程度上能够做到可观测，以下罗列出Nginx的常见监控方式：

ngx_http_stub_status_module。

VTSmodule+[exporter]+prometheus+grafana。（如果Nginx版本比较低，需要引入exporter）

NginxAmplifySaaS。

1.1.1ngx_http_stub_status_module

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

1.1.2VTSmodule

VTSmodule有三个比较明显的缺点。

一、安装复杂

虽然VTSmodule能够采集指标，采集的指标类型也比较多，但是它的安装比较复杂。如果想要采用VTSmodule，需要重新编译Nginx，在编译Nginx之前加入VTSmoudle，完成编译后重新安装Nginx才可以正常使用VTS。

二、扩展能力弱

VTS扩展能力分为两部分，一是在编译之前给VTS增加扩展；二是在编译之后增加扩展——修改配置文件。通过修改文件来增加扩展会使Nginxreload，生产环境直接reload或多或少会对业务产生一些影响。

三、社区更新缓慢

VTSmodule最新的一次更新是在2018年，已经停摆3年了。

1.1.3NginxAmplifySaaS

NginxAmplify是一个SaaS服务，NginxAmplify在远端提供服务，在Nginx服务之外安装Agent。

在Nginx之外安装采集模块，那么在采集指标上就会有限制，只能拿到Nginx暴露出来的信息，没有暴露的内部信息是拿不到的。

另外，这是一个SaaS服务，需要通过公网将采集到的数据传到服务端，这会带来一些安全隐患，同时把一些企业用户阻挡在外面。或许NginxAmplify的目标群体是Nginxplus这样的企业用户，不是开源用户。

NginxAmplifySaaS社区也不活跃，已经停摆2年。

1.2Nginx自身Events缺陷

Nginx在Events收集上自身有缺陷，这里列举出两个问题：

一、Nginx基于进行配置，修改后通过文件使配置生效。除reload事件外，没有其他Events可用，我们无法得知每次修改文件的变化，如：起初只配置一个路由，修改文件增加十个路由，只有reload事件无法得知增加的十个路由是哪十个路由。

二、Nginx开源产品缺少主动健康检查。Nginx是一个反向代理，真正的后端服务可能会出现重启、升级或者异常的情况，如果没有主动的健康检查，依靠被动检查，只能在流量出现异常的时候，才知道服务出了问题，这会丢掉很多Events，导致上游Events事件信息不完整。

1.3Nginx可观测性总结

Nginx的开源版本没有提供非常好用的监控。虽然Nginx提供了一些监控工具，但这些工具的安装和配置非常复杂，几乎没有扩展性。可能这些工具的设计并不是为了可观测性，只是为了能看到指标或统计数据，方便定位问题。现在有各种可观测性设置类的产品，但是很难集成到Nginx上。

另外，Nginx社区停滞不前，导致Nginx迭代速度慢。

2.ApacheAPISIX概述

2.1ApacheAPISIX与Nginx的关系

ApacheAPISIX基于Nginx实现，但只依赖Nginx的网络库，在Nginx基础上，ApacheAPISIX实现了自己的核心的代码，并预留了扩展机制。

在表格中列出了ApacheAPISIX和Nginx的功能对比，ApacheAPISIX既可以做反向代理，又可以做Nginx不支持的功能，如：主动健康检查、流量管理、横向扩缩容等，而且这些功能都是开源的。

API设计：在API设计方面使用ApacheAPISIX更加简单。

开源Dashboard：在界面上就能把反向代理全部配置完。

主动健康检查：ApacheAPISIX支持主动健康检查，可以结合Events完善可观测性。

流量管理：适合监测数据，或者在业务发布上线时使用。

横向扩缩容：ApacheAPISIX支持横向扩缩容，这个特性得益于ApacheAPISIX的架构（见下图）。

插件扩展机制

插件编排：按照业务需求，将多个插件按照逻辑编排，组合起来使用

动态的证书管理

ApacheAPISIX架构图

2.2ApacheAPISIX简介

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

2.3ApacheAPISIX解决方案

左图，从上往下是从单体服务到SOA（面向服务的架构）到微服务的演进过程。

在SOA下，网关一般采用Nginx或者HAProxy；在微服务架构下，网关使用Nginx做负载均衡。微服务架构有两个比较常见的解决方案：一个是基于Java技术栈实现，如SpringCloud系列；另一个是ServiceMesh。在这个演进过程中，ApacheAPISIX处于什么位置，能做什么呢?简单的说，左图中红色的部分（Nginx/HAProxy/Kong/SpringCloudZuul/SpringCloudGateway/Traefik/Envoy/IngressNginx）都可以替换为ApacheAPISIX的解决方案。

在SOA下有ApacheAPISIXSLB解决方案，在微服务架构下有ApacheAPISIXGateway，在Kubernetes部署有ApacheAPISIXIngress，在ServiceMesh里部署有ApacheAPISIXmesh。

从业务请求的流量方面看，当客户端发起请求时会经过LB，经过Gateway，请求被分发到后端业务服务。红色的部分（LB/Gateway/SpringCloudGateway/K8sIngress/Sidecar）都可以选择ApacheAPISIX作为解决方案。ApacheAPISIX支持多语言开发插件，可以在Java体系下使用Java编写插件。

ApacheAPISIX是全流量的数据面，在LB、Gateway、Ingress、sidecar方面ApacheAPISIX都有相应的解决方案，他们是统一的解决方案，在可观测性方面也是统一的方案。当解决方案统一时，管理控制链也是很容易实现出来的。

3.ApacheAPISIX的可观测性

ApacheAPISIX在可观测性上可以做哪些事情？ApacheAPISIX可观测性上的优势在哪里？

3.1ApacheAPISIX支持采集的数据类型

ApacheAPISIX支持采集的数据类型：

Tracing-集成SkyWalking

Metrics-集成SkyWalking/Prometheus

Logging-集成SkyWalking/otherLoggingPlatforms

ApacheAPISIX是一个网关类的产品，可以替代Nginx或者其他的网关；在可观测性上ApacheAPISIX可以集成多个APM或可观测性系统，如：Tracing部分可以集成SkyWalking，Metrics指标上可以集成SkyWalking或Prometheus，Logging可以集成SkyWalking以及其他一些日志系统。

3.2ApacheAPISIX在可观测性上的优势

3.2.1高度扩展能力

ApacheAPISIX可以通过插件扩展自身的能力，上面提到的三种数据类型，都是通过插件机制来实现的。

为什么ApacheAPISIX扩展能力强？因为ApacheAPISIX支持自定义插件。ApacheAPISIX支持多语言编写插件，默认采用Lua语言，也可以使用Java、Golang等编程语言编写插件。

3.2.2灵活的配置能力

举三个例子来介绍下ApacheAPISIX灵活的配置能力。第一个例子是ApacheAPISIX可以在运行时修改logging的配置，如：增加/修改日志字段。修改日志字段是一个比较常见的需求，比如：业务刚开始上线时，配置好了日志字段，系统运行一段时间后，需要修改或者增加几个日志字段。如果使用Nginx，通过修改文件实现需求，reload使配置生效。ApacheAPISIX只需要通过脚本把字段配置好，就会动态生效。

第二个灵活配置能力的例子是Prometheus的使用。在ApacheAPISIX里，想要创建/删除某一个metric或者扩展metricslabels，只需要在Prometheus插件里新增一个metircs或者填写相关信息，ApacheAPISIX有hotreload机制可以直接生效，不需要重启。

第三个灵活的配置能力体现在ApacheAPISIX的实现。ApacheAPISIX把路由对象全部管理起来，在内存里有一套对象管理机制。在ApacheAPISIX里给某个API加插件，生效的级别可以细化到API，每一个API都可以绑定插件，也可以从API上把插件去掉。ApacheAPISIX可以精细化控制到每一个服务里面每一个API的可观测性数据采集。换句话说，你可以只采集最关心的数据，而且这些配置都是动态生效的，可以随时调整。

3.2.3活跃的社区

ApacheAPISIX最重要的一个优势是有一个活跃的社区，一个活跃的社区可以让产品快速迭代、变得越来越完善，让大家的需求得到满足。

上图展示的是ApacheAPISIX（绿色）、Kong（浅蓝）、mosn（黄色）、bfe（深蓝）贡献者增长曲线，ApacheAPISX增长趋势最快，曲线最为陡峭。ApacheAPISIX社区活跃度在同类型项目里面是最活跃的。

4.结合ApacheSkyWalking，在可观测性上做进一步提升

ApacheAPISIX与ApacheSkyWalking结合可以做哪些提升？除了SkyWalkingtracing插件，还可以将tracing、metrics、logging、events汇聚到SkyWalking，借助SkyWalking的聚合能力让数据实现联动。

4.1SkyWalkingSatellite

SkyWalkingSatellite由ApacheAPISIX社区、ApacheSkyWalking社区、百度深度合作开发。

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

4.2ALS方案

ALS（AccessLogService）将经过ApacheAPISIX的访问日志发送出来，在普通的accesslog上增加特殊的字段，如：增加关键字段便于生成拓扑图，同时聚合出metrics。

ALS方案最大的好处是可以直接通过accesslog方式分析和聚合出拓扑图、metrics、logging这三种类型的数据。

在使用Prometheus时，如果配置了URI级别的metrics指标的统计，会导致整个metrics急剧膨胀。因为URI级别的服务可能有几十个，每个metrics后面可能有许多labels，这会降低网关性能，增加metrics获取难度。使用ALS方案，通过流的方式将数据发送给SkyWalking，把计算的事情交给SkyWalking，后续也方便查询，不会出现每隔几秒钟拉取一次非常庞大的数据的情况。

4.3将Events整合到SkyWalking

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

配置分发：在配置API分发时，可能会新增/修改/删除路由、增加插件。

集群变化：集群发生变化时，需要知道集群里的服务数。如：扩容时IP会发生变化，变化体现在网关收到消息的时候。每个过程都是一个事件，这些事件都需要被暴露出来。

健康检查：主动探测是否健康。如：业务请求失败率突然变高，事件探测到业务服务不健康，此时可以快速定位到问题。