企業級監控zabbix基礎

一個標準的監控系統所具有的基本功能：

1.數據的採集

2.爲了展現其長期走勢，將數據存儲下來

3.萬一某次採樣的結果不在被認爲是合理的範圍內，而後就會作出告警操做，儘早的讓相關人員得知到此消息

4.展現

 

監控的對象除了主機以外，還包括主機之間的流量

對主機而言所需監控指標：

系統指標：CPU，memery,IO(Disk,Network)

1.CPU:sys(消耗在系統空間的比例)，usr（用戶空間的比例），idle（空閒的比例）,,,等

2.memery：total（總大小），userd（已用空間大小），free（空閒大小），cached（放在緩存的大小），buffer，shm（共享內存的大小），，，等

3.IO

以上只是系統指標

系統一旦起來，會運行不少進程，對進程而言，他有多少個，他的變化量，處於運行狀態的，處於睡眠狀態的，處於僵死狀態的等，，，這些又是指標

業務指標：好比：對於nginx服務，假如說nginx也算是一個進程，他時而處於運行狀態，時而處於睡眠狀態，對於nginx自己來講，他每秒接受的請求數量，每秒處理的請求數量等，這些能夠理解爲業務指標。

 

數據採集

1.ssh接口（監控中最爲簡單的方式）

咱們要監控的某個特定主機的某一項指標，若是這項指標是核心而敏感的數據，普通用戶是不具備權限的，要想獲取到核心的數據，就要以管理員的身份來運行，能夠用ssh帳號遠程鏈接認證來鏈接到監控的主機上，從而獲取到核心的數據，來實現管理。

2.agent

在監控的目標主機上運行一個進程，這個進程能夠與其控制端經過非系統的認證邏輯來進行認證，即使用戶得到了認證的信息，也不能得到系統級權限。經過了認證後，控制端就會只會agent端作出一些操做，若是agent端以管理員身份來運行，就能在目標主機上得到設計者設計的權限。

3.英特爾智慧平臺接口

一些專業的服務器也能夠不依賴於操做系統提供的系統級接口來監控，就算沒裝操做系統，也能夠獲取該主機的CPU，memery,IO用量，這種方式依賴硬件級的接口，英特爾智慧平臺接口

4.jmx接口

在jvm虛擬機上有一個jmx接口，經過這個接口來獲取數據指標，來完成監控

 

對採集的數據進行存儲

對於mysql

tps:每秒的事務數

qps:每秒的查詢數

歷史數據：每一次採樣都保存下來的數據

趨勢數據：按照固定的時間長度作聚合運算後僅保留有限數據項的數據

假如說,每5分鐘收集一次數據，那麼一小時就要採集12次，這12次採集的數據就是歷史數據，將這12次採集的數據通過聚合運算得出聚合的結果，可能只有三四個數據項，最大，最小，平均值，這就是趨勢數據。

因此爲了展現數據的長期走勢，多保留一些趨勢數據，歷史數據僅保留最近幾個月的，可是這麼一來，就會給數據庫帶來的更大的壓力，由於既要存儲趨勢數據，又要存儲歷史數據，爲了解決這個問題，早期使用關係型數據庫做爲存儲系統，後來也有了一些其餘的方案，例如：rrd(cacti),round-robin-database輪詢數據庫

數據存儲就像圍繞一個圓進行存儲，當存滿了以後，再有新的數據來存儲，就會覆蓋原來最先存儲的數據。

告警

獲取用戶能夠及時獲得信息的接口，而後向用戶傳遞信息

若是一個監控系統監控到異常狀態的信息，向用戶發短信，就須要有一個前提，監控系統可以發短信，可是監控系統並不作這個工做，他只調用發短信這個服務，就須要寫一個程序，來調短信服務的api接口，這個程序寫好以後可以被監控系統所觸發便可。

展現

展現界面越絢麗，簡單美觀，讓看的人少動腦，就越受歡迎。

 

常見的監控系統

Nagios:"難夠死"，是一個很是好的告警系統，可是沒有提供存儲系統

