一個標准的監控系統所具備的基本功能：
3.萬一某次采樣的結果不在被認為是合理的范圍內，然后就會做出告警操作，盡早的讓相關人員得知到此消息
系統指標：CPU，memery,IO(Disk,Network)
1.CPU:sys(消耗在系統空間的比例)，usr（用戶空間的比例），idle（空閑的比例）,,,等
2.memery：total（總大小），userd（已用空間大小），free（空閑大小），cached（放在緩存的大小），buffer，shm（共享內存的大小），，，等
系統一旦起來，會運行很多進程，對進程而言，他有多少個，他的變化量，處於運行狀態的，處於睡眠狀態的，處於僵死狀態的等，，，這些又是指標
業務指標：比如：對於nginx服務，假如說nginx也算是一個進程，他時而處於運行狀態，時而處於睡眠狀態，對於nginx本身來說，他每秒接受的請求數量，每秒處理的請求數量等，這些可以理解為業務指標。
數據采集
1.ssh接口（監控中最為簡單的方式）
我們要監控的某個特定主機的某一項指標，如果這項指標是核心而敏感的數據，普通用戶是不具有權限的，要想獲取到核心的數據，就要以管理員的身份來運行，可以用ssh賬號遠程連接認證來連接到監控的主機上，從而獲取到核心的數據，來實現管理。
在監控的目標主機上運行一個進程，這個進程可以與其控制端通過非系統的認證邏輯來進行認證，即便用戶獲得了認證的信息，也不能獲得系統級權限。通過了認證后，控制端就會只會agent端做出一些操作，如果agent端以管理員身份來運行，就能在目標主機上獲得設計者設計的權限。
3.英特爾智慧平台接口
一些專業的服務器也可以不依賴於操作系統提供的系統級接口來監控，就算沒裝操作系統，也可以獲取該主機的CPU，memery,IO用量，這種方式依賴硬件級的接口，英特爾智慧平台接口
4.jmx接口
在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程序架構
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；模板可以直接鏈接至單個主機；
web場景(web scennario)：用於檢測web站點可用性的一個 或多個HTTP請求；
Zabbix的邏輯架構
Zabbix Server Processes
安裝zabbix
復制鏈接地址，然后在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頁面，訪問成功，第一次訪問的時候，需要做一些初始化設置，如下圖
monitoring
configuration
要配置監控目標主機的指標需要在configuration中配置
Report
administration是用來管理zabbix系統自身的
1.安裝agent(在監控的目標主機上配置)
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
Server=192.168.10.160 監控服務器是哪台主機
ServerActive=192.168.10.160 主動監控的服務器是哪台主機
然后點擊application應用集來定義監控項的類別，點擊創建應用集
key其實就是一些命令，而內建key其實就是經過多次優化的命令，采集數據速度快，效率高，如果內建key不足以滿足我們的需要的話，還可以用戶自定義key
3.(delta)本次采樣減去前一次采樣的值，在除以經過的時長
再來編輯一個item，網卡指標數據，要考慮的是要獲取哪個網卡的值，要獲取哪個網卡上的指標
接着查看采集的數據，在monitoring中的latest data查看
trigger觸發器
界定某特定的item采集到的數據的非合理區間或非合理狀態：邏輯表達式
problem:非正常狀態 --> 較老的zabbix版本為true；
創建觸發器(trigger)
1.監控項"僅負責收集數據，而通常收集數據的目的還包括在 某指標對應的數據超出合理范圍時給相關人員發送告警信 息，"觸發器"正是用於為監控項所收集的數據定義閾值
2.每一個觸發器僅能關聯至一個監控項，但可以為一個監控項 同時使用多個觸發器
事實上，為一個監控項定義多個具有不同閾值的觸發器，可以 實現不同級別的報警功能
3.一個觸發器由一個表達式構成，它定義了監控項所采取的數 據的一個閾值
4.一旦某次采集的數據超出了此觸發器定義的閾值，觸發器狀 態將會轉換為"Problem"；而當采取的數據再次回歸至合理范 圍內時，其狀態將重新返回到"OK"
觸發器表達式
{<server>:<key>.<function>(<parameter>)}<operator><constant>
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也就采集不了被監控主機的數據了，不僅交換機的觸發器會報警，被監控主機的觸發器也會報警，此時定位故障就不好定位了，我們不知道到底是交換機出現了故障，還是被監控主機出現了問題，所以此時要定義觸發器間的依賴關系，如果交換機出現了故障，交換機的觸發器報警了，所有依賴此交換機觸發器的主機就不用報警了。
2.被監控主機上服務觸發器的依賴關系
如圖：觸發器之間的依賴關系：被監控主機上的服務是否正常依賴於主機和主機網卡，而主機和主機網卡是否正常，依賴於交換機，所以監控到交換機故障，被監控主機就不用報警了，監控到被監控主機網卡故障，被監控主機上的服務就不用報警了（被監控網卡故障會導致zabbix server不能采集到被監控主機服務指標的數據）。
注釋：定義觸發器之間的依賴關系需要根據網絡拓撲圖來定義的
在web界面創建觸發器(trigger)
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
選擇合適的事件源，來創建action，我們只了解了觸發器，所以就選擇triggers
operations：操作，在operations里面可以定義一些操作，每隔多長時間執行一次（是從正常到非正常的而執行的動作）
Recovery operations:還沒有執行operations的動作，又恢復了（從problem到ok狀態），要執行Recoery operations里定義的動作
Acknowledge operations:聲明已經執行了operations里定義的動作
報警向Adminstration中users中的用戶發送消息
1.定義媒介的類型，關聯到用戶，讓他們收到告警信息
配置完之后，點擊更新Update，ming_mail定義好了
接着就可以回到Users中點擊admin，就可以選擇定義好的媒介類型了
將來在公司里面，有好多人都想了解線上服務的信息，那么就要在zabbix上給他們創建一個賬號，再給他們關聯一個媒介類型，這樣才能讓他們收到告警信息
2.創建action，監控一個服務，如果這個服務掛了，那么就嘗試重啟，成功了就ok，沒成功就發告警信息
（1）配置redis服務
（2）定義item
回到monitoring中查看定義的監控項 up或1為redis服務正常
（3）定義觸發器triggers，如果發現服務掛了，就會發送觸發器事件
（4）創建action
vim /etc/zabbix/zabbix_agentd.conf
systemctl restart zabbix-agent
第一步做好了，當redis服務掛了之后，就會先嘗試重新啟動redis服務，重啟成功就ok，不成功開始執行第二步，給相關人員發消息，接着就開始定義第二步的操作
如果執行遠程命令服務重啟成功了，怎么辦，接下來的操作就要在recovery operations里定義，一樣也是給相關人員發消息，說服務已經恢復了，可以不用來了
接着我們就可以測試了，先停掉redsi服務，去monitoring中查看dashboard面板，如圖：
過了一會，自動恢復過來，說明遠程執行命令重啟redis服務成功，接着又會向admin發消息，如圖：
接着我們在開啟redis服務，然后再關掉redis服務並卸載redis
過了一會沒有自動回復，說明遠程執行命令失敗，再過一會，就開始發郵件了
zabbix可視化
zabbix提示了眾多的可視化工具提供直觀展示，如graphscreen及map等
自定義圖形（graphs）
支持"線狀圖(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就是一個圖表，可以在創建時可以指 定其行數和列數，而后在每個格子中指定要展示的內容
screen可以展示的信息有許多種，如：簡單圖形、用戶自定 義圖形、maps、其它screen、文本信息、概述的服務器信息、 概述的主機信息、概述的觸發器信息、觸發器狀態、系統狀 態等等
查看
Configuration-->Screens-->Create Screen
創建
創建screen
模板（Templates）
模板是一系列配置的集合，它可以方便地快速部署在某監控 對象上，並支持重復應用
low-level discovery rules (since Zabbix 2.0)
模板的另一個好處在於，必要時，修改了模板，被應用的主機都會相應的作出修改
創建模板(Templates)
在模板上可以按需添加item、trigger、screen、graph,application及發現規則
然后將模板關聯到主機上去，Configuration-->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)
宏可以應用在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上下文切換的合理次數
宏就是一個變量，分全局宏和主機或者模板上的宏（全局宏在adminstration中的user中定義，主機宏在host中定義，模板宏在模板上定義），定義完一個宏，在任何地方都可調用，假如說將被監控上某服務的端口定義為一個宏，那么如果該服務的端口發生變化，也不用在zabbix web界面上去更改
定義宏
