Skip to main content

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

· One min read

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

概述#

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

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

Nginx 的可观测性#

Nginx 常见监控方式#

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

  1. ngx_http_stub_status_module
  2. VTS module + exporter + prometheus + grafana(如果 Nginx 版本比较低,需要引入 exporter )
  3. Nginx Amplify SaaS

ngx_http_stub_status_module#

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

VTS module#

VTS module 有 3 个比较明显的缺点:

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

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

  3. 社区更新缓慢:VTS module 最新的一次更新是在 2018 年,已经停摆 3 年了。

Nginx Amplify SaaS#

Nginx Amplify 是一个 SaaS 服务,Nginx Amplify 在远端提供服务,在 Nginx 服务之外安装 Agent。 在 Nginx 之外安装采集模块,那么在采集指标上就会有限制,只能拿到 Nginx 暴露出来的信息,没有暴露的内部信息是拿不到的。

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

另外,Nginx Amplify SaaS 社区也不活跃,已经停摆 2 年。

Nginx 的缺陷#

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

  1. Nginx 基于 nginx.conf 进行配置,修改后通过 reload nginx.conf 文件使配置生效。除 reload 事件外,没有其他 Events 可用,我们无法得知每次修改文件的变化,如:起初只配置 1 个路由,修改文件增加 10 个路由,只有 reload 事件无法得知增加的到低是哪 10 个路由。

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

Nginx 可观测性总结#

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

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

Apache APISIX 概述#

Apache APISIX 与 Nginx 的关系#

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 支持动态的证书管理。

Apache APISIX 架构图

Apache APISIX 简介#

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

Apache APISIX 解决方案#

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

Apache APISIX 全流量数据面

从业务请求的流量方面看,当客户端发起请求时会经过 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 的可观测性#

简单了解完 Nginx 和 Apache APISIX 之后,现在有两个问题:Apache APISIX 在可观测性上可以做哪些事情?Apache APISIX 可观测性上的优势在哪里?

Apache APISIX 支持采集的数据类型#

Apache APISIX 支持采集的数据类型:

  1. Tracing - 集成 SkyWalking
  2. Metrics - 集成 SkyWalking / Prometheus
  3. Logging - 集成 SkyWalking / 其他日志平台

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

Apache APISIX 在可观测性上的优势#

高度扩展能力#

为什么 Apache APISIX 拥有强大的扩展能力?因为 Apache APISIX 支持多语言编写插件,可以使用 Lua、Java、Golang 等编程语言编写插件。Apache APISIX 可以通过插件扩展自身的能力。上文提到的三种数据类型,都是通过插件机制来实现的。

灵活的配置能力#

举三个例子来介绍一下 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 的可观测性数据采集。换句话说,你可以只采集最关心的数据,而且这些配置都是动态生效的,可以随时调整。

活跃的社区#

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

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 社区、百度深度合作开发。

Apache APISIX SkyWalking Satellite

SkyWalking Satellite 按照上图步骤采集数据,SkyWalking Satellite 可以部署到更靠近产生数据的前端,以 sidecar 的形式存在。

图中从上往下业务请求经过 Apache APISIX 代理到 Upstream,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 本身稳定性有影响?

答:Apache APISIX 扩展机制得益于它的架构,可以在各个 phases(rewrite / access / header_filter / body_filter / preread_filter / log)增加业务逻辑。

至于稳定性方面, Apache 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。

金卫个人介绍