李云婷，張海明，黎建輝*

1. 中國科學院計算機網(wǎng)絡信息中心，北京 100190

2. 中國科學院大學，北京 100049

引言

近年來，數(shù)據(jù)量的持續(xù)高速增長以及大量的并發(fā)訪問，使得單一結構的數(shù)據(jù)庫在容量和性能上不再滿足需求，集群化成為趨勢[1]。此外，數(shù)據(jù)類型也日漸豐富，傳統(tǒng)關系型數(shù)據(jù)庫已難以適應諸如 JSON 樹狀數(shù)據(jù)、圖數(shù)據(jù)等新興數(shù)據(jù)類型，且關系特性一定程度上限制著集群的水平擴展。MongoDB 作為典型的基于文檔存儲 NoSQL (Not Only SQL)數(shù)據(jù)庫，則獲得了廣闊的應用空間。其數(shù)據(jù)結構簡單，數(shù)據(jù)模式靈活，支持大規(guī)模分布式集群部署方式，可擴展能力極強，能實現(xiàn)高性能的讀寫操作[2]。如今，諸多應用趨于使用 MongoDB 集群進行數(shù)據(jù)存儲與管理，為保證集群穩(wěn)定性和數(shù)據(jù)可靠性，則需對 MongoDB 集群進行實時性能分析和健康狀態(tài)報告。集群的各項性能指標與狀態(tài)數(shù)據(jù)，對于系統(tǒng)穩(wěn)定性分析、性能瓶頸優(yōu)化、快速故障恢復等具有重要意義。

現(xiàn)有的 MongoDB 監(jiān)控技術主要分為兩類：MongoDB 官方提供的監(jiān)控工具和服務[3]，國內(nèi)外開源項目。MongoDB 提供的工具如mongostat[4]和mongotop[5]，適用于單個實例 (instance)，監(jiān)控內(nèi)容有限，結果在命令行中每秒刷新展示，對于包含眾多實例的大規(guī)模分布式集群而言并不適用。MongoDB 提供的服務如 free monitoring[6]和 Ops Manager[7]，前者的性能分析過于簡單，僅展示不超過 24h 的性能變化曲線，且監(jiān)控數(shù)據(jù)不在本地存儲，無法詳盡分析；后者則更適用于集群，對企業(yè)版支持較好，社區(qū)版無論在本地進行配置還是使用都較為復雜，且自動發(fā)現(xiàn)實例時易遺漏 mongos 實例。國內(nèi)外開源項目中諸如 UMongo[8]、Mongo3[9]、Treesoft[10]等更側重于數(shù)據(jù)庫的管理和操作，對性能和狀態(tài)分析簡單，一般對集群的支持度較差，大多不再更新。另外，基于開源監(jiān)控平臺如 Zabbix 的 MongoDB 監(jiān)控解決方案[11]也多支持單點或副本集模式，對于復雜的大規(guī)模分布式集群，大多沒有涉及或者尚未解決對所有 mongos 實例進行監(jiān)控和對運行著多個實例的節(jié)點進行監(jiān)控等問題。

由此可看出，現(xiàn)有的監(jiān)控工具與項目雖對MongoDB 進行了一定程度的支持，但就大規(guī)模分布式 MongoDB 集群而言，仍存在不足之處。如何簡單、高效、完備地監(jiān)控 MongoDB 集群成為不容忽視的研究問題。本文認為，監(jiān)控 MongoDB 集群需滿足如下需求：第一，能夠?qū)崟r獲取集群的性能和狀態(tài)數(shù)據(jù)，且能同時監(jiān)控眾多節(jié)點及節(jié)點上的若干實例；第二，能夠保存長期的監(jiān)控歷史數(shù)據(jù)；第三，能夠提供較好的數(shù)據(jù)可視化展示。

本文基于上述問題和需求，結合 MongoDB 集群的結構特點，提出適用于 MongoDB 集群的分布式監(jiān)控方案，在實踐中能取得較好的監(jiān)控效果。

1 MongoDB 集群及監(jiān)控問題分析

1.1 MongoDB 分布式集群結構

