如何利用 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…