Cacti：Cron+SNMP+Mysql,很好的展現系統，可是問題出現比較多

zabbix:整合了上面提到的四種功能的監控系統

1.支持多種接口完成數據採集：agent,SNMP,IPMI(英特爾智慧平臺接口)，jmx

2.數據存儲：mysql,pgsql

3告警：email，script腳本（短信，微信）

（1）能夠告警升級，剛開始出故障時，發短信給運維工程師，隔兩小時後沒有解決問題，就發給他的領導，再隔兩小時沒解決，發給領導的領導，，，

（2）能夠發遠程命令，剛開始出故障時，尤爲是服務級故障，先不要當即發告警，在第一個週期內，試圖嘗試去解決問題，遠程指揮目標主機重啓一下服務，若是問題解決，就不用發警報了，若是沒有解決，那就開始發警報

4.展現：簡單圖，圖形，screen,slide,show,map,,,

 

第三方的展現接口：grafana

結合grafana展現接口造成監控系統

1.statsd+influxdb（時序數據庫）+grafana

2.promethues(自身就至關於時序數據庫，可收集數據，存儲下來，並展現，但展現界面很差看，因此可結合grafana)+grafana

3.graphitce+grafana

 

zabbix程序架構

 

Zabbix組件概述

Zabbix Server：負責接收agent發送的報告信息的核心組 件，全部配置、統計數據及操做數據均由其組織進行；

Database Storage：專用於存儲全部配置信息，以及由zabbix收集的數據,以及存儲在Zabbix所配置的配置信息，好比：哪一個指標須要監控，多長時間監控一次等；

Web interface：zabbix的GUI接口，一般與Server運行在 同一臺主機上；

Proxy：可選組件，經常使用於分佈監控環境中，代理Server收 集部分被監控端的監控數據並統一發往Server端；

Agent：部署在被監控主機上，負責收集本地數據併發往 Server端或Porxy端；

 

Zabbix監控Java應用

 

監控系統運行狀態

Zabbix Server監控的主機上指標不僅一個，以一個指標爲例，假如每隔120秒採樣一次，採集一次存一次，並且每當一個時間段知足時會作一次聚合運算，得出聚合運算結果，最大值，最小值，平均值等，每次採集存儲下來以前會先評估一下數據是否知足觸發器，既是否在合理區間範圍內，若是在就OK，不然PROMBLE，一旦狀態發生轉換，假如上次是OK，如今轉換成了PROMBLE，就會觸發一個時間EVENT,就會採起行動，行動分多個層級，首先執行遠程命令，若是不行，就發報警等。

採集----》斷定閾值範圍-----》若是沒問題就存下來，若是有問題則有事件產生，就會產生某個行爲，告警操做

 

Zabbix經常使用的術語

主機(host)：要監控的網絡設備，可由IP或DNS名稱指定；

主機組(host group)：主機的邏輯容器，能夠包含主機和模 板，但同一個組內的主機和模板不能互相連接；主機組一般 在給用戶或用戶組指派監控權限時使用；

監控項(item)：一個特定監控指標的相關的數據，這些數據 來自於被監控對象；item是zabbix進行數據收集的核心，沒 有item，將沒有數據；相對某監控對象來講，每一個item都由"key"進行標識；

觸發器(trigger)：一個表達式，用於評估某監控對象的某特 定item內所接收到的數據是否在合理範圍內，即閾值；接收 到的數據量大於閾值時，觸發器狀態將從"OK"轉變爲 "Problem"，當數據量再次迴歸到合理範圍時，其狀態將從 "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 Processes

 

安裝zabbix

將yum倉庫路徑指向zabbix的官網

 

複製連接地址，而後在linux系統上，將其下載下來，注意你的dns和網關都正常，不然就會下載不上

而後再將其安裝

再來看一下安裝了這個包，安裝的文件，能夠看到自動在/etc/yum.repo下面給你配好了zabbix倉庫

此時，再yum clean all，yum repolist就會列出安裝zabbix的yum倉庫

 

在安裝以前先確保本地的mysql配置正常

配置mysql

vim /etc/my.cnf.d/server.cnf

[server]

