zabbix監控-基本原理介紹

 

1、Linux下開源監控系統簡單介紹
1）cacti：存儲數據能力強，報警性能差
2）nagios：報警性能差，存儲數據僅有簡單的一段能夠判斷是否在合理範圍內的數據長度，儲存在內存中。好比，連續採樣數據存儲，有連續三次不在合理範圍內的數據就報警
3）zabbix：結合上面兩種工具的優勢，又能夠存儲數據，又能夠報警。

2、什麼是Zabbix及其優缺點（對比Cacti和Nagios）

Zabbix是一個基於Web界面提供分佈式系統監視及網絡監視功能的企業級開源解決方案。它能監視各類網絡參數，保證服務器系統的安全運營，並提供靈活的通知機制以讓系統管理員快速定位/解決存在的各類問題；藉助Zabbix可很輕鬆地減輕運維人員們繁重的服務器管理任務，實現業務系統持續運行。
agent端：主機經過安裝agent方式採集數據。
server端：經過收集agent發送的數據，寫入數據庫（MySQL，ORACLE等），再經過php+apache在web前端展現.
zabbix = cacti + nagios

• 優勢：基於兩款工具優勢於一身並更強大，實現企業級分佈式監控。
• 缺點：2.2版本帶寬佔用大可是升級到2.4版本後更節省了帶寬資源，其它再無發現。

3、Zabbix特性

1）數據採樣：經過snmp、ssh、telnet、agent、ipmi、jmx等通道採集被監控主機的數據。能夠自定義檢測機制和自定義時間間隔
2）實時繪圖：展現，讀取數據繪圖，支持graph，map，screen，幻燈片（slide show）
3）告警：（升級告警，規定時間內內解決不了的事情往上傳）
4）數據存儲：數據庫有mysql，pgsql，時間序列數據庫等等

4、Zabbix監控功能

主機的性能監控、網絡設備性能監控、數據庫性能監控、多種告警方式、詳細的報表圖表繪製
監控主機zabbix有專用的agent，能夠監控Linux，Windows，FreeBSD等 。
監控網絡設備zabbix經過SNMP，ssh(很少用)
可監控對象

• 設備：服務器，路由器，交換機
• 軟件：OS，網絡，應用程序
• 主機性能指標監控
• 故障監控： down機，服務不可用，主機不可達

5、Zabbix工做原理

zabbix監控系統運行大概流程：
zabbix agent須要安裝到被監控的主機上，它負責按期收集各項數據，併發送到zabbix server端；
zabbix server將數據存儲到數據庫中，zabbix web根據數據在前端進行展示和繪圖。這裏agent收集數據分爲主動和被動兩種模式：

• 主動：agent請求server獲取主動的監控項列表，並主動將監控項內須要檢測的數據提交給server/proxy
• 被動：server向agent請求獲取監控項的數據，agent返回數據。

6、zabbix的組件及進程

zabbix由如下幾個組件部分構成：

• Zabbix Server：負責接收agent發送的報告信息的核心組件，全部配置，統計數據及操做數據均由其組織進行；
• Database Storage：專用於存儲全部配置信息，以及由zabbix收集的數據；
• Web interface：zabbix的GUI接口，一般與Server運行在同一臺主機上；
• Proxy：可選組件，經常使用於分佈監控環境中，代理Server收集部分被監控端的監控數據並統一發往Server端；
• Agent：部署在被監控主機上，負責收集本地數據併發往Server端或Proxy端；

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

