Cacti,Nagios,Zabbix,centreon,Ganglia 對比

一、cacti

Cacti 是一套基於 PHP,MySQL,SNMP 及 RRDTool 開發的網絡流量監測圖形分析工具。 簡單的說 Cacti 就是一個 PHP 程序。它經過使用 SNMP 協議獲取遠端網絡設備和相關信息，

（其實就是使用 Net-SNMP 軟件包的 snmpget 和 snmpwalk 命令獲取）並經過 RRDTOOL 工 具繪圖，經過 PHP 程序展示出來。咱們使用它能夠展示出監控對象一段時間內的狀態或者 性能趨勢圖。

二、nagios

Nagios 是一款開源的免費網絡監視工具，能有效監控 Windows、Linux 和 Unix 的主機狀 態，交換機路由器等網絡設置，打印機等。在系統或服務狀態異常時發出郵件或短信報警第 一時間通知網站運維人員，在狀態恢復後發出正常的郵件或短信通知。

三、zabbix

zabbix 是一個基於 WEB 界面的提供分佈式系統監視以及網絡監視功能的企業級的開源 解決方案。zabbix 能監視各類網絡參數，保證服務器系統的安全運營；並提供柔軟的通知機 制以讓系統管理員快速定位/解決存在的各類問題。

zabbix 由 2 部分構成，zabbix server 與可選組件 zabbix agent。zabbix server 能夠經過 SNMP， zabbix agent，ping，端口監視等方法提供對遠程服務器/網絡狀態的監視，數據收集等功能， 它能夠運行在 Linux, Solaris, HP-UX, AIX, Free BSD, Open BSD, OS X 等平臺上。

四、ganglia

Ganglia 是一款爲 HPC（高性能計算）集羣而設計的可擴展的分佈式監控系統，它能夠監視 和顯示集羣中的節點的各類狀態信息，它由運行在各個節點上的 gmond 守護進程來採集 CPU 、內存、硬盤利用率、I/O 負載、網絡流量狀況等方面的數據，而後彙總到 gmetad 守 護進程下，使用 rrdtool 存儲數據，最後將歷史數據以曲線方式經過 PHP 頁面呈現。 Ganglia 監控系統有三部分組成，分別是 gmond、gmetad、webfrontend。

 

五、centreon

Centreon 是一款功能強大的分佈式 IT 監控系統，它經過第三方組件能夠實現對網絡、 操做系統和應用程序的監控：首先，它是開源的，咱們能夠無償使用它；其次，它的底層採
用 nagios 做爲監控軟件，同時 nagios 經過 ndoutil 模塊將監控到的數據定時寫入數據庫中， 而 Centreon 實時從數據庫讀取該數據並經過 Web 界面展示監控數據；，最後，咱們能夠通

過 Centreon 管理和配置 nagios，或者說 Centreon 就是 nagios 的一個管理配置工具，經過

Centreon 提供的 Web 配置界面，能夠輕鬆完成 nagios 的各類繁瑣配置。

六、對比圖

 

2、
統一運維監控平臺設計思路

 

構建一個智能的運維監控平臺，必須以運行監控和故障報警這兩個方面爲重點，將全部業務系統中所涉及的網絡資源、硬件資源、軟件資源、數據庫資源等歸入統一的運維監控平 臺中，並經過消除管理軟件的差異，數據採集手段的差異，對各類不一樣的數據來源實現統一 管理、統一規範、統一處理、統一展示、統一用戶登陸、統一權限控制，最終實現運維規範化、自動化、智能化的大運維管理。

智能的運維監控平臺，設計架構從低到高能夠分爲 6 層，三大模塊，以下圖：

 

 

 
 

 

圖 1

q 數據收集層：位於最底層，主要收集網絡數據、業務系統數據、數據庫數據、操做 系統數據等，而後將收集到的數據進行規範化並進行存儲。

q 數據展現層：位於第二層，是一個 Web 展現界面，主要是將數據收集層獲取到的 數據進行統一展現，展現的方式能夠是曲線圖、柱狀圖、餅狀態等，經過將數據圖 形化，能夠幫助運維人員瞭解一段時間內主機或網絡的運行狀態和運行趨勢，並做 爲運維人員排查問題或解決問題的依據。

