文章目錄
- zabbix是什麼
- zabbix的架構
- zabbix的優缺點
- zabbix的監控流程
- zabbix常見程序
- zabbix監控環境中基本概念
- 幾個開源運維監控架構對比
zabbix是什麼
zabbix（[`zæbiks]）是一個基于WEB界面的提供分布式系統監視以及網絡監視功能的企業級的開源解決方案。
zabbix至少由2部分構成，zabbix server與可選元件zabbix agent。
它具備主機的性能監控，網絡裝置性能監控，資料庫性能監控，多種告警方式，詳細報表、圖表的繪制等功能。監測對象可以是Linux或Windows伺服器，也可以是路由器、交換機等網絡裝置。
zabbix server可以通過SNMP，zabbix agent，ping，端口監視等方法提供對遠端伺服器/網絡狀态的監視，資料收集等功能，它可以運作在Linux，Solaris，HP-UX，AIX，Free BSD，Open BSD，OS X等平台上。
zabbix的架構
在生産環境中，zabbix根據網絡環境、監控規模等外界因素分為三種架構：server-client（直接連接配接）、master-node-client（Node架構）、server-proxy-client（proxy架構），如下圖所示：
1、server-client架構：
server-client架構是zabbix最簡單的架構，監控機和被監控機之間不經過任何代理，直接在zabbix server（監控伺服器） 和zabbix agent（agent：部署在被監控端，用于采集資料）之間進行資料互動，适用于網絡比較簡單，裝置較少的監控環境。
2、master-node-client架構：
master-node-client架構是zabbix最複雜的監控架構，适用于跨網絡、跨機房、裝置較多的大型環境。每個node同時也是一個server端，node下面可以接proxy，也可以直接接client。node有自己的配置檔案和資料庫，其要做的就是将配置資訊和監控資料向master同步。當master當機後，node可以保證架構的完整性。
3、server-proxy-client架構：
proxy是server、client之間溝通的一個橋梁，proxy本身沒有前端，而且其本身不存放資料，隻是将agentd發來的資料暫時存放，而後再送出給server。該架構經常是和master-node-client架構做比較的架構，一般适用于跨機房、跨網絡的中型網絡架構的監控。
zabbix的優缺點
zabbix的優點:
1、資料采集：可用性和性能檢測，自動發現，支援agent、snmp、JMX、telnet等多種采集方式，支援主動和被動模式資料傳輸、支援使用者自定義插件，自定義間隔收集資料
2、高可用：server對裝置性能要求低，支援proxy分布式監控，分布式集中管理，有自動發現功能，可以實作自動化監控；開放式接口，擴充性強，插件編寫容易
3、告警管理：支援多條件告警，支援多種告警方式，支援多組模闆，模闆繼承。
4、告警設定：告警周期，告警級别，告警恢複通知、告警暫停，時段門檻值、支援維護周期、支援單機停用
5、圖形化展示：允許自定義建立多監控項視圖，網絡拓撲，自定義面闆展示，自定義IT服務可用性
6、曆史資料：曆史資料查詢可配置，内置housekeeping資料清理機制
7、安全審計：具備安全的使用者審計日志，權限認證，使用者可以限制允許維護的清單。
8.自定義方面做的也比較好，想關注系統什麼名額就可以自定義鍵值取值。
zabbix缺點：
1、性能瓶頸，監控系統沒有低估高峰期，具有持續性和周期性，機器量越大，資料的增大會使資料庫的寫入成為一定的瓶頸，官網給出的單機上限5000台，屆時就需要增加proxy，增加成本。
2、Zabbix采集資料有pull方式，也就是server主動模式，當目标機器量大之後，pull任務會出現積壓。采集資料會延遲
3、項目二次開發，需要分析MySQL表結構，表結構比較複雜，通過API開發對開發能力有要求。
4、内置housekeeping在執行過程中會對資料庫增加壓力，需要對資料庫進行優化
zabbix的監控流程
Zabbix的監控流程可以簡單描述為：
資料采集-->資料存儲-->資料分析-->資料展示-->監控報警
其中：
資料采集：Zabbix通過SNMP、Agent、ICMP、SSH、IPMI等進行資料采集
資料存儲：Zabbix存儲在MySQL上，也可以存儲在其他資料庫
資料展示：web界面展示、(移動APP、java_php開發一個web界面也可以)
資料報警：郵件報警、微信報警、短信報警、報警更新機制
Zabbix的監控配置流程可以簡單描述為：
告警是由一系列的流程組成，首先是觸發器達到閥值，産生一個事件，接下來由Action對事件資訊進行處理，其中包括兩部分：
第一部分是發送消息，即将告警資訊發送給使用者。
第二部分是執行指令，即将事件用指令進行處理，達到對事件故障自動嘗試恢複的效果。
Host groups（主機組）-->Hosts（主機）-->template(模闆)
-->Applications（監控項組）-->Items（監控項）
-->graph(圖形) -->screen (圖形分組)-->Triggers（觸發器）
-->Event（事件）-->Actions（處理動作）-->
Media types(告警更新|1.執行遠端指令2.發送告警郵件)-->
User groups（使用者組）-->Users（使用者）-->Medias(告警郵件)
在實際生産使用的時候，Items、Trigger、Graph采用模闆來進行監控，模闆特點就是可以重複的事情一次完成，修改了模闆等于修改了所有調用此模闆的主機,這樣可解放運維的雙手.
Graph不是必需的，因為沒有配置圖形，資料擷取并不影響，擷取資料是Items的功能。但是對于使用ZabbixWeb界面使用者來說，沒有圖形等于沒有資料，是以重要的Items必須添加必要的圖形以做可視化展示。如果想集中檢視圖形，可以通過screen功能
zabbix常見程序
預設情況下zabbix包含5個程序：zabbix_agentd、zabbix_get、
zabbix_proxy、zabbix_sender、zabbix_server，
另外一個zabbix_java_gataway是可選的，這個需要另外安裝。
Zabbix_server：zabbix服務端守護程序。Zabbix_agentd、zabbix_get、
zabbix_sender、zabbix_proxy、zabbix_java_gataway的資料最終都是送出到server，并不是資料都是主動送出給zabbix_server，
也有的是sever主動去取資料
Zabbix_agentd：用戶端守護程序，此程序收集用戶端資料，
例如cpu負載、記憶體、磁盤使用情況等。
Zabbix_proxy：zabbix代理守護程序，功能類似server，唯一不同的是它隻是一個中轉站，它需要把收集到的資料送出/被送出到sever
Zabbix_get：zabbix工具，單獨使用的指令，通常在server
或者proxy端執行擷取遠端用戶端資訊的指令。通常用來排錯。
例如在server端擷取不到用戶端的記憶體資料，可以使用zabbix_get擷取
用戶端記憶體的方式來做故障排查。
Zabbix_sender：zabbix工具，用于發送資料給server或者proxy，
通常用于耗時比較長的檢查。很多檢查非常耗時，導緻zabbix逾時。
于是我們在腳本執行完畢之後，使用sender主動送出資料。
Zabbix_java_gataway：zabbix2.0之後引入的一個功能，
顧名思義：java網關，類似agentd，但是隻用于java方面。
需要特别注意的， 它隻能主動取擷取資料，而不能被動擷取資料。
它的資料最終會給到server或者proxy
Zabbix_database:MySQL或PostgreSQL
Zabbix_web:Web GUI
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接口
幾個開源運維監控架構對比