Mongo DB 的分布式集群[12]，也稱分片集 (Sharded Cluster)，主要利用分片技術 (Sharding)使得數(shù)據(jù)分布式地存儲于多臺機器上，同時通過副本技術 (Replication)為每臺機器上的數(shù)據(jù)進行備份。一個典型的分片集架構如圖1 所示。它包含三個成分：Shard、mongos 和 Config servers。

Shard 即分片，負責存儲數(shù)據(jù)庫中的實際數(shù)據(jù)。分片在生產(chǎn)環(huán)境中一般部署為副本集，即一組mongod 實例，以避免單點故障。圖1 中的每個分片均部署為包含 3 個 mongod 實例的副本集，其中只有一個 mongod 承擔主節(jié)點 (primary)角色，其它 mongod 一般作為備份點 (secondary)或仲裁點 (arbiter)。mongos，為客戶端訪問集群提供接口，本身不存儲數(shù)據(jù)，可部署為多個?？蛻舳诉B接任一 mongos 均可對集群進行操作，整個集群對外如同單一數(shù)據(jù)庫。Config servers，存儲整個集群的元數(shù)據(jù)和配置信息，也部署為副本集。mongos 收到來自客戶端的數(shù)據(jù)操作請求后，會先從 Config servers 加載元數(shù)據(jù)，從而將請求正確定位到對應的分片，在相關分片上執(zhí)行操作后返回結果。

1.2 集群監(jiān)控問題分析

總體而言，MongoDB 的分布式集群中通常只包含 mongos 和 mongod 兩種實例。mongos 處理來自應用層的請求，不存儲數(shù)據(jù)；而 mongod 則處理數(shù)據(jù)請求，一般存儲數(shù)據(jù)。對分布式集群進行監(jiān)控，不僅是對集群中的所有節(jié)點進行監(jiān)控，更是對集群中所有的 mongos 和 mongod 實例進行監(jiān)控。因此監(jiān)控 MongoDB 分布式集群需考慮的問題如下：

第一，如何獲取完整的集群結構。MongoDB 分片集往往規(guī)模龐大、結構復雜，因而監(jiān)控的前提是要知曉集群的結構，如集群中的節(jié)點信息、各節(jié)點上運行的實例信息。目前無法通過 MongoDB 官方提供的相關命令獲取完整的集群結構。主要原因在于集群中各個 mongos 實例相互獨立，即無法通過登錄到一個mongos 而獲取到另一個 mongos 的基本信息和狀態(tài)。此外，集群結構還需設計簡單明了的數(shù)據(jù)格式來進行表達。

第二，如何選取監(jiān)控的基本單元。MongoDB 分布式集群結構復雜的主要原因在于集群的節(jié)點和實例并不局限為一對一關系，在實際部署環(huán)境中往往表現(xiàn)為一對多關系。即在一個節(jié)點上同時運行多個實例，以充分利用節(jié)點資源，例如某個節(jié)點上可部署一個 mongos 和多個 mongod 實例，它們占用不同的端口，在集群中承擔不同的角色，每個 mongod 實例在不同位置分別存放數(shù)據(jù)。一般而言，集群的監(jiān)控通常以節(jié)點作為基本單元，便于數(shù)據(jù)分析和呈現(xiàn)，但 MongoDB 集群需要對每個實例進行單獨的監(jiān)控分析。

第三，如何處理集群結構的變動。MongoDB 集群的可擴展性極強，集群結構容易發(fā)生變動。當集群增加分片時，集群結構隨之改變，新的節(jié)點和實例需要能夠及時加入監(jiān)控。即在不改變原有節(jié)點監(jiān)控的前提下，花費較小的開銷將新增節(jié)點和實例納入監(jiān)控范圍。

圖1 MongoDB 分布式集群架構Fig.1 MongoDB sharded cluster architecture

2 分布式監(jiān)控方案設計

針對上述監(jiān)控基本需求和問題，結合大規(guī)模分布式 MongoDB 集群的結構特點，提出分布式監(jiān)控方案。其中分布式監(jiān)控架構以集群實例作為基本監(jiān)控單元，定時采集數(shù)據(jù)，進行處理、存儲和分析，同時進行性能實時展示，能用于包含大量節(jié)點與實例的MongoDB 集群。另外，設計 MongoDB 集群結構描述方法，將集群成分、節(jié)點、實例等詳細信息通過簡潔清晰的JSON格式進行表達。