skip_name_resolve = on 跳過域名解析

innodb_file_per_table = on

innodb_buffer_pool_size = 256M 緩衝池大小爲256M

max_connections = 2000

配置好以後，從新啓動數據庫服務

systemctl restart mariadb

 

而後安裝zabbix

yum install zabbix-server-mysql zabbix-web zabbix-web-mysql zabbix-agent zabbix-get zabbix-sender -y

到此zabbix就成功安裝了

 

考慮到zabbix來鏈接數據庫，儘量用普通用戶的身份來鏈接，因此須要進入數據庫中建立用戶

mysql

create database zbxdb character set 'utf8';

grant all on zbxdb.* to 'zbxuser'@'192.168.10.%' identified by 'zabbix';

flush privileges;

 

安裝zabbix-server-mysql時提供了一些腳本，其中/usr/share/doc/zabbix-server-mysql-3.4.4/create.sql.gz就是在zabbix數據庫生成表的腳本

將其複製到家目錄下，並解壓縮

cp /usr/share/doc/zabbix-server-mysql-3.4.4/create.sql.gz /root

 

這些表裏面存的是歷史數據，趨勢數據，配置等

 

配置zabbix配置文件

cp /etc/zabbix/zabbix_server.conf /etc/zabbix/zabbix_server.conf.bak 修改配置文件先作好備份，養成良好習慣

vim zabbix_server.conf

ListenPort=10051 監聽端口

LogFile=/var/log/zabbix/zabbix_server.log 日誌文件

LogFileSize=0 日誌自動滾動

PidFile=/var/run/zabbix/zabbix_server.pid pid進程文件

SocketDir=/var/run/zabbix

DBHost=192.168.10.160 zabbix鏈接數據庫所在的主機

DBName=zbxdb 數據庫名字

DBUser=zbxuser 數據庫用戶

DBPassword=zabbix 密碼

DBPort=3306

 

配置完後，啓動zabbix服務，而後查看zabbix服務狀態

systemctl start zabbix-server

systemctl status zabbix-server

 

接下來就是經過zabbix GUI接口來訪問zabbix的web頁面，須要修改配置文件

vim /etc/httpd/conf.d/zabbix.conf

在/etc/php.ini中配置時區（在/etc/php.ini中配置時區對全部的php程序都有效，在/etc/httpd/conf.d/zabbix.conf中配置時區只對zabbix應用有效）

而後開啓httpd服務，在瀏覽器上去訪問zabbix的web頁面

systemctl start httpd

在瀏覽器上去訪問zabbix的web頁面，訪問成功，第一次訪問的時候，須要作一些初始化設置，以下圖

 

 

 

 

 

 

而後就能登進來了，如圖：就是zabbix默認的儀表盤

 

 

monitoring

咱們配置好監控指標後，須要到Monitoring中去查看

dashboard面板

problem能夠看到哪些有問題的地方，還能夠過濾

overview概覽

latest data採集到的數據

trigger觸發器

 

configuration

要配置監控目標主機的指標須要在configuration中配置

 

 

Report

Report可以幫咱們生成監控結果報告

 

administration

administration是用來管理zabbix系統自身的

 

 

 

配置監控的主機

注意關掉防火牆和selinux

1.安裝agent(在監控的目標主機上配置)

安裝方法和安裝zabbix同樣

yum install zabbix-agent zabbix-sender -y

 

2.修改agent配置文件

vim /etc/zabbix/zabbix_agentd.conf

PidFile=/var/run/zabbix/zabbix_agentd.pid

LogFile=/var/log/zabbix/zabbix_agentd.log

LogFileSize=0

Server=192.168.10.160 監控服務器是哪臺主機

ListenIP=0.0.0.0

StartAgents=3

ServerActive=192.168.10.160 主動監控的服務器是哪臺主機

Hostname=node1 被監控主機名

啓動agent服務

systemctl start agent

查看agent服務狀態

 

接着在zabbix web界面手動將該主機歸入監控的主機上

 

添加以後，而後點主機，建立主機

而後編輯

編輯以後點擊add添加便可

