譯者 | 劉汪洋
審校 | 重樓
本文將從監控系統開發者的視角，探討監控分布式數據庫的復雜性。主要涵蓋以下幾個方面：多節點管理、網絡限制、以及高吞吐量問題。我們將對這些方面進行權衡，并解決以下挑戰：
- 內置導出器與專用導出器的選擇。
- 像 Open Telemetry 這樣的行業標準在特定情況下的限制。
- 獲取指標的架構和數據的成本。
- 全局狀態同步的一致性問題。
- 在云環境中支持連接的復雜性。
我將以我開發的分布式數據庫 Apache Ignite 云監控解決方案為例，分享相關經驗，希望能為想要創建自己監控系統的開發者提供一些有價值的參考。
引言
監控分布式數據庫的挑戰在于，沒有一個普遍適用的最佳解決方案。每個系統都有其獨特的權衡點和限制，找到完美的實現非常困難。我們的討論將從一個抽象的指標收集系統的基本示例開始。正如這個示例所示，在多個點上，我們可能會基于特定需求進行不同的討論。
圖1. 抽象指標系統的基本實現
例如，在第一個點，我們可以選擇不同的指標注冊表實現，可以將它們存儲在內存中或持久化到磁盤中。指標注冊表是一個在導出之前存儲測量值的中間結構。理解這一點非常重要，因為我們可能會出于不同的原因對自定義監控系統采取不同的方法：
- 空間占用——即消耗的內存量。在內存有限的物聯網應用中，需要一種占用較少內存的解決方案。
- 內存壓力——對象分配的結果，可能會影響使用自動垃圾回收語言的應用程序。
由于大多數場景使用的是常規內存數據結構，不會特別關心這些問題。在第二個點，我們可以討論在遇到的背壓（backpressure）和連接丟失時的應對策略。在第三個點，我們可以評估最合適的協議和數據獲取方法。盡管我們不討論分布式系統中指標收集的任何具體權衡，但我們可以看到，這種簡單實現方法很具有爭議性。
系統需求
在設計系統時，第一步通常是估算預期的負載，包括輸入規模、擴展計劃、用戶數量和業務限制。
我們將從一個包含 N 個節點的分布式數據庫中提取指標。這些指標提供了關于對象及其相關進程的信息。
圖2. Apache Ignite 集群 N 個節點的指標導出
在我的場景中，我考慮了兩種不同類型的指標：
你可能已經注意到，動態創建的指標數量取決于特定環境。
我們嘗試估算其數量：
- 中型應用程序中的表、緩存和索引數量約為 250。
- 因此，每個節點有 100 + 30 * 250 = 7600 個指標。
- 平均集群大約有 10 個節點。
- 全局集群的指標總數為 7600 * 10 = 76,000。
- 考慮到 Gauge 指標 包含字段：Name、Description、Unit 和 Data。當指標數量為 76,000 時，負載大小約為 256 字節 * 76,000 ≈ 每次請求約 19MB。
如上所述，不加過濾地發送所有指標可能導致空間浪費和不必要的網絡流量。此外，通常這些指標通過節點聚合獲得，監控 7600 個不同的指標也不現實。
指標收集系統的一個優勢是其高效的擴展能力。這樣我們能夠為每個集群分配獨立的實例來存儲數據，確保數據獨立且有效分區。假設我們有一個微服務，可以為每個實例服務 50 個集群。盡管一個集群有數千個指標，但典型用戶使用的指標卻很少。
他們有 12 個儀表板 + 12 個警報，每個儀表板/警報大約有 4 個指標。因此，當指標收集間隔為 5 - 10 秒時：
- 50 個集群 _ (12 個儀表板 + 12 個警報) _ 4 個指標 _ (31 _ 24 _ 60 _ 60 / 5) 每月間隔 ≈ 每月存儲 2,571,264,000 個指標
- 2,571,264,000 * (64 + 32) 位指標大小（以 Ignite 持久化緩存中的位為單位）≈ 230 GB
為了解決占用過多存儲空間的問題，我們對指標進行壓縮，只存儲時間戳（作為 int64）和值（作為 int32）。壓縮算法對這種類型的數據壓縮效果非常好。如果使用時間序列數據庫，相同時間的時間戳將不會重復。
因此，如果沒有數據過期策略，我們每月需要提供 230 GB 的存儲空間。免費用戶通常有 7 天的數據保留期，付費用戶有更長的保留期以覆蓋我們的成本。
此外，另一個需要考慮的假設是讀/寫比率。這有助于我們為數據選擇合適的數據庫。然而，在我們的案例中，我們將數據存儲在 Apache Ignite 中。
逐步解決方案
數據獲取方法
問題： 你更喜歡哪種類型的收集模式？（選項：推送 / 拉取 / 兩者皆可 / 我沒有特別的意見。）
在處理數據傳輸的管道時，通常有兩種主要方法：要么將數據推送到管道中，要么將數據從管道中拉出。在我們的具體場景中，管道指的是網絡，我們考慮兩種數據獲取方法。
推送（CollectD、Zabbix 和 InfluxDB）
使用推送方法，每個應用實例會在設定的時間間隔內推送數據。這意味著數據會根據預定義的計劃或頻率，從應用程序主動推送到數據庫或存儲系統。
圖3. 推送獲取方法示意圖
優點：
- 不需要復雜的服務發現。
缺點：
- 需要在每個獨立的代理節點上進行配置。
雖然可以使用 Ansible 等自動化工具簡化配置過程，但每個節點的配置依然耗時且容易出錯。此外，更新配置也具有挑戰性，因為需要修改每個獨立節點。
拉取（Prometheus、SNMP 和 JMX）
拉取方法涉及外部監控系統根據需要請求指標。
圖4. 拉取獲取方法示意圖
優點：
- 可以在監控系統內集中管理配置。
- 自動處理背壓。
- 只請求所需的指標。
缺點：
- 需要服務發現。
- 監控系統必須能夠遠程訪問。
在我們的案例中，拉取方法相比推送方法更有優勢，但也存在顯著缺點。例如，網絡防火墻可能阻止所有從公共網絡到私有網絡的傳入連接。為了解決這個問題，我們采用了一種混合方法。
Ignite 2 采集模型
在 Ignite 2 中，我們最初采用了傳統的拉取方法進行指標收集，因為這是最直接的方法。然而，隨著我們增加更多集群，未經過濾的平均響應大小每 5 秒達到 19 MB，使得處理變得困難。
圖5. Ignite 2 采集方法示意圖
為了收集指標，我們的流程包括兩個異步步驟。首先，我們發送一個不帶參數的拉取請求，開始收集所有可用的指標。然后，收集器接收這些指標并重復該過程。在隨后的迭代中，我們應用過濾器以減少后續請求中的數據量。然而，第一次請求必須是空的，以收集完整的指標架構。
當架構過時時，代理會發送新版本。代理是一個嵌入式插件，負責處理數據庫連接并響應指標請求。
存在的問題：
- 大多數拉取請求具有相同的有效負載，這導致流量浪費。
- 數據和架構請求一起發送，使得數據模型復雜，難以單獨從架構中檢索數據。
這些問題可能導致指標收集過程中的性能和效率問題。
你可能會問為什么沒有更換協議，這是因為當前系統支持多個版本的代理。如果更改協議，收集器將不得不支持新舊版本，增加系統復雜性。
Ignite 3
在與 Ignite 3 的第二版集成中，我們對協議進行了一些更改，將消息分為不同類型：架構更新消息和指標輪詢消息。這種方式使得協議更加高效。
圖6. 原型 Ignite 3 采集方法示意圖
架構收集步驟（綠色圓圈）：
- 應用程序通過請求指標架構并訂閱更新來啟動過程 (1)。
- 收集器發送包含完整指標架構的響應 (2)。當架構有更新時，它會向應用程序發送更新 (2')。
指標收集步驟（紅色圓圈）：
- 在指標收集過程中，收集器在第一次請求中發送過濾器設置 (1)，指定未來請求中要收集的指標類型。
- 隨后，收集器發送指標請求 (2)，并接收包含所請求指標的響應 (3)。
這種方法顯著減少了流量消耗，這是我們當前選用的協議。
網絡結構
采集模型的選擇會影響監控系統的使用范圍。在設計監控系統時，考慮網絡層的限制是非常重要的。
公共網絡
在公共網絡場景中，系統的每個部分都對公眾開放，通常可以使用推送或拉取采集模型。由于所有組件都是公開可用的，監控系統可以輕松地使用拉取方法從應用實例請求數據，或使用推送方法接收實例推送的數據。
圖7. 公共網絡交互
然而，這種方法在企業環境中不可行，因為它存在安全隱患，例如開放端口可能成為攻擊目標。
私有網絡
在私有網絡中，數據庫集群通常位于其中。出于安全考慮，這種網絡不會直接對外部開放。因此，收集器不能直接從集群拉取指標，推送采集方法在這種情況下更適合。
圖8. 私有網絡交互
推送模型在這種情況下具有優勢，因為代理可以建立到收集器公共地址的外向連接。如果希望在私有網絡中使用拉取方法，需要在兩個網絡之間建立連接。這可以通過多種方式實現，例如虛擬專用網絡、AWS PrivateLink、代理服務器或其他類似解決方案。這些橋接方法允許收集器通過橋接連接從私有網絡拉取指標。然而，這種方法需要額外的橋接基礎設施設置和維護。
Ignite 2/3 網絡
為了支持私有網絡和公共網絡之間的連接，我們決定不使用虛擬專用網絡或其他復雜方法，因為它們可能會讓客戶感到困難并導致流失。相反，我們從代理到收集器打開一個 TCP 連接（使用 WebSocket，因為大多數銀行端口已禁用），收集器使用該連接來拉取指標。
圖9. Ignite 的網絡交互
代理/導出器
代理/導出器是指標收集系統的一部分，用于從指標源收集指標并將其提供給存儲。有幾種方法可以放置導出器：應用程序可以在類路徑中包含一個代理，這樣代理就會與應用程序一起啟動。代理可以位于應用程序外部，但在同一實例或同一網絡中。應用程序能夠支持使用 JMX 和 REST 等直接調用的開放協議，這種情況類似于內部的代理。
圖10. 導出器代理
應用程序內部的代理
在應用程序內部運行的代理類似于包含在應用程序運行時的庫，例如 Prometheus 代理。采用這種方法的一個優勢是可以輕松地為缺乏指標的系統添加指標導出，并通過依賴于易于修補的常見框架來提供應用程序指標。另一個好處是，在實現一個抽象的指標框架時，代理可以作為特定收集系統的導出器實現。
然而，這種方法也有缺點。主要缺點是外部代碼在與應用程序（在本例中是數據庫）相同的運行時執行，這可能導致以下副作用：
- 導出器內部使用緩沖區可能導致內存不足的錯誤進而引發崩潰。
- 代碼中的錯誤，尤其是使用不安全代碼時，可能會導致在不同字節順序環境中出現問題，從而引發崩潰。
- 額外的內存占用和垃圾回收暫停。
- 滾動升級問題，即必須停止數據庫實例以更新依賴項。
- 潛在的安全問題。
應用程序外部的代理
應用程序外部的代理是在與業務應用程序相同實例中安裝外部代理應用程序的方式。這種方法消除了對收集系統的直接依賴以及應用程序內部代理方法的缺點。
然而，這種方法帶來了額外的成本，因為需要管理兩個應用程序。盡管性能可能略有下降，但這并不是關鍵問題。除非有下面要討論的一個問題，否則這種方法應該成為首選。
Ignite 代理和我們的討論
我們為 Ignite 2 開發了一個插件，該插件與我們的云建立連接并發送指標。我們還在探索將相同方法用于 Ignite 3 集成的可能性。起初，我們考慮使用外部導出器，因為它對客戶集群更安全，但我們還必須考慮減少手動安裝步驟的業務價值。
我們曾考慮支持兩種類型的代理——內部和外部——并在性能和穩定性更好的情況下推薦遷移到外部版本。然而，這種方法將需要雙倍的工作量。
因此，我們決定堅持使用內部版本的代理。雖然這種方法有其優勢，特別是在分布式系統中，我們將在下面進一步探討。簡而言之，我們可以利用對負責共識的內部數據庫服務的訪問，并將其重用于我們的目的。
可擴展性（全局或本地指標）
在接下來，我們將探討在分布式環境中監控的挑戰。與監控單個應用程序相比，我們將深入了解推送/拉取采集方法在微服務架構或分布式數據庫中的應用。
每個節點上的推送
我認為，每個節點上的推送模型是解決分布式系統中許多問題的理想方法。這種方法涉及每個節點與收集器之間建立直接連接，對于處理腦裂場景非常有利。如果集群的一部分分離，它將自動停止發送指標。
圖11. 每個節點上的推送
優點：
- 自動擴展，無需服務發現。
- 減少重新發送數據的流量。
- 消除單點故障。
缺點：
- 套接字連接可能會成為問題，但可以通過使用虛擬地址和超過 65k 的連接來緩解。
- 合并數據時，時間同步可能會有挑戰。
每個節點上的拉取
在傳統架構中，在分布式系統的每個節點上使用拉取采集方法需要更復雜的交互模式。為了適應節點的啟動和與其他實例失去連接的情況，每個節點必須在服務發現組件中注冊自己。
圖12. 每個節點上的拉取
我們可以通過使用反向連接使這個解決方案更簡單，如圖例所示，但這需要管理多個連接，這使得它比推送方法更復雜。
圖13. 每個節點上的推送
此外，還需要考慮集群仍在運行但某些節點無法與收集器建立連接的情況。
單一協調器與跟隨者
接下來的方法與之前討論的推送/拉取方法類似，但有一些不同。在這種方法中，集群中有一個節點作為協調器代理，它與指標收集器建立連接，并從其他節點收集中間指標。
圖14. 代理協調器節點
這種方法在管理連接和基于時間戳同步數據方面更簡單，但與之前的方法一樣，也存在一些缺點。
- 首先，可能會導致流量消耗增加，因為指標被提交了兩次。
- 其次，如果協調器接收到大量數據批次，可能會導致內存不足。
- 最后，管理腦裂場景可能更加棘手。
我們的解決方案
正如之前提到的，我們選擇使用內部代理來解決問題，盡管這種方法存在一些缺點。這種方法使我們能夠將腦裂問題的處理委托給集群。考慮一個協調器節點分裂集群的場景。
圖15. 集群腦裂第一步
圖16. 集群腦裂第二步
為了在使用內部代理的解決方案中處理腦裂問題，我們決定將責任委托給集群。如果協調器節點與集群的其余部分分裂，則必須選擇一個新的協調器代理。選擇新的代理協調器并非易事，假設集群保證最早的節點會在正確的分裂部分中，我們的算法選擇最早的可用節點作為新的代理協調器。
協議
回到簡單的交互圖，還未討論一個方面——通信協議。
圖17. 交互圖
Open Telemetry
在我看來，使用廣泛接受的行業標準如 Open Telemetry 作為通信協議是最好的選擇。盡管它可能不是一個完美的解決方案，但它有幾個優點，例如：
- 無需為流行的收集系統實現適配器。
- 協議基于最佳實踐。
需要注意的是，這些常見的解決方案可能并不適用于每一個獨特的場景。
Rest / GraphQL / 類 SQL
另一種流行的協議是 Rest，它的優點在于使用和檢查都很簡單。例如，可以通過瀏覽器進行檢查。
自定義協議（自定義 - TCP / UDP, Protobuff）
自定義的協議可以更好地解決特定的邊緣情況，因為開發人員了解所使用的監控系統。然而，缺點是如果使用其他收集系統，則需要支持多個適配器，并且存在重復解決行業標準協議中已解決問題的風險。
我們的選擇
在我們的討論中，我們發現系統設計需求的主要問題是全量獲取的大消息大小以及需要保持架構值的更新。因此，我們最終決定實現自己的自定義協議。
圖18. Ignite 協議的原型
該協議在上一節中已詳細描述，這里就不再贅述了。
總結
總之，我試圖解決在開發過程中提出的基本問題。
譯者介紹
劉汪洋，51CTO社區編輯，昵稱：明明如月，一個擁有 5 年開發經驗的某大廠高級 Java 工程師，擁有多個主流技術博客平臺博客專家稱號。
原文標題：Why Monitoring a Distributed Database is More Complex Than You Might Expect，作者：Stepachev Maksim
