1、cacti
Cacti 是一套基於 PHP,MySQL,SNMP 及 RRDTool 開發的網絡流量監測圖形分析工具。 簡單的說 Cacti 就是一個 PHP 程序。它通過使用 SNMP 協議獲取遠端網絡設備和相關信息，
（其實就是使用 Net-SNMP 軟件包的 snmpget 和 snmpwalk 命令獲取）並通過 RRDTOOL 工 具繪圖，通過 PHP 程序展現出來。我們使用它可以展現出監控對象一段時間內的狀態或者 性能趨勢圖。
2、nagios
Nagios 是一款開源的免費網絡監視工具，能有效監控 Windows、Linux 和 Unix 的主機狀 態，交換機路由器等網絡設置，打印機等。在系統或服務狀態異常時發出郵件或短信報警第 一時間通知網站運維人員，在狀態恢復后發出正常的郵件或短信通知。
3、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 等平台上。
4、ganglia
Ganglia 是一款為 HPC（高性能計算）集群而設計的可擴展的分布式監控系統，它可以監視 和顯示集群中的節點的各種狀態信息，它由運行在各個節點上的 gmond 守護進程來采集 CPU 、內存、硬盤利用率、I/O 負載、網絡流量情況等方面的數據，然后匯總到 gmetad 守 護進程下，使用 rrdtool 存儲數據，最后將歷史數據以曲線方式通過 PHP 頁面呈現。 Ganglia 監控系統有三部分組成，分別是 gmond、gmetad、webfrontend。
5、centreon
Centreon 是一款功能強大的分布式 IT 監控系統，它通過第三方組件可以實現對網絡、 操作系統和應用程序的監控：首先，它是開源的，我們可以免費使用它；其次，它的底層采
用 nagios 作為監控軟件，同時 nagios 通過 ndoutil 模塊將監控到的數據定時寫入數據庫中， 而 Centreon 實時從數據庫讀取該數據並通過 Web 界面展現監控數據；，最后，我們可以通
過 Centreon 管理和配置 nagios，或者說 Centreon 就是 nagios 的一個管理配置工具，通過
Centreon 提供的 Web 配置界面，可以輕松完成 nagios 的各種繁瑣配置。
6、對比圖
二、
統一運維監控平台設計思路
構建一個智能的運維監控平台，必須以運行監控和故障報警這兩個方面為重點，將所有業務系統中所涉及的網絡資源、硬件資源、軟件資源、數據庫資源等納入統一的運維監控平 台中，並通過消除管理軟件的差別，數據采集手段的差別，對各種不同的數據來源實現統一 管理、統一規范、統一處理、統一展現、統一用戶登錄、統一權限控制，最終實現運維規范化、自動化、智能化的大運維管理。
智能的運維監控平台，設計架構從低到高可以分為 6 層，三大模塊，如下圖：
圖 1
q 數據收集層：位於最底層，主要收集網絡數據、業務系統數據、數據庫數據、操作 系統數據等，然后將收集到的數據進行規范化並進行存儲。
q 數據展示層：位於第二層，是一個 Web 展示界面，主要是將數據收集層獲取到的 數據進行統一展示，展示的方式可以是曲線圖、柱狀圖、餅狀態等，通過將數據圖 形化，可以幫助運維人員了解一段時間內主機或網絡的運行狀態和運行趨勢，並作 為運維人員排查問題或解決問題的依據。
q 數據提取層：位於第三層，主要是對從數據收集層獲取到的數據進行規格化和過濾 處理，提取需要的數據到監控報警模塊，這個部分是監控和報警兩個模塊的銜接點。
q 報警規則配置層：位於第四層，主要是根據第三層獲取到的數據進行報警規則設置、 報警閥值設置、報警聯系人設置和報警方式設置等。
q 報警事件生成層：位於第五層，主要是對報警事件進行實時記錄，將報警結果存入 數據庫以備調用，並將報警結果形成分析報表，以統計一段時間內的故障率和故障 發生趨勢。
q 用戶展示管理層：位於最頂層，是一個 Web 展示界面，主要是將監控統計結果、 報警故障結果進行統一展示，並實現多用戶、多權限管理，實現統一用戶和統一權 限控制。
在這 6 層中，從功能實現划分，又分為三個模塊，分別是數據收集模塊、數據提取
模塊和監控報警模塊，每個模塊完成的功能如下：
q 數據收集模塊：此模塊主要完成基礎數據的收集與圖形展示。數據收集的方式有很 多種，可以通過 SNMP 實現，也可以通過代理模塊實現，還可以通過自定義腳本 實現。常用的數據收集工具有 Cacti、Ganglia 等。
q 數據提取模塊：此模板主要完成數據的篩選過濾和采集，將需要的數據從數據收集 模塊提取到監控報警模塊中。可以通過數據收集模塊提供的接口或自定義腳本實現 數據的提取。
q 監控報警模塊：此模塊主要完成監控腳本的設置、報警規則設置，報警閥值設置、 報警聯系人設置等，並將報警結果進行集中展現和歷史記錄。常見的監控報警工具 有 Nagios、Centreon 等。
在了解了運維監控平台的一般設計思路之后，接下來詳細介紹下如何通過軟件實現這樣 一個智能運維監控系統。
下圖 2 是根據圖 1 的設計思路形成的一個運維監控平台實現拓撲圖，從圖中可以看出， 主要有三大部分組成，分別是數據收集模塊、監控報警模塊和數據提取模塊，其中，數據提 取模塊用於其他兩個模塊之間的數據通信，而數據收集模塊可以有一台或多台數據收集服務 器組成，每個數據收集服務器可以直接從服務器群組收集各種數據指標，經過規范數據格式，
最終將數據存儲到數據收集服務器中。監控報警模塊通過數據抽取模塊從數據收集服務器獲 取需要的數據，然后設置報警閥值、報警聯系人等，最終實現實時報警。報警方式支持手機 短信報警、郵件報警等，另外，也可以通過插件或者自定義腳本來擴展報警方式。這樣一整 套監控報警平台就基本實現了。
圖 2
三、企業運維監控平台選型
1、中小企業監控平台選擇 Zabbix
Zabbix 是一款綜合了數據收集、數據展示、數據提取、監控報警配置、用戶展示等方面 的一款綜合運維監控平台。
Zabbix 學習入門較快，功能也很強大，是一個可以迅速用起來的監控軟件，能夠滿足中 小企業（服務器數 500 台一下）的監控報警需求，因此是中小型企業運維監控的首選平台。
但是，Zabbix 當監控服務器數量較多時，會產生很多問題，如監控數據不及時、報警超 時等等問題，這是因為 Zabbix 對服務器性能要求較高，當監控的服務器數量超過 500 台后， 監控性能急劇下降，此時需要進行分布式監控部署，並且需要提升監控服務器的性能。
安全性方面，Zabbix 客戶端的 agent 如果故障，收集到的數據將丟失，同時 Zabbix Server
也是單點，可能還需要對 Zabbix Server 做 HA 保證數據的安全和監控的高可用。
2、互聯網大企業監控平台選擇 Ganglia+Centreon
開源監控軟件組合應用+二次開發
是大型互聯網企業構建監控平台的一個基本策略，
對於有海量服務器、多業務系統的復雜監控，沒有哪個軟件能獨立完成企業的所有監控需求， 因此，多種開源監控軟件組合應用+二次開發才是監控平台的最終方向。
推薦 ganglia 是因為 ganglia 客戶端軟件對服務資源占用非常低，並且擴展插件非常多，
監控擴展也非常容易，同時結合專業的 web 監控平台 centreon，可以實現在數據收集、數 據展示、數據提取、監控報警配置、用戶展示等方面的完美配合，因此這里對海量服務器進
行監控我們推薦 ganglia+centreon 組合。
為什么選擇 ganglia+centreon 組合，我們后面課程會陸續進行詳細深入的介紹。
3. Zabbix 的運行架構
1、組件
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 的一種 。
2、進程
默認情況下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。
3、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 接口；