而後點擊主機中去查看

而後點擊application應用集來定義監控項的類別，點擊建立應用集

 

 

再次建立，依舊點擊建立應用集便可

而後再來添加item監控項

點擊create item 建立監控項

而後編輯監控項，採集CPU中斷次數數據

key其實就是一些命令，而內建key其實就是通過屢次優化的命令，採集數據速度快，效率高，若是內建key不足以知足咱們的須要的話，還能夠用戶自定義key

採集數據的類型：

數值：

整數

浮點數

字符串：

字符串

文本

對採集到的數據進行存儲：

1.(as is)不對數據進行處理，直接存儲下來

2.(delta)本次採樣減去前一次採樣的值的結果

3.(delta)本次採樣減去前一次採樣的值，在除以通過的時長

採集完數據要作一些簡單的計算

點擊添加

查看採集的數據

查看圖形

再來編輯一個item，網卡指標數據，要考慮的是要獲取哪一個網卡的值，要獲取哪一個網卡上的指標

點添加，添加完成

接着查看採集的數據，在monitoring中的latest data查看

查看圖形

 

trigger觸發器

界定某特定的item採集到的數據的非合理區間或非合理狀態：邏輯表達式

邏輯表達式，閾值；一般定義數據的不合理區間；

    OK：正常狀態--> 較老的zabbix版本爲false；

    problem:非正常狀態 --> 較老的zabbix版本爲true；

ok ---> problem

Recovery:problem ---> OK

觸發器存在可調用的函數：

nodata()

last()

time()

now()

dayomonth()

...

建立觸發器(trigger)

1.監控項"僅負責收集數據，而一般收集數據的目的還包括在 某指標對應的數據超出合理範圍時給相關人員發送告警信 息，"觸發器"正是用於爲監控項所收集的數據定義閾值

2.每個觸發器僅能關聯至一個監控項，但能夠爲一個監控項 同時使用多個觸發器

事實上，爲一個監控項定義多個具備不一樣閾值的觸發器，能夠 實現不一樣級別的報警功能

3.一個觸發器由一個表達式構成，它定義了監控項所採起的數 據的一個閾值

4.一旦某次採集的數據超出了此觸發器定義的閾值，觸發器狀 態將會轉換爲"Problem"；而當採起的數據再次迴歸至合理範 圍內時，其狀態將從新返回到"OK"

觸發器表達式

觸發器表達式高度靈活，能夠以之建立出很是複雜的測試條件

基本的觸發器表達式格式以下所示

{<server>:<key>.<function>(<parameter>)}<operator><constant>

server：主機名稱；

key：主機上關係的相應監控項的key；

function：評估採集到的數據是否在合理範圍內時所使用的函數，其 評估過程能夠根據採起的數據、當前時間及其它因素進行；

目前，觸發器所支持的函數有avg、count、change、date、dayofweek、delta、diff、iregexp、last、max、min、nodata、now、sum等

parameter：函數參數；大多數數值函數能夠接受秒數爲其參數，而 若是在數值參數以前使用"#"作爲前綴，則表示爲最近幾回的取值，如：

