zabbix的組件及作用 理論

  1. Zabbix簡介
    Zabbix是一個企業級的開源分佈式監控解決方案,由C語言編寫而成的底層架構(server端和agent端),由一個國外的團隊持續維護更新,軟件可以自由下載使用,運作團隊靠提供收費的技術支持贏利。
    官方網站:http://×××w.zabbix.com
    Zabbix通過C/S模式採集數據,通過B/S模式在web端展示和配置。
    被監控端:主機通過安裝agent方式採集數據,網絡設備通過SNMP方式採集數據
    Server端:通過收集SNMP和agent發送的數據,寫入MySQL數據庫,再通過php+apache在web前端展示。

    1. Zabbix運行條件:
      Server:
      Zabbix Server需運行在LAMP(Linux+Apache+Mysql+PHP)環境下,對硬件要求低
      Agent:
      目前已有的agent基本支持市面常見的OS,包含Linux、HPUX、Solaris、Sun、windows等
      SNMP:
      支持各類常見的網絡設備
    2. Zabbix功能
      具備常見的商業監控軟件所具備的功能(主機的性能監控、網絡設備性能監控、數據庫性能監控、FTP等通用協議監控、多種告警方式、詳細的報表圖表繪製)
      支持自動發現網絡設備和服務器,支持分佈式,能集中展示、管理分佈式的監控點,擴展性強,server提供通用接口,可以自己開發完善各類監控。
    3. 優劣勢
      優點:
      開源,無軟件成本投入;
      Server對設備性能要求低(實際測試環境:虛擬機Redhat EL AS5,2GCPU 1G內存,監控5臺設備,CPU使用率基本保持在10%以下,內存剩餘400M以上);
      支持設備多;
      支持分佈式集中管理;
      開放式接口,擴展性強;
      當監控的item比較多服務器隊列比較大時可以採用被動狀態,被監控客戶端主動從server端去下載需要監控的item然後取數據上傳到server端。這種方式對服務器的負載比較小。
      缺點:
      無廠家支持,出現問題解決比較麻煩
      需在被監控主機上安裝agent,所有數據都存在數據庫裏,產生的數據據很大,瓶頸主要在數據庫。

    1.zabbix的監控原理:

組件說明:
1)zabbix server:負責接收agent發送的報告信息的核心組件,所有配置、統計數據及操作數據都由它組織進行;
2)database storage:專用於存儲所有配置信息,以及由zabbix收集的數據;
3)web interface:zabbix的GUI接口;通常與 Server 運⾏在同⼀臺主機上;
4)proxy:可選組件,常用於監控節點很多的分佈式環境中,代理server收集部分數據轉發到server,可以減輕server的壓力;
5)agent:部署在被監控的主機上,負責收集主機本地數據如cpu、內存、數據庫等數據發往server端或proxy端;
監控流程:
agentd需要安裝到被監控的主機上,它負責定期收集各項數據,併發送到zabbix server端,zabbix server將數據存儲到數據庫中,zabbix web根據數據在前端進行展現和繪圖。這裏agentd收集數據分爲主動和被動兩種模式:
主動:agent請求server獲取主動的監控項列表,並主動將監控項內需要檢測的數據提交給server/proxy
被動:server向agent請求獲取監控項的數據,agent返回數據。
客戶端守護進程:
此進程收集客戶端數據,例如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教程系列。
zabbix_java_gateway
zabbix2.0之後引入的一個功能。顧名思義:Java網關,類似agentd,但是隻用於Java方面。需要特別注意的是,它只能主動去獲取數據,而不能被動獲取數據。它的數據最終會給到server或者proxy。
擴展: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架構做比較的架構 ,一般適用於跨機房、跨網絡的中型網絡架構的監控。
3、master-node-client架構
該架構是zabbix最複雜的監控架構,適用於跨網絡、跨機房、設備較多的大型環境 。每個node同時也是一個server端,node下面可以接proxy,也可以直接接client 。node有自已的配置文件和數據庫,其要做的是將配置信息和監控數據向master同步,master的故障或損壞對node其下架構的完整性。

Grafana簡介:
Grafana是一個可視化面板(Dashboard),有着非常漂亮的圖表和佈局展示,功能齊全的度量儀表盤和圖形編輯器,支持Graphite、zabbix、InfluxDB、Prometheus和OpenTSDB作爲數據源。以InfluxDB(由go語言編寫,是一個開源,分佈式,時間序列,事件,可度量和無外部依賴的數據庫)作爲底層數據庫;
Grafana主要特性:靈活豐富的圖形化選項;可以混合多種風格;支持白天和夜間模式;多個數據源。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章