q 數據提取層：位於第三層，主要是對從數據收集層獲取到的數據進行規格化和過濾 處理，提取須要的數據到監控報警模塊，這個部分是監控和報警兩個模塊的銜接點。

q 報警規則配置層：位於第四層，主要是根據第三層獲取到的數據進行報警規則設置、 報警閥值設置、報警聯繫人設置和報警方式設置等。

q 報警事件生成層：位於第五層，主要是對報警事件進行實時記錄，將報警結果存入 數據庫以備調用，並將報警結果造成分析報表，以統計一段時間內的故障率和故障 發生趨勢。

q 用戶展現管理層：位於最頂層，是一個 Web 展現界面，主要是將監控統計結果、 報警故障結果進行統一展現，並實現多用戶、多權限管理，實現統一用戶和統一權 限控制。

在這 6 層中，從功能實現劃分，又分爲三個模塊，分別是數據收集模塊、數據提取

 

模塊和監控報警模塊，每一個模塊完成的功能以下：

q 數據收集模塊：此模塊主要完成基礎數據的收集與圖形展現。數據收集的方式有很 多種，能夠經過 SNMP 實現，也能夠經過代理模塊實現，還能夠經過自定義腳本 實現。經常使用的數據收集工具備 Cacti、Ganglia 等。

q 數據提取模塊：此模板主要完成數據的篩選過濾和採集，將須要的數據從數據收集 模塊提取到監控報警模塊中。能夠經過數據收集模塊提供的接口或自定義腳本實現 數據的提取。

q 監控報警模塊：此模塊主要完成監控腳本的設置、報警規則設置，報警閥值設置、 報警聯繫人設置等，並將報警結果進行集中展示和歷史記錄。常見的監控報警工具 有 Nagios、Centreon 等。

在瞭解了運維監控平臺的通常設計思路以後，接下來詳細介紹下如何經過軟件實現這樣 一個智能運維監控系統。

下圖 2 是根據圖 1 的設計思路造成的一個運維監控平臺實現拓撲圖，從圖中能夠看出， 主要有三大部分組成，分別是數據收集模塊、監控報警模塊和數據提取模塊，其中，數據提 取模塊用於其餘兩個模塊之間的數據通訊，而數據收集模塊能夠有一臺或多臺數據收集服務 器組成，每一個數據收集服務器能夠直接從服務器羣組收集各類數據指標，通過規範數據格式，

最終將數據存儲到數據收集服務器中。監控報警模塊經過數據抽取模塊從數據收集服務器獲 取須要的數據，而後設置報警閥值、報警聯繫人等，最終實現實時報警。報警方式支持手機 短信報警、郵件報警等，另外，也能夠經過插件或者自定義腳原本擴展報警方式。這樣一整 套監控報警平臺就基本實現了。

 

 

 

圖 2

3、企業運維監控平臺選型

一、中小企業監控平臺選擇 Zabbix 

Zabbix 是一款綜合了數據收集、數據展現、數據提取、監控報警配置、用戶展現等方面 的一款綜合運維監控平臺。

Zabbix 學習入門較快，功能也很強大，是一個能夠迅速用起來的監控軟件，可以知足中 小企業（服務器數 500 臺一下）的監控報警需求，所以是中小型企業運維監控的首選平臺。

可是，Zabbix 當監控服務器數量較多時，會產生不少問題，如監控數據不及時、報警超 時等等問題，這是由於 Zabbix 對服務器性能要求較高，當監控的服務器數量超過 500 臺後， 監控性能急劇降低，此時須要進行分佈式監控部署，而且須要提高監控服務器的性能。

安全性方面，Zabbix 客戶端的 agent 若是故障，收集到的數據將丟失，同時 Zabbix Server

也是單點，可能還須要對 Zabbix Server 作 HA 保證數據的安全和監控的高可用。

 

二、互聯網大企業監控平臺選擇 Ganglia+Centreon

 

開源監控軟件組合應用+二次開發
是大型互聯網企業構建監控平臺的一個基本策略，

 

對於有海量服務器、多業務系統的複雜監控，沒有哪一個軟件能獨立完成企業的全部監控需求， 所以，多種開源監控軟件組合應用+二次開發纔是監控平臺的最終方向。

推薦 ganglia 是由於 ganglia 客戶端軟件對服務資源佔用很是低，而且擴展插件很是多，