2.1 分布式監(jiān)控方案架構

MongoDB 集群節(jié)點和實例數(shù)量眾多、結構易變動，尤其是一個節(jié)點上往往運行多個實例，承擔多重功能。因此，傳統(tǒng)的單一數(shù)據(jù)采集和接收模式在效果和效率上均難以滿足監(jiān)控需求，以節(jié)點為監(jiān)控單位的數(shù)據(jù)采集方式更是無法滿足監(jiān)控架構的擴展需求，故設計分布式監(jiān)控架構如圖2 所示，以適應大規(guī)模易擴展的 MongoDB 集群。

在實際生產(chǎn)環(huán)境中，MongoDB 集群的節(jié)點往往同時運行和維護著多個 mongos 和 mongod 實例，這些實例在功能上多互有關聯(lián)，但在性能和運行狀態(tài)上則相對獨立。因而在分布式監(jiān)控架構中，采用實例作為基本監(jiān)控單元，對每個實例單獨進行性能分析。首先，使用多個采集器分散采集實時運行數(shù)據(jù)，每個采集器負責一定數(shù)量實例的數(shù)據(jù)采集。數(shù)據(jù)采集過程則突破了集群節(jié)點的局限，將整個集群視作實例的集合，不同節(jié)點、不同類型的實例可通過同一采集器進行數(shù)據(jù)采集。采集器定時從連接的實例上采集實時數(shù)據(jù)，從數(shù)據(jù)中篩選出監(jiān)控所需的指標數(shù)據(jù)。數(shù)據(jù)發(fā)送器將指標數(shù)據(jù)發(fā)送至相應的代理接收處。代理接收處主要用于數(shù)據(jù)中轉(zhuǎn)，匯聚一定范圍的數(shù)據(jù)后再進行發(fā)送，能夠有效地減緩數(shù)據(jù)接收的負擔，在監(jiān)控大規(guī)模 MongoDB 集群時效果顯著。最后接收數(shù)據(jù)，對數(shù)據(jù)進行一定處理和分類，將監(jiān)控數(shù)據(jù)統(tǒng)一存儲至數(shù)據(jù)庫。讀取數(shù)據(jù)庫中的數(shù)據(jù)，一方面可進行實時性能的可視化展示，在集群發(fā)生異常狀態(tài)時告警，另一方面，可通過歷史數(shù)據(jù)進行系統(tǒng)瓶頸分析和集群穩(wěn)定性分析。

另外，為適應 MongoDB 集群的可擴展性，上述監(jiān)控架構也具有一定的可擴展性。當集群中增加了新節(jié)點和實例，由于監(jiān)控架構將實例而非節(jié)點作為監(jiān)控單元，因此只需簡單地將新增實例加入到已有采集器的數(shù)據(jù)采集范圍，即可高效地將擴展的新節(jié)點納入監(jiān)控范圍。當擴展的節(jié)點數(shù)過多時，可適當再增加新的采集器，還可相應地增加代理接收以減輕數(shù)據(jù)接收壓力。

圖2 分布式監(jiān)控架構Fig.2 Distributed monitoring architecture

2.2 集群結構描述方法

在分布式監(jiān)控架構中，監(jiān)控數(shù)據(jù)以實例為單位進行分散采集，接收時可按照節(jié)點進行分類整理并存儲，便于數(shù)據(jù)可視化展示。即展示每個節(jié)點上所有實例的實時性能和狀態(tài)，同時表現(xiàn)出每個實例在集群中充當?shù)某煞趾徒巧畔?。因此，對?MongoDB 集群，構建其分布式監(jiān)控系統(tǒng)的關鍵依據(jù)是集群的結構信息。

但由于節(jié)點和實例的一對多關系，以及實例間的相對獨立性，集群的結構信息往往難以完整獲取。上文提及的 Ops Manager 和一些基于 Zabbix 的監(jiān)控解決方案，在監(jiān)控 MongoDB 分布式集群時都存在會遺漏 mongos 實例的問題，而原因也正是因為無法獲取集群的完整結構信息。因此，本文認為，完整的集群結構信息不應通過外部連接命令獲取，而是應由集群的管理員直接提供并維護。同時，結構信息作為監(jiān)控系統(tǒng)的輸入，還需進行簡明規(guī)范的表達和描述。