1）zabbix_agentd：
客戶端守護進程，此進程收集客戶端數據，例如cpu負載、內存、硬盤使用狀況等。
2）zabbix_get
zabbix工具，單獨使用的命令，一般在server或者proxy端執行獲取遠程客戶端信息的命令。一般用戶排錯。例如在server端獲取不到客戶端的內存數據，咱們可使用zabbix_get獲取客戶端的內容的方式來作故障排查。
3）zabbix_sender
zabbix工具，用於發送數據給server或者proxy，一般用於耗時比較長的檢查。不少檢查很是耗時間，致使zabbix超時。因而咱們在腳本執行完畢以後，使用sender主動提交數據。
4）zabbix_server
zabbix服務端守護進程。zabbix_agentd、zabbix_get、zabbix_sender、zabbix_proxy、zabbix_java_gateway的數據最終都是提交到server
備註：固然不是數據都是主動提交給zabbix_server,也有的是server主動去取數據。
5）zabbix_proxy
zabbix代理守護進程。功能相似server，惟一不一樣的是它只是一箇中轉站，它須要把收集到的數據提交/被提交到server裏。爲何要用代理？代理是作什麼的？賣個關子，請繼續關注運維生存時間zabbix教程系列。
6）zabbix_java_gateway
zabbix2.0以後引入的一個功能。顧名思義：Java網關，相似agentd，可是隻用於Java方面。須要特別注意的是，它只能主動去獲取數據，而不能被動獲取數據。它的數據最終會給到server或者proxy。

7、zabbix監控環境中基本概念

主機（host）：要監控的網絡設備，可由IP或DNS名稱指定；
主機組（host group）：主機的邏輯容器，能夠包含主機和模板，但同一個組織內的主機和模板不能互相連接；主機組一般在給用戶或用戶組指派監控權限時使用；
監控項（item）：一個特定監控指標的相關的數據；這些數據來自於被監控對象；item是zabbix進行數據收集的核心，相對某個監控對象，每一個item都由"key"標識；
觸發器（trigger）：一個表達式，用於評估某監控對象的特定item內接收到的數據是否在合理範圍內，也就是閾值；接收的數據量大於閾值時，觸發器狀態將從"OK"轉變爲"Problem"，當數據再次恢復到合理範圍，又轉變爲"OK"；
事件（event）：觸發一個值得關注的事情，好比觸發器狀態轉變，新的agent或從新上線的agent的自動註冊等；
動做（action）：指對於特定事件事先定義的處理方法，如發送通知，什麼時候執行操做；
報警升級（escalation）：發送警報或者執行遠程命令的自定義方案，如每隔5分鐘發送一次警報，共發送5次等；
媒介（media）：發送通知的手段或者通道，如Email、Jabber或者SMS等；
通知（notification）：經過選定的媒介向用戶發送的有關某事件的信息；
遠程命令（remote command）：預約義的命令，可在被監控主機處於某特定條件下時自動執行；
模板（template）：用於快速定義被監控主機的預設條目集合，一般包含了item、trigger、graph、screen、application以及low-level discovery rule；模板能夠直接連接至某個主機；
應用（application）：一組item的集合；
web場景（web scennario）：用於檢測web站點可用性的一個活多個HTTP請求；
前端（frontend）：Zabbix的web接口；

8、zabbix的監控架構

在實際監控架構中，zabbix根據網絡環境、監控規模等 分了三種架構： server-client 、master-node-client、server-proxy-client三種 。
1）server-client架構
也是zabbix的最簡單的架構，監控機和被監控機之間不通過任何代理 ，直接由zabbix server和zabbix agentd之間進行數據交互。適用於網絡比較簡單，設備比較少的監控環境 。
2）server-proxy-client架構
其中proxy是server、client之間溝通的一個橋樑，proxy自己沒有前端，並且其自己並不存放數據，只是將agentd發來的數據暫時存放，然後再提交給server 。該架構常常是和master-node-client架構作比較的架構 ，通常適用於跨機房、跨網絡的中型網絡架構的監控。
三、master-node-client架構
該架構是zabbix最複雜的監控架構，適用於跨網絡、跨機房、設備較多的大型環境 。每一個node同時也是一個server端，node下面能夠接proxy，也能夠直接接client 。node有自已的配置文件和數據庫，其要作的是將配置信息和監控數據向master同步，master的故障或損壞對node其下架構的完整性。