監控擴展也很是容易，同時結合專業的 web 監控平臺 centreon，能夠實如今數據收集、數 據展現、數據提取、監控報警配置、用戶展現等方面的完美配合，所以這裏對海量服務器進

行監控咱們推薦 ganglia+centreon 組合。

爲何選擇 ganglia+centreon 組合，咱們後面課程會陸續進行詳細深刻的介紹。

 

3. Zabbix 的運行架構

 
 

一、組件

1）、Zabbix Server：負責接收agent 發送的報告信息的核心組件，全部配置，統計數據及操

做數據均由其組織進行；

2）、Database Storage：專用於存儲全部配置信息，以及由zabbix 收集的數據；

3）、Web interface：zabbix 的GUI 接口，一般與Server 運行在同一臺主機上；

4）、Proxy：可選組件，經常使用於分佈監控環境中，代理Server 收集部分被監控端的監控數據

並統一發往Server 端；

5 )、Agent：部署在被監控主機上，負責收集本地數據併發往Server 端或Proxy 端；

注：zabbix node 也是 zabbix server 的一種 。

 

二、進程

 

默認狀況下zabbix包含 5 個程序：zabbix_agentd、zabbix_get、zabbix_proxy、zabbix_sender、 zabbix_server，另一個zabbix_java_gateway 是可選，這個須要另外安裝。下面來分別介紹 下他們各自的做用。

 

● zabbix_agentd

客戶端守護進程，此進程收集客戶端數據，例如 cpu 負載、內存、硬盤使用狀況等。

 

● zabbix_get

zabbix 工具，單獨使用的命令，一般在 server 或者 proxy 端執行獲取遠程客戶端信息的 命令。一般用戶排錯。例如在server 端獲取不到客戶端的內存數據，咱們可使用 zabbix_get 獲取客戶端的內容的方式來作故障排查。

 

● zabbix_sender

zabbix 工具，用於發送數據給 server 或者 proxy，一般用於耗時比較長的檢查。不少檢 查很是耗時間，致使 zabbix 超時。因而咱們在腳本執行完畢以後，使用 sender 主動提交數 據。

● zabbix_server

zabbix 服務端守護進程。zabbix_agentd、zabbix_get、zabbix_sender、zabbix_proxy、 zabbix_java_gateway 的數據最終都是提交到 server

備註：固然不是數據都是主動提交給 zabbix_server,也有的是 server 主動去取數據。

 

● zabbix_proxy

zabbix 代理守護進程。功能相似 server，惟一不一樣的是它只是一箇中轉站，它須要把收 集到的數據提交/被提交到 server 裏。

 

● zabbix_java_gateway

zabbix2.0 以後引入的一個功能。顧名思義：Java 網關，相似 agentd，可是隻用於 Java 方面。須要特別注意的是，它只能主動去獲取數據，而不能被動獲取數據。它的數據最終會 給到 server 或者 proxy。

 

三、zabbix 監控環境中相關術語

 

主機（host）：要監控的網絡設備，可由 IP 或 DNS 名稱指定；

l 主機組（host group）：主機的邏輯容器，能夠包含主機和模板，但同一個組織內的主機 和模板不能互相連接；主機組一般在給用戶或用戶組指派監控權限時使用；

l 監控項（item）：一個特定監控指標的相關的數據；這些數據來自於被監控對象；item 是 zabbix 進行數據收集的核心，相對某個監控對象，每一個 item 都由「key」標識；

l 觸發器（trigger）：一個表達式，用於評估某監控對象的特定 item 內接收到的數據是否 在合理範圍內，也就是閾值；接收的數據量大於閾值時，觸發器狀態將從「OK」轉變爲「Problem」，當數據再次恢復到合理範圍，又轉變爲「OK」；

l 事件（event）：觸發一個值得關注的事情，好比觸發器狀態轉變，新的 agent 或從新上 線的 agent 的自動註冊等；

l 動做（action）：指對於特定事件事先定義的處理方法，如發送通知，什麼時候執行操做；

l 報警媒介類型（media）：發送通知的手段或者通道，如 Email、Jabber 或者 SMS 等；

l 模板（template）：用於快速定義被監控主機的預設條目集合，一般包含了 item、trigger、 graph、screen、application以及 low-level discovery rule；模板能夠直接連接至某個主機；

● 前端（frontend）：Zabbix 的 web 接口；