通常情況下，結構信息應包含節(jié)點信息、實例信息、成分信息三部分。本文提出集群結構描述方法，將三種信息用通用規(guī)范的 JSON 格式進行統(tǒng)一表達。按照集群成分來劃分并組織集群結構，對每個實例進行詳細描述，在實例信息中融入節(jié)點信息。對于 mongos 實例，需給出所在節(jié)點的 IP 地址和占用端口；對于 mongod 實例，除 IP 和端口信息外，還需給出實例的角色信息，即是否為仲裁點。若為仲裁點 (arbiter)，則該實例不存儲數(shù)據(jù)，監(jiān)控時只需判斷實例是否正常運行；若不是仲裁點 (not arbiter)，則監(jiān)控時需獲取詳細的性能指標數(shù)據(jù)。

表1 集群結構信息示例Table1 Example of a cluster structure

例如某 MongoDB 集群共包含 5 個節(jié)點、15 個實例。其中 mongos 實例共 3 個，Config servers 包含的mongod 實例共 3 個，3 個分片中每個分片包含 mongod 實例各 3 個，其各節(jié)點的詳細信息如表1 所示。

集群結構可通過 MongoDB 的三種成分 mongos、config、shard 進行劃分，分別描述各成分中所有實例的詳細信息，表1 中的集群結構可表達為如下的 JSON 格式：

3 監(jiān)控系統(tǒng)實現(xiàn)

上述監(jiān)控方案主要依據(jù) MongoDB 的集群結構來構建分布式監(jiān)控系統(tǒng)，分散地采集各實例的實時數(shù)據(jù)，經(jīng)代理中轉(zhuǎn)后，統(tǒng)一接收存儲，并提供可視化展示和數(shù)據(jù)分析支持。對比當前主流的開源監(jiān)控平臺后，本文選用 Zabbix 對上述分布式監(jiān)控系統(tǒng)進行實現(xiàn)。

3.1 開源監(jiān)控平臺 Zabbix 介紹

Zabbix[13]是一個企業(yè)級的開源通用監(jiān)控平臺，能對包括操作系統(tǒng)、數(shù)據(jù)庫系統(tǒng)、硬件、網(wǎng)絡等在內(nèi)的多種系統(tǒng)資源和設備進行監(jiān)控；提供靈活的告警與事件處理機制；同時通過 Web 界面提供可視化展示和配置管理；支持分布式的監(jiān)控部署方式。目前，眾多企業(yè)、高校的數(shù)據(jù)中心均使用Zabbix作為監(jiān)控解決方案[14-17]。

Zabbix 架構簡潔，通常包含 5 個主要的組件：Server、Database、Web、Proxy、Agent。其中，Server 是 Zabbix 的核心組件，用于捕獲、接收和處理監(jiān)控數(shù)據(jù)，將監(jiān)控數(shù)據(jù)存儲至 Database，并通過 Web頁面進行展示。Database 用于存儲 Zabbix 的所有數(shù)據(jù)信息，包括監(jiān)控數(shù)據(jù)和配置信息。Web 提供 Zabbix 的訪問接口，一方面提供監(jiān)控數(shù)據(jù)的可視化展示，另一方面提供監(jiān)控主機、監(jiān)控項、用戶權限等配置和管理。Database 和 Web 均可視作 Server 的一部分。Proxy 為可選組件，用于實現(xiàn)分布式監(jiān)控，減輕 Server 端的負擔。Agent 一般部署于被監(jiān)控的主機上，通過 zabbix_agentd 進程采集并發(fā)送數(shù)據(jù)。除 zabbix_agentd 外，也可使用 zabbix_sender 進程來發(fā)送數(shù)據(jù)，但它無法直接采集數(shù)據(jù)。

3.2 監(jiān)控系統(tǒng)的 Zabbix 實現(xiàn)

Zabbix 作為當前主流的開源監(jiān)控方案，具有較強的通用性和易用性，因此本文選用 Zabbix 4.0 實現(xiàn)對 MongoDB 集群的分布式監(jiān)控系統(tǒng)。其實現(xiàn)架構如圖3 所示，主要使用了 Zabbix 的 sender 進程、Proxy 和 Server 組件。