sum(300)表示300秒內全部取值之和，而sum(#10)則表示最近10次取值之和；

此外，avg、count、last、min和max還支持使用第二個參數，用於完 成時間限定；例如，max(1h,7d)將返回一週以前的最大值；

operator：表達式所支持的運算符及其功能以下表所示

觸發器表達式的例子

一個例子

{www.magedu.com:system.cpu.load[all,avg1].last(0)}>3

表示主機www.magedu.com上全部CPU的過去1分鐘內的平均負 載的最後一次取值大於3時將觸發狀態變換

對last函數來講，last(0)至關於last(#1)

觸發器間的依賴關係

在一個網絡中，主機的可用性之間可能存在依賴關係

例如，當某網關主機不可用時，其背後的全部主機都將沒法正常訪問

若是全部主機都配置了觸發器並定義了相關的通知功能，相關人員將會接收到許多告警信息，這既不利於快速定位問題，也 會浪費資源

正肯定義的觸發器依賴關係能夠避免相似狀況的發生，它將使 用通知機制僅發送最根本問題相關的告警

注意：目前zabbix不可以直接定義主機間的依賴關係，其依 賴關係僅能經過觸發器來定義

 

1.被監控主機觸發器的依賴關係

監控主機zabbix server 經過交換機的網絡鏈接線來監控兩臺主機，假如交換機出現故障了，那麼zabbix server也就採集不了被監控主機的數據了，不只交換機的觸發器會報警，被監控主機的觸發器也會報警，此時定位故障就很差定位了，咱們不知道究竟是交換機出現了故障，仍是被監控主機出現了問題，因此此時要定義觸發器間的依賴關係，若是交換機出現了故障，交換機的觸發器報警了，全部依賴此交換機觸發器的主機就不用報警了。

 

2.被監控主機上服務觸發器的依賴關係

如圖：觸發器之間的依賴關係：被監控主機上的服務是否正常依賴於主機和主機網卡，而主機和主機網卡是否正常，依賴於交換機，因此監控到交換機故障，被監控主機就不用報警了，監控到被監控主機網卡故障，被監控主機上的服務就不用報警了（被監控網卡故障會致使zabbix server不能採集到被監控主機服務指標的數據）。

註釋：定義觸發器之間的依賴關係須要根據網絡拓撲圖來定義的

在web界面建立觸發器(trigger)

點擊create trigger，定義表達式

 

點擊添加

再回到host中查看，如圖：變綠了

再次回到monitoring

老師的圖：在100pkts/sec那裏有一根黃線

 

 

在web界面定義觸發器的依賴關係

 

action執行動做

1.在配置好監控項和觸發器以後，一旦正常工做中的某觸發器狀態發生改變，通常意味着有異常狀況發生，此時一般須要採起必定的動做(action)，如告警或者執行遠程命令等

2.並不是全部的觸發器狀態發生改變的場景都須要對其進行干預，如轉變爲"OK"狀態時，相應地，若是觸發器的狀態轉變爲"Problem"，就須要告知全部關心其相關監控指標的人員了。

3."通知(notification)"是zabbix中最經常使用的"動做"之一

 

實現zabbix的通知功能，通常須要兩個步驟：

1. 定義所需的"媒介(media)"：一般指發送信息的途徑，如郵件、Jabber和SMS等；

2.配置一個"動做(action)"：發送信息至某"媒介"；

 

動做由"條件"和"操做"組成，它的邏輯爲當"條件"知足時，就執行相應的"操做" "發送通知"和"執行遠程命令"是兩個最基本的操做

 

zabbix事件(event)

1.觸發器(trigger)事件：觸發器狀態每次發生改變，都會生成相 應"事件"，且一般包含詳細信息，如發生的時間及新的狀態等；

2.發現(discovery)事件：zabbix會週期性地掃描"網絡發現規則" 中指定的IP範圍，一旦發現主機或服務，就會生成一個或幾個 發現事件；

發現事件有8類：Service Up、Service Down、Host Up、 Host Down、Service Discovered、Service Lost、Host

Discovered和Host Lost；

 

在zabbix的web界面定義action

選擇合適的事件源，來建立action，咱們只瞭解了觸發器，因此就選擇triggers

點擊create action

action:定義action自身的屬性

operations：操做，在operations裏面能夠定義一些操做，每隔多長時間執行一次（是從正常到非正常的而執行的動做）

Recovery operations:尚未執行operations的動做，又恢復了（從problem到ok狀態），要執行Recoery operations裏定義的動做

Acknowledge operations:聲明已經執行了operations裏定義的動做

 

報警向Adminstration中users中的用戶發送消息

用戶想要接受報警消息，須要先定義接受報警信息的媒介

1.定義媒介的類型，關聯到用戶，讓他們收到告警信息

先定義個Email

 

配置完以後，點擊更新Update，ming_mail定義好了

接着就能夠回到Users中點擊admin，就能夠選擇定義好的媒介類型了

點擊添加，添加成功

假如還想添加其餘的媒介，點擊add，再次定義便可

未來在公司裏面，有好多人都想了解線上服務的信息，那麼就要在zabbix上給他們建立一個帳號，再給他們關聯一個媒介類型，這樣才能讓他們收到告警信息

2.建立action，監控一個服務，若是這個服務掛了，那麼就嘗試重啓，成功了就ok，沒成功就發告警信息

（1）配置redis服務

yum install redis -y

vim /etc/redis.conf

bind 0.0.0.0 簡單的配置一下監聽的地址

開啓redis服務

systemctl start redis

ss -ntl 查看6379端口

 

（2）定義item

點擊add，添加成功

回到monitoring中查看定義的監控項 up或1爲redis服務正常

（3）定義觸發器triggers，若是發現服務掛了，就會發送觸發器事件

點擊add，添加成功

（4）建立action

 

vim /etc/sudoers

vim /etc/zabbix/zabbix_agentd.conf

而後重啓zabbix-agent服務

systemctl restart zabbix-agent

而後在回到web界面點擊add

第一步作好了，當redis服務掛了以後，就會先嚐試從新啓動redis服務，重啓成功就ok，不成功開始執行第二步，給相關人員發消息，接着就開始定義第二步的操做

點擊new，定義第二步

再點擊add，第二步添加成功

若是執行遠程命令服務重啓成功了，怎麼辦，接下來的操做就要在recovery operations裏定義，同樣也是給相關人員發消息，說服務已經恢復了，能夠不用來了

點擊add,添加成功

再次點擊add

接着咱們就能夠測試了，先停掉redsi服務，去monitoring中查看dashboard面板，如圖：

過了一會，自動恢復過來，說明遠程執行命令重啓redis服務成功，接着又會向admin發消息，如圖：

而後咱們去linux系統中查看郵件

接着咱們在開啓redis服務，而後再關掉redis服務並卸載redis

過了一會沒有自動回覆，說明遠程執行命令失敗，再過一會，就開始發郵件了

再到linux系統中查看郵件

 

zabbix可視化

zabbix提示了衆多的可視化工具提供直觀展現，如graphscreen及map等

自定義圖形（graphs）

自定義圖形中能夠集中展現多個時間序列的數據流

支持"線狀圖(normal)"、"堆疊面積圖(stacked)"、"餅圖(pie)" 和"分離型餅圖(exploded)"四種不一樣形式的圖形

"Configuration → Hosts (或者Templates) → Graphs→Create graph"

自定義圖形的相關屬性說明

Name：圖形的獨有名稱；

Width：圖形的寬度，單位爲像素；僅適用於"預覽(preview)"模式、餅圖或分離型餅圖；

Height：圖形的高度，單位爲像素；

Graph type：圖形類型，共有四種，即"線狀圖(normal)"、"堆 疊面積圖(stacked)"、"餅圖(pie)"和"分離型餅圖(exploded)"；

Show legend：是否顯示圖例，即圖形數據序列說明；

Show working time：是否高亮顯示工做時間區域；選定時， 非工做時間區間的背景爲灰色；此功能不適用於pie和 exploded；

Show triggers：是否顯示觸發器；此功能不適用於pie和 exploded；

Y axis MIN value：Y軸最小刻度，其類型有三種；

Calculated：自動計算；

Fixed：固定值，此功能不適用於pie和exploded；

Item：相關item的最近一次取值爲其最小刻度；

Y axis MAX value：Y軸最大刻度，其類型同上述最小刻度的 說明；

3D view：3D風格，此功能僅適用於pie和exploded；

Items：圖形展現的數據序列所來自的item，一個圖形中能夠同 時展現多個item；

 

在一個圖形中，不一樣item的圖形還有一些可單獨配置的屬 性，如圖形顏色、繪圖風格等

Function：展現何種聚合數據；

min：僅展現最小值；

avg：僅展現平均值；

max：僅展現最大值；

all：展現全部，即上面三類數據；

Draw stype：繪圖風格，僅適用於線狀圖；

Line：繪製爲簡單線條；

Filled region：區域填充圖，即面積圖；

Bold line：加粗線條；

Dot：虛線圖，以稀疏的點組成；

Dashed line：虛線圖，以破折號組成；

Y axis side：Y軸顯示的位置，能夠爲圖形左側或右側；

Colour：圖形顏色；

 

多個指標顯示在一張圖上

 

 

 

 

屏幕(screen)

屏幕用於集中展現多個數據源的相關信息，可實現快速瀏覽 關注的信息

從根本上來說，screen就是一個圖表，能夠在建立時能夠指 定其行數和列數，然後在每一個格子中指定要展現的內容

 

screen能夠展現的信息有許多種，如：簡單圖形、用戶自定 義圖形、maps、其它screen、文本信息、概述的服務器信息、 概述的主機信息、概述的觸發器信息、觸發器狀態、系統狀 態等等

 

查看

Configuration-->Screens-->Create Screen

建立

Monitoring-->Screens

 

建立screen

Monitoring-->Screens

點擊create screen

點擊add，建立成功

而後再點進去編輯

點擊Edit screen

點擊change，選擇graph，而後add

而後第一張graph就添加進去screen中了

而後再次點擊change，添加第二張

 

模板（Templates）

模板是一系列配置的集合，它能夠方便地快速部署在某監控 對象上，並支持重複應用

items

triggers

graphs

applications

screens (since Zabbix 2.0)

low-level discovery rules (since Zabbix 2.0)

將模板應用至某主機上時，其定義的全部條目都會自動添加

模板的另外一個好處在於，必要時，修改了模板，被應用的主機都會相應的做出修改

建立模板(Templates)

Configuration-->Templates

點擊建立模板create template

在模板上能夠按需添加item、trigger、screen、graph,application及發現規則

 

而後將模板關聯到主機上去，Configuration-->Hosts

點擊node5主機

點擊Update，回到Hosts

也能夠移除鏈接

 

宏(macros)

宏是一種抽象(Abstraction)，它根據一系列預約義的規則替 換必定的文本模式，而解釋器或編譯器在遇到宏時會自動進 行這一模式替換

 

相似地，zabbix基於宏保存預設文本模式，而且在調用時將 其替換爲其中的文本

zabbix有許多內置的宏，如{HOST.NAME}、{HOST.IP}、{TRIGGER.DESCRIPTION}、{TRIGGER.NAME}、{TRIGGER.EVENTS.ACK}等

 

詳細信息請參考官方文檔

https://www.zabbix.com/documentation/2.0/manual/appendix/macros/supported_by_location

 

爲了更強的靈活性，zabbix還支持在全局、模板或主機級別 使用用戶自定義宏(user macro)

用戶自定義宏要使用"{$MACRO}"這種特殊的語法格式

宏能夠應用在item keys和descriptions、trigger名稱和表達 式、主機接口IP/DNS及端口、discovery機制的SNMP協議 的相關信息中等

宏的名稱只能使用大寫字母、數字及下劃線

進一步信息請參考

https://www.zabbix.com/documentation/2.0/manual/appendix/macros/supp

orted_by_location#additional_support_for_user_macros

 

宏替換次序

首先是主機級別的宏；

其次是當前主機上一級模板中(直接連接至主機的模板)的宏， 多個一級模板按其ID號排序；

再接着是二級模板中的宏；然後依次類推；

最後檢查的是全局宏；

zabbix若是沒法查找到某主機定義使用的宏，則不會對其進行替換操做。要使用用戶自定義宏，有如下兩種算途徑：

全局宏："Administration → General → Macros"

主機或模板級別的宏：編輯相應主機或模板的屬性便可

 

Macros使用示例

在主機級別定義一個名爲{$CPUMAXSWITCHES}的宏，以 定義當前主機所接受的CPU上下文切換的合理次數

然後在主機的triggers中使用此宏

 

宏就是一個變量，分全局宏和主機或者模板上的宏（全局宏在adminstration中的user中定義，主機宏在host中定義，模板宏在模板上定義），定義完一個宏，在任何地方均可調用，假如說將被監控上某服務的端口定義爲一個宏，那麼若是該服務的端口發生變化，也不用在zabbix web界面上去更改

定義宏