zabbix簡介

背景

要確保服務的可靠性，離不開對服務的監控和報警，固然還有服務運行的所在機器上的一些狀態指標監控. 就是當某些指標不符合咱們的需求時，咱們可以在第一時間發現異常。這時候，咱們能夠本身寫腳本去實現，也能夠藉助一些第三方工具。這裏，咱們討論監控工具。它須要按期的對被監控主機進行檢查，信息收集等操做。當被監控主機出現異常時，可以及時報警，通知管理員，而且須要記錄這些一場，以便咱們分析這些數據，查缺補漏。那麼，一個監控工具就應該具有採集信息，存儲信息，展現信息，報警通知等功能，而zabbix就能夠作到這些。zabbix([`zæbiks])是一個基於WEB界面的提供分佈式系統監視以及網絡監視功能的企業級的開源解決方案。除了zabbix，你可能還據說過cacti, nagios, ganglia等相似的監控系統，可是這裏咱們只聊zabbix。

那麼咱們經過zabbix可以監控哪些硬件資源呢，理論上來講，只要是與咱們的業務有關的硬件資源，都應該被監控，好比 主機、交換機、路由器、UPS等等，可是，監控它們的前提是能與它們進行通信，那麼問題來了，因爲硬件的不一樣，致使咱們沒法使用統一的方法去監控它們，這個時候，就須要監控程序有必定的通用性，或者說，監控程序須要可以與多種硬件設備通信，才能知足咱們的監控需求，舉個例子：若是被監控的對象是一臺安裝了linux操做系統的服務器，那麼咱們能夠經過ssh或者telnet這種遠程工具與被監控對象創建起通信的通道，但是若是被監控的對象是一臺安裝了其餘操做系統的服務器呢，更甚之，被監控的對象並非服務器，而只是一臺交換機或者路由器呢，因此，zabbix若是想要可以全面的監控這些對象，則須要可以經過各類方法與它們進行通信。

 

zabbix支持的通信方式

• agent：經過專用的代理程序進行監控，與常見的master/agent模型相似，若是被監控對象支持對應的agent，推薦首選這種方式。
• ssh/telnet：經過遠程控制協議進行通信，好比ssh或者telnet。
• SNMP：經過SNMP協議與被監控對象進行通信，SNMP協議的全稱爲Simple Network Management Protocol ,被譯爲 "簡單網絡管理協議"，一般來講，咱們沒法在路由器、交換機這種硬件上安裝agent，可是這些硬件每每都支持SNMP協議，SNMP是一種比較久遠的、通行的協議，大部分網絡設備都支持這種協議，其實SNMP協議的工做方式也能夠理解爲master/agent的工做方式，只不過是在這些設備中內置了SNMP的agent而已，因此，大部分網絡設備都支持這種協議。
• IPMI：經過IPMI接口進行監控，咱們能夠經過標準的IPMI硬件接口，監控被監控對象的物理特徵，好比電壓，溫度，風扇狀態，電源狀態等。
• JMX：經過JMX進行監控，JMX（Java Management Extensions，即Java管理擴展），監控JVM虛擬機時，使用這種方法也是很是不錯的選擇。

 

zabbix的核心組件

好了，咱們剛纔提到了zabbix agent，通常狀況下，咱們將zabbix agent部署到被監控主機上，由agent採集數據，報告給負責監控的中心主機，中心主機也就是master/agent模型中的master，負責監控的中心主機被稱爲zabbix server，zabbix server將從agent端接收到的信息存儲於zabbix的數據庫中，咱們把zabbix的數據庫端稱爲zabbix database， 若是管理員須要查看各類監控信息，則須要zabbix的GUI，zabbix的GUI是一種Web GUI，咱們稱之爲zabbix web，它是用PHP編寫的，因此，若是想要使用zabbix web展現相關監控信息，須要依賴LAMP環境，不論是zabbix server，或是zabbix web，他們都須要鏈接到zabbix database獲取相關數據，這樣說可能不容易理解，對比下圖理解上述概念，就容易許多.

 

zabbix分佈式監控

當監控規模變得龐大時，咱們可能有成千上萬臺設備須要監控，這時咱們是否須要部署多套zabbix系統進行監控呢？若是部署多套zabbix監控系統，那麼監控壓力將會被分攤，可是，這些監控的對象將會被儘可能平均的分配到不一樣的監控系統中，這個時候，咱們就沒法經過統一的監控入口，去監控這些對象了，雖然分攤了監控壓力，可是也增長了監控工做的複雜度，那麼，咱們到底該不應創建多套zabbix監控系統從而分攤巨大的監控壓力呢？其實，zabbix天生就有處理這種問題的能力，由於zabbix支持分佈式監控，咱們能夠把成千上萬臺的被監控對象分紅不一樣的區域，每一個區域中設置一臺代理主機，區域內的每一個被監控對象的信息被agent採集，提交給代理主機，在這個區域內，代理主機的做用就比如zabbix server，咱們稱這些代理主機爲zabbix proxy，zabbix proxy再將收集到的信息統一提交給真正的zabbix server處理，這樣，zabbix proxy分攤了zabbix server的壓力，同時，咱們還可以經過統一的監控入口，監控全部的對象，當監控規模龐大到須要使用zabbix proxy時，zabbix的架構以下圖，咱們能夠對比下圖，理解上述描述。

此處，咱們再把剛纔說到的各類組件總結一遍：

• zabbix agent：部署在被監控主機上，負責被監控主機的數據，並將數據發送給zabbix server。
• zabbix server:負責接收agent發送的報告信息，而且負責組織配置信息、統計信息、操做數據等。
• zabbix database：用於存儲全部zabbix的配置信息、監控數據的數據庫。
• zabbix web：zabbix的web界面，管理員經過web界面管理zabbix配置以及查看zabbix相關監控信息，能夠單獨部署在獨立的服務器上。
• zabbix proxy：可選組件，用於分佈式監控環境中，zabbix proxy表明server端，完成局部區域內的信息收集，最終統一發往server端。

 

zabbix的工做模式

咱們知道，agent端會將採集完的數據主動發送給server端，這種模式咱們稱之爲主動模式，即對於agent端來講是主動的。

其實，agent端也能夠不主動發送數據，而是等待server過來拉取數據，這種模式咱們稱之爲被動模式。

聰明如你必定已經明白，不論是主動模式仍是被動模式，都是對於agent端來講的，並且，主動模式與被動模式能夠同時存在，並不衝突。

管理員能夠在agent端使用一個名爲zabbix_sender的工具，測試是否可以向server端發送數據。

管理員能夠在server端使用一個名爲zabbix_get的工具，測試是否可以從agent端拉取數據。

 

好了，咱們已經瞭解了zabbix的一些基本概念，其實zabbix還有不少經常使用術語，可是如今咱們並無遇到實際的使用場景，空口白話的描述顯得特別無力，並且難以理解，咱們就先無論它們了，等到用到它們的時候，咱們再作解釋。