與圖2 的分布式監(jiān)控架構相對應，數(shù)據(jù)采集模塊通過定時執(zhí)行 Python 腳本實現(xiàn)，而數(shù)據(jù)發(fā)送模塊則通過 zabbix_sender 進程實現(xiàn)。使用 Python 腳本配合 zabbix_sender 來進行采集和發(fā)送，而非使用傳統(tǒng)的 zabbix_agentd 進程，原因在于：其一，agentd 一般需部署運行于監(jiān)控的節(jié)點上，而 sender 可部署在集群外的其它節(jié)點上，能連接集群即可。雖然 agentd 對于所在節(jié)點的影響甚微，但出于數(shù)據(jù)安全和操作權限等考慮，將集群節(jié)點與監(jiān)控點隔離則更佳；其二，agentd 只能監(jiān)控其所在節(jié)點的實例，當 MongoDB 集群進行擴展，則需在新節(jié)點上重新部署 agentd，而 sender 則可跨節(jié)點監(jiān)控實例，更為靈活便捷；其三，sender 更適于批量數(shù)據(jù)的收集和發(fā)送。監(jiān)控架構中的代理接收模塊則通過圖3 中的 zabbix_proxy 實現(xiàn)，proxy 可匯聚來自 sender 的數(shù)據(jù)，再將數(shù)據(jù)定期發(fā)送至 Zabbix Server。Zabbix Server 包含 Database 和 Web，因此能夠?qū)崿F(xiàn)分布式監(jiān)控架構中的接收處理、統(tǒng)一存儲、實時展示模塊。 而圖2 架構中的數(shù)據(jù)分析模塊則需通過其它更為專業(yè)的統(tǒng)計分析模型或工具來完成。

圖3 Zabbix 監(jiān)控實現(xiàn)架構Fig.3 Implementation of Zabbix monitoring architecture

總體而言，Zabbix 實現(xiàn) MongoDB 集群監(jiān)控的流程可劃分為兩個階段：配置主機和持續(xù)監(jiān)控。兩個階段都需要讀取并解析 MongoDB 集群的 JSON 結構信息。

配置主機階段，即在 Zabbix Server 端依據(jù) MongoDB 集群結構進行相應的主機配置，其具體流程如下：

配置主機階段主要在 Web 前端完成可視化相關配置，以集群節(jié)點為單位進行組織，構建一個主機組，為每個節(jié)點創(chuàng)建主機，并根據(jù)節(jié)點上運行的具體實例為該主機鏈接相應的模板。模板是 Zabbix 中監(jiān)控項、觸發(fā)器、自定義圖形等的集合。本文將模板與實例進行對應，充當相同集群成分和角色的實例可使用同一模板。Zabbix 4.0 尚未提供適用于 MongoDB 的官方模板，考慮到大規(guī)模集群監(jiān)控的復雜性，本文對 MongoDB 相關指標進行設計和篩選，提出了適用于 MongoDB 集群的基礎模板 Template MongoDB Not Arbiter 和 Template MongoDB Arbiter。前者適用于 mongos 實例以及非仲裁點的 mongod 實例，包含 11 個監(jiān)控項，能對 MongoDB 主要性能指標和狀態(tài)進行實時監(jiān)控；后者則適用于充當仲裁點的 mongod 實例，包含 1 個監(jiān)控項，僅監(jiān)控運行狀態(tài)，不對性能指標作監(jiān)控。兩種模板的監(jiān)控項、觸發(fā)器、自定義圖形等具體內(nèi)容分別如表2 和表3 所示。

表2 Template MongoDB Not Arbiter 模板內(nèi)容Table2 Template MongoDB Not Arbiter

表3 Template MongoDB Arbiter 模板內(nèi)容Table3 Template MongoDB Arbiter

結合集群的結構信息，可通過關鍵詞替換等方法將基礎模板簡單地轉(zhuǎn)化生成集群的定制模板，再根據(jù)每個節(jié)點上實際運行的實例情況為其鏈接相應的模板。以表1 集群中的 IP102 節(jié)點為例，其上運行 3 個實例，分別為 mongos 實例，shard1 的 mongod 實例和 config 的 mongod 實例，且兩個 mongod 實例均為非仲裁點。因此，IP102 對應的主機需要鏈接 3 個模板，分別是 Template MongoDB Not Arbiter mongos，Template MongoDB Not Arbiter shard1，Template MongoDB Not Arbiter config。

