##一、什么是zabbix及優缺點
Zabbix能監視各種網絡參數,保證服務器系統的安全運營,並提供靈活的通知機制以讓系統管理員快速定位/解決存在的各種問題。是一個基於WEB界面的提供企業級的開源分布式系統監視以及網絡監視功能的企業級的開源解決方案。 Agent端:主機通過安裝agent方式采集數據 Server端:通過收集agent發送的數據,寫入數據庫(MySQL,ORACLE),在通過php+apache/nginx在web前端展示 cacti:在監控方面有良好的繪圖,cacti在流量和圖型塑造上要強於nagios,但是在故障分析上延遲性大,而且報警機制薄弱,不適合大規范監控場景。 nagios :適合監視大量服務器上面的大批服務是否正常, 重點並不在圖形化的監控, 其集成的很多功能例如報警,都是 cacti 沒有或者很弱的。但在繪圖以及圖型塑造方面精細度比cacti要弱,不適合大規模監控場景。 Zabbix=cacti+Nagios 優點:基於兩款工具(cacti+Nagios)優點於一身並更強大,集數據采集、數據存儲、數據展示及報警功能為一體實現企業級分布式監控 缺點:需在被監控主機上安裝agent,所有數據都存在數據庫里,產生的數據量很大,瓶頸主要在數據庫
##二、監控功能
主機的性能監控、網絡設備性能監控、數據庫性能監控、多種警告方式、詳細的報表圖表繪制
監控主機zabbix有專用的agent,可以監控Linux、Windows、FreeBSD等
監控網絡設備zabbix通過SNMP、ssh
可監控對象:
設備:服務器、路由器、交換機
軟件:OS、網絡、應用程序
主機性能指標監控
故障監控:down機、服務不可達、主機不可達
##三、zabbix支持的通訊方式
硬件監控:Zabbix IPMI Interface 系統監控:Zabbix Agent Interface java監控:ZabbixJMXInterface 網絡設備監控:Zabbix SNMP Interface 應用服務監控:Zabbix Agent UserParameter MySQL數據庫監控:percona-monitoring-pldlgins URL監控:Zabbix Web監控
##四、工作原理
一個監控系統運行的大概流程是這樣的: Zabbix agent需要安裝到被監控的主機上,它負責定期收集各項數據,並發送到zabbix server端,zabbix server將數據存儲到數據庫中,zabbix web根據數據在前端進行展現和繪圖。 這里agent收集數據分為主動和被動兩種模式: 主動:agent請求server獲取主動的監控項列表,並主動將監控項內需要檢測的數據提交給server/proxy 被動:server向agent請求獲取監控項的數據,agent返回數據
##五、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_gataway是可選的,這個需要另外安裝。 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_gataway的數據最終都是提交到server,並不是數據都是主動提交給zabbix_server,也有的是sever主動去取數據
Zabbix_proxy:zabbix代理守護進程,功能類似server,唯一不同的是它只是一個中轉站,它需要把收集到的數據提交/被提交到sever
Zabbix_java_gataway:zabbix2.0之后引入的一個功能,顧名思義:java網關,類似agentd,但是只用於java方面。需要特別注意的是,它只能主動取獲取數據,而不能被動獲取數據。它的數據最終會給到server或者proxy
##六、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接口
##七、zabbix的監控架構
在實際監控架構中,zabbix根據網絡環境、監控規模等分了三種架構:server-client、master-node-client、server-proxy-client三種。 server-client架構 也是zabbix最簡單的架構,監控機和被監控機直接不經過任何代理,直接由zabbix server和zabbix agentd之間進行數據交互。適用於網絡比較簡單,設備比較少的監控環境。
server-proxy-client架構 其中proxy是server、client之間溝通的一個橋梁,proxy本身沒有前端,而且其本身並不存放數據,只是將agentd發來的數據暫時存放,而后再提交給server。該架構經常是和master-node-client架構做比較的架構,一般適用於跨機房、跨網絡的中型網絡架構的監控
master-node-clinet架構 該架構是zabbix最復雜的監控架構,適用於跨網絡、跨機房、設備較多的大型環境。每個node同時也是一個server端,node下面可以接proxy,也可以直接接client。Node有自己的配置文件和數據庫,其要做的是將配置信息和監控數據向master同步
##八、zabbix 使用詳細介紹
zabbix基本應用流程: Host group -->Host ---> Application --->item ---> Trigger(狀態ok --> PROBLEM,trigger event) --->Action(Condition + Operation(Send Message,Remote)) Send Message: Media: Email 、SMS、Jabber、EZ Texting 、Script User Groups -->User(Media) 示例:node.mage.com --->Traffic --->Inbiund traffic,Outbound traffic --> trigger(inbound) Zabbix 常用術語 Item key: 監控項,監控項當中最關鍵的是Item key,用於定義每個item事件用key來進行標識 Escalation:報經升級 template:模板 web Scenario:web應用場景,對web進行監控,例如:打開web頁面需要的時間等 Zabbix服務器進程 Poller:主要功能是:主動去被監控的服務器中拉去數據的進程 Pinger:探測主機是否在線 db_config_syncer:服務器同步 timer:計時器 escaltor:報警升級器 housekeeper: discoverer:用來發現主機 httppoller:對web監控時用來獲取web監控數據 alter:用來發送警告 Item key: 命名要求:只能使用字母、數字、下划線、點號、連接符 接收參數:system.cpu.load[<cpu>,<moduel>],new.if.inbound[if,<model>] 注意:每個key背后都應該有一個命令或腳本來負責實現數據采集,此命令或腳本可調用傳遞給key的參數,調用方式$1,$2,..... 在zabbix中定義item時調用某key,還需要額外定義數據采集頻率,歷史數據保存時長等 Trigger: 觸發器表達式:{<Server>:<key>.<function>(<parameter>)}<operator><constant> 示例:{node2.mageedu.com:net.if.in[eth0,bytes].last(#1)} > 1200 <funciton>:評估采集到的數據是否在合理范圍內時所使用的函數,其評估過程可以根據采集到的數據、當時時間或其他因素 avg、count、change、date、dayofweek、delta、diff、iregexp、last、max、min、now、nodata、sum、prev、strlen regexp:檢查最后一次采樣的數據是否能夠被指定的模式所匹配:1表示匹配,0表示不匹配 now:返回自Unix元年至此刻經歷的秒數 prev:從最后一次的采樣中查找此處指定的子串 str:從最后一次的采樣中查找此處指定的字串 strlen: operator:操作符 > < = #不等於 / * - + & | 觸發器間存在依賴關系 應用場景:核心交換機出現故障,會導致警告,下面連接多個交換機也會隨之告警,通過依賴關系,如果核心交換機出現故障,下面的交換機很定連接不上,下面的交換就不需要告警了,可以減少警告次數,加快故障定位與排查效果 Action: message: codition(條件): event: trigger discovery: Server up,Server down,Host up,Host Down,Service Discovred,Service Lost,Host Discovred,Host Lost auto_registration: operation(操作): send message: Media Email , SMS,Jabber,Script,EZ Texting User remote commond (1)zabbix用戶不一定有權限執行所要執行的命令 給zabbix用戶定義sudo規則:賦權限 zabbix ALL=(ALL) ALL (2)不支持active模式的agent (3)不支持代理模式 (4)命令長度不得超過255哥字符 (5)可以使用宏 (6)zabbix-server僅執行命令,而不關心命令是否執行成功 Script: Alter Script 放置於特定目錄中:AlterScriptsPath = /usr/lib/zabbix/alterscripts zabbix_server.conf配置文件中的參數 腳本中可使用$1,$2,$3來調用aciton頁面中郵件的收件人,Default Subject,Default Message 注意:新房如此目錄中的腳本只有重啟zabbix-server方能被使用 可視化: graph,screen,slide,shows,map 宏:macros 是一種抽象,他根據一系列預定的規則替換一定的文本模式,而解釋器或編譯器在遇到宏時自動進行這一模式替換 兩類: 內建:{MACRO_NAME} 自定義:{$MACRO_NAME} 可以三個級別使用: GLOBAL全局,Template模板,Host主機級別 優先級:host ---> template ---> global 在某級別找到后將直接使用 模板:一系列配置的集合,辭謝配置可通過連接的方式應用於指定的主機 appplication,item,trigger,graph,screen,discovery,web 維護時間: configuration -->Maintenance user Parameters: zabbix內置了許多item key zabbix提供網絡發現功能:network discovery HTTP ICMP SSH LDAP TCP SNMP TELNET ZABBIX_AGENT掃描指定網絡中的主機 一旦主機被發現,如果對其進行操作,將由action來決定 LLD:low level discovery 低級網絡發現功能 此二者的功能: 自動添加主機,鏈接至模板,添加監控項、分組、定義觸發器 網絡發現有兩個步驟: discovery --> action 發現中的事件: Server up,Server down,Host up,Host Down,Service Discovred,Service Lost,Host Discovred,Host Lost actions: sending notifications Adding/removing hosts enabling/disabling hostadding hosts to a group removing hosts from a group auto_registration: 主動注冊功能 網絡發現功能自去掃描,極其占用資源 可以使用主動注冊功能 LLD:low level discovery 低級網絡發現功能 自動發現特定變量的名稱 添加針對變量的Items 返回魏JSON zabbix 的監控方式: zabbix-web 所能夠顯示的且可指定為監控接口類型的監控方式: Agent: passive active SNMP:simple Network Management Protocol MIB,smi snmp(V1,v2c,v3) IPMI:智慧平台管理接口 JMX:用於通過java自己的接口對java程序進行監控 zabbix-java-gateway 用於獲取監控接口數據 zabbix database需要用到的空間 默認保存90天 歷史數據 = 天數 X 每秒鍾處理的數據量 X 24 X 3600 X50 Bytes 趨勢數據: 默認一年 每一個趨勢默認128Bytes 大小 = 天數*監控項數量*24 * 128Bytes 事件數據: 保存一年 每個占據130Bytes 大小 = 天數 * 86400 * 130 zabbix: database ---> zabbix-server(zabbix_server.conf) ---> zabbix-web(LNMP) ---> http://zabbix-web-server/zabbix zabbix-agent 歷史數據: 采樣生成的數據 歷史趨勢數據: 每小時的最大值、最小值、平均值、統計 as is :不做任何處理
##參考博客
https://www.cnblogs.com/clsn/p/7885990.html#auto_id_24 https://www.cnblogs.com/cheyunhua/p/9961608.html