3.萬一某次採樣的結果不在被認爲是合理的範圍內,而後就會作出告警操做,儘早的讓相關人員得知到此消息node
系統指標:CPU,memery,IO(Disk,Network)nginx
1.CPU:sys(消耗在系統空間的比例),usr(用戶空間的比例),idle(空閒的比例),,,等web
2.memery:total(總大小),userd(已用空間大小),free(空閒大小),cached(放在緩存的大小),buffer,shm(共享內存的大小),,,等redis
系統一旦起來,會運行不少進程,對進程而言,他有多少個,他的變化量,處於運行狀態的,處於睡眠狀態的,處於僵死狀態的等,,,這些又是指標
業務指標:好比:對於nginx服務,假如說nginx也算是一個進程,他時而處於運行狀態,時而處於睡眠狀態,對於nginx自己來講,他每秒接受的請求數量,每秒處理的請求數量等,這些能夠理解爲業務指標。
咱們要監控的某個特定主機的某一項指標,若是這項指標是核心而敏感的數據,普通用戶是不具備權限的,要想獲取到核心的數據,就要以管理員的身份來運行,能夠用ssh帳號遠程鏈接認證來鏈接到監控的主機上,從而獲取到核心的數據,來實現管理。
在監控的目標主機上運行一個進程,這個進程能夠與其控制端經過非系統的認證邏輯來進行認證,即使用戶得到了認證的信息,也不能得到系統級權限。經過了認證後,控制端就會只會agent端作出一些操做,若是agent端以管理員身份來運行,就能在目標主機上得到設計者設計的權限。
一些專業的服務器也能夠不依賴於操做系統提供的系統級接口來監控,就算沒裝操做系統,也能夠獲取該主機的CPU,memery,IO用量,這種方式依賴硬件級的接口,英特爾智慧平臺接口
在jvm虛擬機上有一個jmx接口,經過這個接口來獲取數據指標,來完成監控
趨勢數據:按照固定的時間長度作聚合運算後僅保留有限數據項的數據
假如說,每5分鐘收集一次數據,那麼一小時就要採集12次,這12次採集的數據就是歷史數據,將這12次採集的數據通過聚合運算得出聚合的結果,可能只有三四個數據項,最大,最小,平均值,這就是趨勢數據。
因此爲了展現數據的長期走勢,多保留一些趨勢數據,歷史數據僅保留最近幾個月的,可是這麼一來,就會給數據庫帶來的更大的壓力,由於既要存儲趨勢數據,又要存儲歷史數據,爲了解決這個問題,早期使用關係型數據庫做爲存儲系統,後來也有了一些其餘的方案,例如:rrd(cacti),round-robin-database輪詢數據庫
數據存儲就像圍繞一個圓進行存儲,當存滿了以後,再有新的數據來存儲,就會覆蓋原來最先存儲的數據。
若是一個監控系統監控到異常狀態的信息,向用戶發短信,就須要有一個前提,監控系統可以發短信,可是監控系統並不作這個工做,他只調用發短信這個服務,就須要寫一個程序,來調短信服務的api接口,這個程序寫好以後可以被監控系統所觸發便可。
Nagios:"難夠死",是一個很是好的告警系統,可是沒有提供存儲系統
Cacti:Cron+SNMP+Mysql,很好的展現系統,可是問題出現比較多
1.支持多種接口完成數據採集:agent,SNMP,IPMI(英特爾智慧平臺接口),jmx
(1)能夠告警升級,剛開始出故障時,發短信給運維工程師,隔兩小時後沒有解決問題,就發給他的領導,再隔兩小時沒解決,發給領導的領導,,,
(2)能夠發遠程命令,剛開始出故障時,尤爲是服務級故障,先不要當即發告警,在第一個週期內,試圖嘗試去解決問題,遠程指揮目標主機重啓一下服務,若是問題解決,就不用發警報了,若是沒有解決,那就開始發警報
4.展現:簡單圖,圖形,screen,slide,show,map,,,
1.statsd+influxdb(時序數據庫)+grafana
2.promethues(自身就至關於時序數據庫,可收集數據,存儲下來,並展現,但展現界面很差看,因此可結合grafana)+grafana
Zabbix Server:負責接收agent發送的報告信息的核心組 件,全部配置、統計數據及操做數據均由其組織進行;
Database Storage:專用於存儲全部配置信息,以及由zabbix收集的數據,以及存儲在Zabbix所配置的配置信息,好比:哪一個指標須要監控,多長時間監控一次等;
Web interface:zabbix的GUI接口,一般與Server運行在 同一臺主機上;
Proxy:可選組件,經常使用於分佈監控環境中,代理Server收 集部分被監控端的監控數據並統一發往Server端;
Agent:部署在被監控主機上,負責收集本地數據併發往 Server端或Porxy端;
Zabbix Server監控的主機上指標不僅一個,以一個指標爲例,假如每隔120秒採樣一次,採集一次存一次,並且每當一個時間段知足時會作一次聚合運算,得出聚合運算結果,最大值,最小值,平均值等,每次採集存儲下來以前會先評估一下數據是否知足觸發器,既是否在合理區間範圍內,若是在就OK,不然PROMBLE,一旦狀態發生轉換,假如上次是OK,如今轉換成了PROMBLE,就會觸發一個時間EVENT,就會採起行動,行動分多個層級,首先執行遠程命令,若是不行,就發報警等。
採集----》斷定閾值範圍-----》若是沒問題就存下來,若是有問題則有事件產生,就會產生某個行爲,告警操做
主機(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;模板能夠直接連接至單個主機;
web場景(web scennario):用於檢測web站點可用性的一個 或多個HTTP請求;
複製連接地址,而後在linux系統上,將其下載下來,注意你的dns和網關都正常,不然就會下載不上
再來看一下安裝了這個包,安裝的文件,能夠看到自動在/etc/yum.repo下面給你配好了zabbix倉庫
此時,再yum clean all,yum repolist就會列出安裝zabbix的yum倉庫
innodb_buffer_pool_size = 256M 緩衝池大小爲256M
yum install zabbix-server-mysql zabbix-web zabbix-web-mysql zabbix-agent zabbix-get zabbix-sender -y
考慮到zabbix來鏈接數據庫,儘量用普通用戶的身份來鏈接,因此須要進入數據庫中建立用戶
create database zbxdb character set 'utf8';
grant all on zbxdb.* to 'zbxuser'@'192.168.10.%' identified by 'zabbix';
安裝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
cp /etc/zabbix/zabbix_server.conf /etc/zabbix/zabbix_server.conf.bak 修改配置文件先作好備份,養成良好習慣
LogFile=/var/log/zabbix/zabbix_server.log 日誌文件
PidFile=/var/run/zabbix/zabbix_server.pid pid進程文件
DBHost=192.168.10.160 zabbix鏈接數據庫所在的主機
配置完後,啓動zabbix服務,而後查看zabbix服務狀態
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頁面
在瀏覽器上去訪問zabbix的web頁面,訪問成功,第一次訪問的時候,須要作一些初始化設置,以下圖
要配置監控目標主機的指標須要在configuration中配置
administration是用來管理zabbix系統自身的
yum install zabbix-agent zabbix-sender -y
vim /etc/zabbix/zabbix_agentd.conf
PidFile=/var/run/zabbix/zabbix_agentd.pid
LogFile=/var/log/zabbix/zabbix_agentd.log
Server=192.168.10.160 監控服務器是哪臺主機
ServerActive=192.168.10.160 主動監控的服務器是哪臺主機
而後點擊application應用集來定義監控項的類別,點擊建立應用集
key其實就是一些命令,而內建key其實就是通過屢次優化的命令,採集數據速度快,效率高,若是內建key不足以知足咱們的須要的話,還能夠用戶自定義key
3.(delta)本次採樣減去前一次採樣的值,在除以通過的時長
再來編輯一個item,網卡指標數據,要考慮的是要獲取哪一個網卡的值,要獲取哪一個網卡上的指標
接着查看採集的數據,在monitoring中的latest data查看
界定某特定的item採集到的數據的非合理區間或非合理狀態:邏輯表達式
problem:非正常狀態 --> 較老的zabbix版本爲true;
1.監控項"僅負責收集數據,而一般收集數據的目的還包括在 某指標對應的數據超出合理範圍時給相關人員發送告警信 息,"觸發器"正是用於爲監控項所收集的數據定義閾值
2.每個觸發器僅能關聯至一個監控項,但能夠爲一個監控項 同時使用多個觸發器
事實上,爲一個監控項定義多個具備不一樣閾值的觸發器,能夠 實現不一樣級別的報警功能
3.一個觸發器由一個表達式構成,它定義了監控項所採起的數 據的一個閾值
4.一旦某次採集的數據超出了此觸發器定義的閾值,觸發器狀 態將會轉換爲"Problem";而當採起的數據再次迴歸至合理範 圍內時,其狀態將從新返回到"OK"
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)將返回一週以前的最大值;
{www.magedu.com:system.cpu.load[all,avg1].last(0)}>3
表示主機www.magedu.com上全部CPU的過去1分鐘內的平均負 載的最後一次取值大於3時將觸發狀態變換
例如,當某網關主機不可用時,其背後的全部主機都將沒法正常訪問
若是全部主機都配置了觸發器並定義了相關的通知功能,相關人員將會接收到許多告警信息,這既不利於快速定位問題,也 會浪費資源
正肯定義的觸發器依賴關係能夠避免相似狀況的發生,它將使 用通知機制僅發送最根本問題相關的告警
注意:目前zabbix不可以直接定義主機間的依賴關係,其依 賴關係僅能經過觸發器來定義
監控主機zabbix server 經過交換機的網絡鏈接線來監控兩臺主機,假如交換機出現故障了,那麼zabbix server也就採集不了被監控主機的數據了,不只交換機的觸發器會報警,被監控主機的觸發器也會報警,此時定位故障就很差定位了,咱們不知道究竟是交換機出現了故障,仍是被監控主機出現了問題,因此此時要定義觸發器間的依賴關係,若是交換機出現了故障,交換機的觸發器報警了,全部依賴此交換機觸發器的主機就不用報警了。
1.在配置好監控項和觸發器以後,一旦正常工做中的某觸發器狀態發生改變,通常意味着有異常狀況發生,此時一般須要採起必定的動做(action),如告警或者執行遠程命令等
2.並不是全部的觸發器狀態發生改變的場景都須要對其進行干預,如轉變爲"OK"狀態時,相應地,若是觸發器的狀態轉變爲"Problem",就須要告知全部關心其相關監控指標的人員了。
3."通知(notification)"是zabbix中最經常使用的"動做"之一
2.配置一個"動做(action)":發送信息至某"媒介";
動做由"條件"和"操做"組成,它的邏輯爲當"條件"知足時,就執行相應的"操做" "發送通知"和"執行遠程命令"是兩個最基本的操做
1.觸發器(trigger)事件:觸發器狀態每次發生改變,都會生成相 應"事件",且一般包含詳細信息,如發生的時間及新的狀態等;
2.發現(discovery)事件:zabbix會週期性地掃描"網絡發現規則" 中指定的IP範圍,一旦發現主機或服務,就會生成一個或幾個 發現事件;
發現事件有8類:Service Up、Service Down、Host Up、 Host Down、Service Discovered、Service Lost、Host
選擇合適的事件源,來建立action,咱們只瞭解了觸發器,因此就選擇triggers
operations:操做,在operations裏面能夠定義一些操做,每隔多長時間執行一次(是從正常到非正常的而執行的動做)
Recovery operations:尚未執行operations的動做,又恢復了(從problem到ok狀態),要執行Recoery operations裏定義的動做
Acknowledge operations:聲明已經執行了operations裏定義的動做
報警向Adminstration中users中的用戶發送消息
配置完以後,點擊更新Update,ming_mail定義好了
接着就能夠回到Users中點擊admin,就能夠選擇定義好的媒介類型了
未來在公司裏面,有好多人都想了解線上服務的信息,那麼就要在zabbix上給他們建立一個帳號,再給他們關聯一個媒介類型,這樣才能讓他們收到告警信息
回到monitoring中查看定義的監控項 up或1爲redis服務正常
(3)定義觸發器triggers,若是發現服務掛了,就會發送觸發器事件
vim /etc/zabbix/zabbix_agentd.conf
systemctl restart zabbix-agent
第一步作好了,當redis服務掛了以後,就會先嚐試從新啓動redis服務,重啓成功就ok,不成功開始執行第二步,給相關人員發消息,接着就開始定義第二步的操做
若是執行遠程命令服務重啓成功了,怎麼辦,接下來的操做就要在recovery operations裏定義,同樣也是給相關人員發消息,說服務已經恢復了,能夠不用來了
接着咱們就能夠測試了,先停掉redsi服務,去monitoring中查看dashboard面板,如圖:
過了一會,自動恢復過來,說明遠程執行命令重啓redis服務成功,接着又會向admin發消息,如圖:
接着咱們在開啓redis服務,而後再關掉redis服務並卸載redis
過了一會沒有自動回覆,說明遠程執行命令失敗,再過一會,就開始發郵件了
zabbix提示了衆多的可視化工具提供直觀展現,如graphscreen及map等
支持"線狀圖(normal)"、"堆疊面積圖(stacked)"、"餅圖(pie)" 和"分離型餅圖(exploded)"四種不一樣形式的圖形
"Configuration → Hosts (或者Templates) → Graphs→Create graph"
Width:圖形的寬度,單位爲像素;僅適用於"預覽(preview)"模式、餅圖或分離型餅圖;
Graph type:圖形類型,共有四種,即"線狀圖(normal)"、"堆 疊面積圖(stacked)"、"餅圖(pie)"和"分離型餅圖(exploded)";
Show working time:是否高亮顯示工做時間區域;選定時, 非工做時間區間的背景爲灰色;此功能不適用於pie和 exploded;
Show triggers:是否顯示觸發器;此功能不適用於pie和 exploded;
Y axis MIN value:Y軸最小刻度,其類型有三種;
Fixed:固定值,此功能不適用於pie和exploded;
Y axis MAX value:Y軸最大刻度,其類型同上述最小刻度的 說明;
3D view:3D風格,此功能僅適用於pie和exploded;
Items:圖形展現的數據序列所來自的item,一個圖形中能夠同 時展現多個item;
在一個圖形中,不一樣item的圖形還有一些可單獨配置的屬 性,如圖形顏色、繪圖風格等
Y axis side:Y軸顯示的位置,能夠爲圖形左側或右側;
屏幕用於集中展現多個數據源的相關信息,可實現快速瀏覽 關注的信息
從根本上來說,screen就是一個圖表,能夠在建立時能夠指 定其行數和列數,然後在每一個格子中指定要展現的內容
screen能夠展現的信息有許多種,如:簡單圖形、用戶自定 義圖形、maps、其它screen、文本信息、概述的服務器信息、 概述的主機信息、概述的觸發器信息、觸發器狀態、系統狀 態等等
Configuration-->Screens-->Create Screen
模板是一系列配置的集合,它能夠方便地快速部署在某監控 對象上,並支持重複應用
low-level discovery rules (since Zabbix 2.0)
模板的另外一個好處在於,必要時,修改了模板,被應用的主機都會相應的做出修改
在模板上能夠按需添加item、trigger、screen、graph,application及發現規則
而後將模板關聯到主機上去,Configuration-->Hosts
宏是一種抽象(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)
宏能夠應用在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"
在主機級別定義一個名爲{$CPUMAXSWITCHES}的宏,以 定義當前主機所接受的CPU上下文切換的合理次數
宏就是一個變量,分全局宏和主機或者模板上的宏(全局宏在adminstration中的user中定義,主機宏在host中定義,模板宏在模板上定義),定義完一個宏,在任何地方均可調用,假如說將被監控上某服務的端口定義爲一個宏,那麼若是該服務的端口發生變化,也不用在zabbix web界面上去更改