持續(xù)監(jiān)控階段需定時采集數(shù)據(jù)、處理數(shù)據(jù)并展示。主要依據(jù) JSON 結構信息中的 IP 地址和端口連接每一個實例，通過執(zhí)行 serverStatus 命令，從返回文檔中篩選出與模板監(jiān)控項對應的指標數(shù)據(jù)。監(jiān)控數(shù)據(jù)由 sender 發(fā)送，經(jīng)過 proxy，最后到達 Server 端，進行簡單預處理后，將數(shù)據(jù)分派到對應的主機并統(tǒng)一存儲，Web 頁面實時以圖形化方式顯示各主機的性能數(shù)據(jù)并刷新。每個 sender 負責一定數(shù)量的實例的數(shù)據(jù)采集。若集群進行擴展，首先需在集群結構的 JSON 描述中添加新增的實例和節(jié)點信息，而后更新 Server 端的主機配置，最后再將新增實例納入數(shù)據(jù)采集范圍。若加入新實例后，監(jiān)控系統(tǒng)中各組件負荷過大，還可根據(jù)實際情況相應地增加 sender 與 proxy 數(shù)量。

3.3 實現(xiàn)效果

與其它同樣使用 Zabbix 的 MongoDB 監(jiān)控解決方案相比，本文的分布式監(jiān)控方案針對集群設計，尤其是大規(guī)模復雜集群，而非單點模式。方案將整個集群當作實例的集合進行監(jiān)控，在性能展示時又以節(jié)點為單位進行組織，重點解決復雜集群多節(jié)點、多實例、節(jié)點與實例呈一對多關系的監(jiān)控難題。以表1 中集群的 IP101 節(jié)點為例，通過 Zabbix 的 Web 頁面，既能查看該節(jié)點上 shard1 mongod 實例的監(jiān)控項如 Mongo current connections (數(shù)據(jù)庫當前連接數(shù))的實時變化曲線，也能查看其 config mongod 實例的網(wǎng)絡帶寬和數(shù)據(jù)庫基本操作數(shù)的實時變化，如圖4 所示。

與 MongoDB 官方提供的 mongostat、mongotop 命令和 free monitoring 服務相比，本文的分布式監(jiān)控方案能同時監(jiān)控一個復雜集群的所有實例，而非單個實例，且監(jiān)控指標豐富多樣，能全面對實例進行狀態(tài)評估，還能對任一實例的任一數(shù)值型監(jiān)控項提供如圖4 的可視化展示。

與 MongoDB 官方提供的 Ops Manager 相比，本文的分布式監(jiān)控方案配置較為簡單，能提供并表達出完整的集群結構，在監(jiān)控時不會遺漏任何一個 mongos 實例。同時，在監(jiān)控指標上進行了篩選，重點關注實例運行狀態(tài)、網(wǎng)絡帶寬和數(shù)據(jù)庫操作信息，專注于集群性能監(jiān)控。若集群進行擴展，該方案能夠通過結構信息簡單方便快速地更新監(jiān)控范圍。另外，由于方案中對監(jiān)控歷史數(shù)據(jù)進行了集中存儲，因此能支持接入專業(yè)的模型和工具以進行深入的性能數(shù)據(jù)分析。

圖4 監(jiān)控效果圖Fig.4 Example of monitoring results

在實踐過程中，對上述分布式監(jiān)控系統(tǒng)中監(jiān)控數(shù)據(jù)發(fā)送所需的網(wǎng)絡流量以及監(jiān)控數(shù)據(jù)存儲所需的空間容量進行簡單測試。對于 mongos 實例或非仲裁點的 mongod 實例，使用表2 模板，每次需采集并打包發(fā)送11項監(jiān)控指標，平均每次發(fā)送使用網(wǎng)絡流量為 1104 B；對于充當仲裁點的 mongod 實例，使用表3 模板，每次只需采集并打包發(fā)送1項監(jiān)控指標，平均每次發(fā)送使用網(wǎng)絡流量為 310 B。對表1 中的集群進行測試，集群包含 5 個節(jié)點，15 個實例，其中 13 個實例為 mongos 或非仲裁點的 mongod 實例，2 個實例為仲裁點實例，共有 145 個監(jiān)控項，將數(shù)據(jù)采集發(fā)送頻率設置為 30 s 一次，則監(jiān)控 1 天后，監(jiān)控數(shù)據(jù)發(fā)送使用的網(wǎng)絡總流量為 37.8 MB，Zabbix 的 Database 中增加的存儲量為 59.7 MB。對包含 20 個節(jié)點、39 個實例的集群進行測試，共有 349 個監(jiān)控項，將數(shù)據(jù)采集發(fā)送頻率設置為 30 s 一次，則監(jiān)控 1 天后，監(jiān)控數(shù)據(jù)發(fā)送使用的網(wǎng)絡總流量為 92.3 MB，Database 中增加的存儲量為 143.8 MB。由于監(jiān)控中將集群實例作為數(shù)據(jù)采集的基本單位，因此系統(tǒng)中監(jiān)控數(shù)據(jù)的網(wǎng)絡流量和存儲總量均應與集群實例數(shù)量呈正比關系。由此可推斷，當集群中實例數(shù)達到 100 時，頻率 30 s、監(jiān)控 1 天，數(shù)據(jù)發(fā)送使用的網(wǎng)絡流量應為約 200 MB，數(shù)據(jù)存儲量將增加約 350 MB。并且，由于 Zabbix 的 Database 中存儲的歷史和趨勢數(shù)據(jù)可配置存儲保留時長，超過時長的數(shù)據(jù)將被清理，因此 Database 的數(shù)據(jù)容量不會持續(xù)大量增長。

上述分布式監(jiān)控系統(tǒng)理論上能通過增加 sender 和 proxy 的數(shù)量、配置多級 proxy 等方式適應超大規(guī)模的 MongoDB 集群。由于 sender 需將數(shù)據(jù)打包發(fā)送，每個 sender 負責的實例數(shù)量建議設置為 15-20 個，這樣能保證每個 sender 的發(fā)送負荷不會過大且 sender 的數(shù)量可控。每個proxy建議連接 3-10 個 sender。當集群達到超大規(guī)模，可考慮設置二級 proxy 以進一步減輕 Server 處的接收負擔。

實踐證明，本文提出的分布式監(jiān)控方案能適用于大規(guī)模分布式 MongoDB 集群，能通過較小的網(wǎng)絡流量和存儲空間獲得完備的長期和實時監(jiān)控數(shù)據(jù)。Zabbix 的 Server 和 proxy 部署和使用對基本內(nèi)存和硬盤要求較低、sender 對部署節(jié)點的影響較小，監(jiān)控數(shù)據(jù)采集所使用的 serverStatus 命令對 MongoDB 集群本身影響甚微，不影響集群的整體性能。因此當集群節(jié)點數(shù)較多時，仍能維持高效的監(jiān)控方式。此外，Zabbix 還可與可視化工具 Grafana 相結合[18]以提供更專業(yè)的數(shù)據(jù)可視化展示。

4 結語

MongoDB 集群作為典型的 NoSQL 數(shù)據(jù)庫系統(tǒng)，在數(shù)據(jù)量級持續(xù)增加的背景下，獲得了廣泛的應用和發(fā)展。針對 MongoDB 集群規(guī)模龐大、節(jié)點和實例數(shù)量多、結構易變動等特點，本文提出分布式監(jiān)控方案，設計集群結構的描述方法，將集群實例作為基本監(jiān)控單元，分散采集數(shù)據(jù)，再進行統(tǒng)一存儲和分析。通過使用開源平臺 Zabbix，實現(xiàn)了對大規(guī)模分布式 MongoDB 集群的性能狀態(tài)監(jiān)控，得到較好的可視化效果。在下一步工作中，將把集群節(jié)點的系統(tǒng)資源使用情況納入監(jiān)控范圍，同時加強對監(jiān)控數(shù)據(jù)的統(tǒng)計和分析，進一步完善監(jiān)控方案。