CPU利用率大於50%,須要注意;大於70%,須要密切關注;高於90%,狀況比較嚴重。php
監控命令:vmstat、sar、dstat、mpstat、top、pscss
類型java |
度量方法node |
衡量標準mysql |
利用率linux |
一、vmstat 統計1-%idleios 二、sar -u 統計1-%idlenginx 三、dstat 統計1-%idlweb 四、mpstat -P ALL 統計1-%idleredis |
注意>=50% 告警>=70% 嚴重>=90% |
滿載 |
一、vmstat的r值> cpu邏輯顆數 二、sar -q ,「runq-sz」>cpu邏輯顆數
|
運行隊列大於1時,證實已經有必定的負載 |
當物理內存不夠時,會使用swap分區,因此性能測試過程當中須要關注swap和mem的使用狀況。
物理內存不夠,大量的內存置換到swap空間,可能致使CPU和I/O的瓶頸。
監控命令:vmstat、sar、dstat、free、top、ps等
類型 |
度量方法 |
衡量標註 |
佔用率 |
一、free 查看使用狀況 二、vmstat 三、sar -r 四、ps |
注意>=50% 告警>=70% 嚴重>=80% |
滿載 |
一、vmstat的si/so比例,swapd佔比 二、sar -W 查看次缺頁數 三、dmesg | grep killed |
一、so數值大,且swapd已經佔比很高,內存已經飽和 二、sar命令次缺頁多意味內存已經飽和 三、內存不夠用會觸發內核的OOM機制 |
監控命令:sar、ifconfig、netstat,以及查看net的dev速率。
經過查看發現收發包的吞吐率達到網卡的最大上限,網絡數據報文有由於這類緣由而引發的丟包、阻塞等現象都證實當前網絡可能存在瓶頸。
爲了減少網絡對性能測試的影響,通常咱們都在局域網中進行測試執行。
類型 |
度量方法 |
衡量標準 |
使用狀況 |
一、sar -n DEV 的收發計數大於網卡上限 二、ifconfig RX/TX寬帶超過網卡上限 三、cat /proc/net/dev的速率超過上限 四、nicstat的util基本滿負荷 |
一、收發包的吞吐率達到網卡上限 二、有延遲 三、有丟包 四、有阻塞 |
滿載 |
一、ifconfig dropped 有計數 二、netstat -s "segments retransmited"有計數 三、sar -n EDEV,rxdrop/s txdrop/s有計數 |
有丟包統計 |
錯誤 |
一、ifconfig,「errors」 二、netstat -i,RX-ERR TX-ERR 三、sar -n EDEV,rxerr/s txerr/s 四、ip -s link, 「errors」 |
錯誤有計數 |
I/O讀寫頻繁的時候,若是I/O得不到知足會致使應用的阻塞。
須要考慮I/O的TPS、平均I/O數據、平均隊列長度、平均服務時間、平均等待時間、IO利用率(磁盤Busy Time%)等指標
監控命令:sar、iostat、iotop
類型 |
度量方法 |
衡量標準 |
使用狀況 |
一、iostat -xz,「%util」 二、sar -d,「%util」 三、cat /proc/pid/sched | grep iowait |
注意>=40% 告警>=60% 嚴重>=80% |
滿載 |
一、iostat -xnz,「avgqu-sz 」>1 二、iostat await>70 |
IO疑似滿載 |
錯誤 |
一、dmseg 查看io錯誤 二、smartctl /dev/sda |
有錯誤信息 |
# uname –a (查看操做系統信息,所檢查服務器爲64位操做系統)
# lsb_release –a (查看linux發行商版本,所檢查服務器linux版本爲:CentOS6.5)
一、手動下載解壓安裝
nmon: 下載命令 wget http://sourceforge.net/projects/nmon/files/download/nmon_x86_12a.zip/download
安裝位置:/home/nmon (任意目錄)
一、 在home 目錄下建立nmon文件夾:# mkdir nmon
二、 上傳nmon_linux_14i.tar.gz 到nmon目錄
三、 解壓:# tar –zxvf nmon_linux_14i.tar.gz
四、 賦權限:# chmod –R 755 nmon
五、 啓動nmon:# ./nmon_x86_64_sles11(在nmon目錄下執行命令)
二、yum自動安裝
首先安裝第三方yum源
wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo
wget -P /target/path http://192.168.1.1:3333/file/to/download.gz 下載文件時若須要指定目錄則使用 -P 參數,若是指定的目錄不存在,則會自動建立
wget http://192.168.1.1:3333/file/to/download.gz -O /path/to/rename.gz 下載的文件進行重命名則使用 -O 參數,若是重命名中包含路徑則該路徑必須事先建立好
更新yum源
yum makecache
安裝nmon
yum -y install nmon
安裝成功顯示如下界面:
輸入如下命令:
c 可顯示CPU的信息
m 對應內存
n 對應網絡
d 能夠查看磁盤信息
t 能夠查看系統的進程信息
一、修改啓動文件名稱:
# mv nmon_x86_64_sles11 nmon
# ./nmon
二、 添加到環境變量中:
# vim /etc/profile (在profile中寫入如下兩行內容)
PATH=PATH:/home/nmon/nmon(PATH:/home/nmon/nmon(PATH:後爲命令的路徑)
export PATH
三、 保存退出
四、 使配置文件當即生效
# source /etc/profile
# nmon (在任何目錄下執行nmon命令啓動nmon)
在實際的性能測試中咱們須要把一段時間以內的數據記錄下來,如:
一、採集數據
# nmon -s1 -c60 -f -m /home/nmon
參數說明:
-s1 每隔n秒抽樣一次,這裏爲1秒
-c60 取出多少個抽樣數量,這裏爲60,即監控=1*60/60=1分鐘
-f 按標準格式輸出文件名稱:<hostname>_YYMMDD_HHMM.nmon
-m 指定監控文件的存放目錄,-m後跟指定目錄
nmonanalyser:
版本:nmon_analyser_v47.zip
1、將.nmon文件轉化成.csv文件
# sort chen _151014_1659.nmon > chen _151014_1659.csv
2、將.csv文件下載到本地
3、打開nmon analyser工具
在本地解壓nmon_analyser_v47.zip
雙擊打開:nmon analyser v47.xlsm
點擊Analyse nmon data按鈕,加載以前下載的chen_151014_1659.csv文件。
開源工具介紹
一、Zabbix
Zabbix是一個基於WEB界面的提供分佈式系統監控以及網絡監控功能的企業級開源運維平臺,也是目前國內互聯網用戶中使用最廣的監控軟件,雲智慧遇到的85%以上用戶在使用Zabbix作監控解決方案。入門容易、上手簡單、功能強大而且開源免費是雲智慧對Zabbix的最直觀評價。Zabbix易於管理和配置,能生成比較漂亮的數據圖,其自動發 現功能大大減輕平常管理的工做量,豐富的數據採集方式和API接口可讓用戶靈活進行數據採集,而分佈式系統架構能夠支持監控更多的設備。理論上,經過 Zabbix提供的插件式架構,能夠知足企業的任何需求。
優勢:
1. 支持多平臺的企業級分佈式開源監控軟件
2. 安裝部署簡單,多種數據採集插件靈活集成
3. 功能強大,可實現複雜多條件告警,
4. 自帶畫圖功能,獲得的數據能夠繪成圖形5. 提供多種API接口,支持調用腳本6. 出現問題時可自動遠程執行命令(需對agent設置執行權限)
缺點:
1. 項目批量修改不方便2. 入門容易,能實現基礎的監控,可是深層次需求須要很是熟悉Zabbix並進行大量的二次定製開發,難度較大;3. 系統級別報警設置相對比較多,若是不篩選的話報警郵件會不少;而且自定義的項目報警須要本身設置,過程比較繁瑣(可是網上的模板比較,也可使用模板導入的方法);4. 缺乏數據彙總功能,如沒法查看一組服務器平均值,需進行二次開發;5. 數據報表須要特殊二次開發定義;
2、Open-falcon
Open-falcon是小米運維團隊從互聯網公司的需求出發,根據多年的運維經驗,結合SRE、SA、DEVS的使用經驗和反饋,開發的一套面向互聯網的企業級開源監控產品。
Open-falcon架構
用戶羣:目前有幾十家企業用戶不一樣程度使用。
優勢:
1. 自動發現,支持falcon-agent、snmp、支持用戶主動push、用戶自定義插件支持
2. 支持每一個週期上億次的數據採集、告警斷定、歷史數據存儲和查詢
3. 高效的portal、支持策略模板、模板繼承和覆蓋、多種告警方式、支持callback調用
4. 單機支撐200萬metric的上報、歸檔、存儲
5. 採用rrdtool的數據歸檔策略,秒級返回上百個metric一年的歷史數據
6. 多維度的數據展現,用戶自定義Screen
7. 經過各類插件目前支持Linux、Windows、Mysql、Redis、Memache、RabbitMQ和交換機監控。
缺點:
因爲發佈時間較短,不少基礎的服務監控插件(如Tomcat、apache等)還不支持,不少功能還在不斷完善中,另外因爲缺乏專門的支持,雖然有開放社區,可是解決問題的效率相對較低。
Zabbix 是由 Alexei Vladishev 開發的一種網絡監視、管理系統,基於CS架構。可用於監視各類網絡服務、服務器和網絡機器等狀態。使用MySQL, PostgreSQL, SQLite, Oracle 或 IBM DB2 等數據庫儲存資料。Server 端基於C語言、Web 管理端則是基於 PHP 所製做的。Zabbix 可使用多種方式監視。能夠只使用 Simple Check 不須要安裝 Client 端,亦可基於 SMTP 或 HTTP ... 各類協定作死活監視。在客戶端如 UNIX, Windows 中安裝 Zabbix Agent 以後,可監視 CPU Load、網絡使用情況、硬盤容量等各類狀態。而就算沒有安裝 Agent 在監視對象中,Zabbix 也能夠經由 SNMP、TCP、ICMP、利用 IPMI、SSH、telnet 對目標進行監視。另外,Zabbix 包含 XMPP 等各類 Item 警示功能。
zabbix官網: https://www.zabbix.com
zabbix 主要由2部分構成 zabbix server和 zabbix agent
zabbix proxy是用來管理其餘的agent,做爲代理
zabbix監控範疇
² 硬件監控 :Zabbix IPMI Interface
² 系統監控 :Zabbix Agent Interface
² Java 監控:ZabbixJMX Interface
² 網絡設備監摶:Zabbix SNMP Interface
² 應用服務監控:Zabbix Agent UserParameter
² MySQL 數據庫監控:percona-monitoring-pldlgins
² URL監控:Zabbix Web監控
一、實驗準備
centos系統服務器3臺、 一臺做爲監控服務器, 兩臺臺做爲被監控節點, 配置好yum源、 防火牆關閉、 各節點時鐘服務同步、 各節點之間能夠經過主機名互相通訊。
[root@linux-node2 ~]# systemctl stop firewalld.service
[root@linux-node2 ~]# setenforce 0
setenforce: SELinux is disabled
init的發展:
CentOS 5: SysV init,串行
CentOS 6:Upstart,並行,借鑑ubantu
CentOS 7:Systemd,並行,借鑑MAC
Systemd是由紅帽公司開發,systemd是Linux系統中最新的初始化系統(init),它主要的設計目的是克服Sys V 固有的缺點,提升系統的啓動速度,systemd和upstart是競爭對手,ubantu上使用的是upstart的啓動方式,centos7上使用systemd替換了Sys V
開機啓動chkconfig name on–>systemctl enable name.service
開機禁止啓動chkconfig name off –>systemctl disable name.service
查看全部服務的開機自啓狀態chkconfig –list–>systemctl list-unit-files -t service
啓動:service name start –>systemctl start name.service
中止:service name stop –>systemctl stop name.service
重啓:service name restart–>systemctl restart name.service
狀態:service name status–>systemctl status name.service
[root@localhost ~]# rpm -qa mysql* #查看已安裝的 [root@localhost ~]# yum remove mysql [root@localhost ~]# yum remove mysql-connector-java-5.1.17-6.el6.noarch [root@localhost ~]# yum remove mysql-libs-5.1.73-8.el6_8.x86_64 ##刪除MySQL物理存儲位置 [root@localhost mysql]# cd /var/lib/mysql [root@localhost mysql]# rm -rf ./*
1.下載mysql源安裝包
shell> wget http://dev.mysql.com/get/mysql57-community-release-el7-8.noarch.rpm
2.安裝mysql源
shell> yum localinstall mysql57-community-release-el7-8.noarch.rpm
3.檢查mysql源是否安裝成功
shell> yum repolist enabled | grep "mysql.*-community.*"
4.修改 vim /etc/yum.repos.d/mysql-community.repo源 ,改變默認安裝的mysql版本。好比要安裝5.6版本,將5.7源的enabled=1改爲enabled=0。而後再將5.6源的enabled=0改爲enabled=1便可。
5.安裝MySQL
shell> yum install mysql-community-server
6.啓動MySQL服務
shell> systemctl start mysqld
7.開機啓動
shell> systemctl enable mysqld
shell> systemctl daemon-reload
8.修改root本地登陸密碼
1)鏈接mysql
shell> mysql -uroot -p
3)修改密碼
a、在mysql中該
mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY 'MyNewPass4!';
或者:
mysql> set password for 'root'@'localhost'=password('MyNewPass4!');
b、安裝後經過初始化該
shell# mysql_secure_installation #初始化
[root@linux-node2 ~]# rpm -vhi http://repo.zabbix.com/zabbix/3.0/rhel/7/x86_64/zabbix-release-3.0-1.el7.noarch.rpm
[root@linux-node2 ~]# yum install -y zabbix-server-mysql zabbix-web-mysql #系統會自動安裝php依賴
mysql> create database zabbix character set 'utf8';
mysql> grant all privileges on zabbix.* to 'zabbix'@'localhost' identified by 'zabbix'; #用戶名和密碼都是zabbix
mysql> flush privileges; #刷新受權
導入表
[root@server ~]# rpm -ql zabbix-server-mysql #查看zabbix-server-mysql包提供的文件
[root@server ~]# gzip -d/usr/share/doc/zabbix-server-mysql-3.0.28/create.sql.gz #使用這個文件生成咱們所須要的表
[root@server ~]# mysql -uzabbix -hlocalhost -pzabbix < create.sql #
[root@server ~]# mysql -uzabbix -hlocalhost -pzabbix < create.sql #直接把這個表導入至咱們的數據庫便可
進去數據庫查看一下:
localhost -pzabbix [root@server ~]# mysql -uzabbix -h
mysql> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | test | | zabbix | +--------------------+ mysql> use zabbix; Database changed mysql> show tables; +----------------------------+ | Tables_in_zabbix | +----------------------------+ | acknowledges | | actions | | alerts | …… | usrgrp | | valuemaps | +----------------------------+ 127 rows in set (0.00 sec)
能夠看出來,咱們的數據已經導入成功了。
修改server端的配置文件zabbix_server.conf
[root@server ~]# cd /etc/zabbix/ [root@server zabbix]# ls web zabbix_agentd.conf zabbix_agentd.d zabbix_server.conf [root@server zabbix]# cp zabbix_server.conf.bak #爲了方便咱們之後恢復,咱們把配置文件備份一下 [root@server zabbix]# vim zabbix_server.conf ListenPort=10051 #默認監聽端口 SourceIP=192.168.37.111 #發採樣數據請求的IP
[root@linux-node2 ~]# grep ^DB /etc/zabbix/zabbix_server.conf DBHost=localhost DBName=zabbix DBUser=zabbix DBPassword=zabbix
php_value max_execution_time 300 php_value memory_limit 128M php_value post_max_size 16M php_value upload_max_filesize 2M php_value max_input_time 300 php_value always_populate_raw_post_data -1 php_value date.timezone Asia/Shanghai
時區是必定要設置的,這裏的是能夠被註釋掉,由於咱們也能夠在php的配置文件中設置時區,若是咱們在php配置文件中設置時區,則對全部的php服務均有效,若是咱們在zabbix.conf
中設置時區,則僅對zabbix服務有效。因此,咱們去php配置文件中設置咱們的時區:
vim /etc/php.ini
[Date] ; Defines the default timezone used by the date functions ; http://php.net/date.timezone date.timezone = Asia/Shanghai
開啓服務:
[root@server zabbix]# systemctl start httpd #開啓web服務器 [root@server zabbix]# systemctl enable httpd #設置爲開機啓動
[root@server zabbix]# netstat -an |grep 80 #查看端口
[root@server zabbix]# systemctl start zabbix-server.service #開啓zabbix服務
[root@server zabbix]# systemctl enable zabbix-server.service #設置zabbix服務開啓啓動
[root@server zabbix]# systemctl enable zabbix-server.service #設置zabbix服務開啓啓動
[root@server zabbix]# ss -nutl |grep 10051 #查看端口
tcp LISTEN 0 128 *:10051 *:* tcp LISTEN 0 128 :::10051 :::*
咱們使用瀏覽器訪問192.168.37.111/zabbix
,第一次訪問時須要進行一些初始化的設置,咱們按照提示操做便可:
點擊Finish之後,咱們就會跳轉到登陸頁面,使用咱們的帳號密碼登陸便可:
默認用戶名爲:admin ,密碼爲:zabbix 。
登錄進來就能夠看到咱們的儀表盤了:
當咱們把監控端配置啓動之後,咱們須要來設置一下咱們的監控端,咱們在被監控的主機安裝好agent,設置好他的server,並把他添加到server端,就能將其歸入咱們的監控系統中去了。
[root@node1 ~]# yum install zabbix-agent
[root@node1 zabbix]# rpm -ql zabbix-agent #先查一下包內容
[root@node1 ~]# cd /etc/zabbix/
[root@node1 zabbix]# ls
zabbix_agentd.conf zabbix_agentd.d
[root@node1 zabbix]# cp zabbix_agentd.conf{,.bak} #備份配置文件
[root@node1 zabbix]# vim zabbix_agentd.conf
Server=192.168.37.111 #指明服務器是誰的 ListenPort=10050 #本身監聽的端口 ListenIP=0.0.0.0 #本身監聽的地址,0.0.0.0表示本機全部地址 StartAgents=3 #優化時使用的 ServerActive=192.168.37.111 #主動監控時的服務器 Hostname=node1.keer.com #本身能被server端識別的名稱 如果server和agernt在同一臺機器上則無需改。
[root@node1 zabbix]# systemctl start zabbix-agent.service #修改完後保存,啓動服務
[root@node1 zabbix]# ss -ntul |grep 10050 查看端口
已經開啓成功。咱們能夠去server端添加了。node2也進行一樣的操做,惟一不一樣的就是配置文件中的要設爲。tcp LISTEN 0 128 *:10050 *:*
Hostnamenode2.keer.com
按如上操做便可,選擇中文之後,點擊下面的update便可更新成功,一樣的,爲了安全起見,咱們把密碼改掉:
咱們先來定義一個主機羣組:
而後咱們就能夠去添加主機了:
設置完成後,點擊添加。咱們就能夠看到,咱們添加的這個主機已經出如今列表中了:
一樣的,咱們把node2節點也添加進來:
咱們點擊上圖中node1的監控項,便可建立咱們的監控項,首先,咱們建立三個應用集:
而後咱們來定義監控項:
任何一個被監控項,若是想要可以被監控,必定要在zabbix-server端定義了可以鏈接至zabbix-agent端,而且可以獲取命令。或者在agent端定義了可以讓server端獲取命令。通常都是內建的命令,都對應的有其名字,被咱們稱之爲key
。
設置完之後,點擊更新,便可加入,並會自動跳轉至下圖頁面:
定義完成,咱們回到全部主機,等待5秒,咱們能夠看到,咱們node1節點後面的選項已經有變成綠色的了:
咱們也能夠回到咱們的儀表盤,能夠看到,咱們的監控項有一個處於啓用狀態:
那麼,咱們的數據在哪裏呢?能夠點擊最新數據
,把咱們的node1節點添加至主機,應用一下,就能夠看到下面的狀態了:
能夠看到,咱們還有一個圖形頁面,點進去則能夠看圖形的分佈:
剛剛咱們定義的監控項是很簡單的,指定一個key
便可,可是有些監控項是帶有參數的,這樣一來,咱們的監控項就有更多的靈活性。接下來,咱們來簡單說明一個須要帶參數的監控項:
圖中的[]
就是須要參數的意思,裏面的值即爲參數,帶<>
爲不可省略的。咱們就以這個例子來講明:
if
表示是接口名;<mode>
表示是那種模式,包括但不限於:packets(包)、bytes(字節)、errors(錯誤)、dropped(丟包)、overuns等等(上述內容經過ifconfig
查看)
咱們來設置一下這個監控值:
咱們來看看網頁的顯示狀況:檢測中 ---> 最新數據 ---> Network Interface Stats(圖形)
能夠看一下,咱們如今已經定義的指標:
咱們來到 檢測中 ---> 最新數據,能夠看到,咱們定義的監控項都已經有值了:
當咱們的採集的值定義完了之後,就能夠來定義觸發器了。
咱們觸發器的定義是:界定某特定的item採集到的數據的非合理區間或非合理狀態。一般爲邏輯表達式。
邏輯表達式(閾值):一般用於定義數據的不合理區間,其結果以下:
OK
(不符合條件):正常狀態 --> 較老的zabbix版本,其爲FALSE;
PROBLEM
(符合條件):非正常狀態 --> 較老的zabbix版本,其爲TRUE;
通常,咱們評定採樣數值是否爲合理區間的比較穩妥的方法是——根據最後N次的平均值來斷定結果;這個最後N次一般有兩種定義方式:
並且,咱們的觸發器存在可調用的函數:
nodata() #是否採集到數據,採集不到則爲異常
last() #最近幾回的平均值
date()
time()
now()
dayofmonth()
...
注:能用數值保存的就不要使用字符串
基本的觸發器表達式格式以下所示
{<server>:<key>.<function>(<parameter>)}<operator><constant>
server
:主機名稱;key
:主機上關係的相應監控項的key;function
:評估採集到的數據是否在合理範圍內時所使用的函數,其評估過程能夠根據採起的數據、當前時間及其它因素進行;parameter
:函數參數;大多數數值函數能夠接受秒數爲其參數,而若是在數值參數以前使用「#」作爲前綴,則表示爲最近幾回的取值,如sum(300)表示300秒內全部取值之和,而sum(#10)則表示最近10次取值之和; 咱們能夠查看一下rate of packets(in)
的值,並以其爲標準肯定咱們的非正常的值:
圖中咱們能夠看出,咱們的最大值爲74,最小值爲4,平均值爲24。這樣的話,咱們能夠定義50以上的都是非正常的值。
下面咱們來定義一個觸發器:
進入:配置 ---> 主機 ---> node1 ---> 觸發器 ---> 建立觸發器
咱們的表達式能夠直接點擊右側的添加,而後定義本身所需的內容,便可自動生成:
生成完畢後,咱們就點擊頁面下方的添加,即成功定義了一個觸發器,同時頁面自動跳轉:
而後咱們去看一下咱們剛剛定義了觸發器的那個監控項:
咱們能夠看出,這個裏面就有了一根線,就是咱們剛剛定義的值,超過線的即爲異常狀態,看起來很是直觀。
可是,如今即便超過了這根線,也僅僅會產生一個觸發器事件而不會作其餘任何事。所以,咱們就須要去定義一個動做(action)。
咱們的觸發器彼此之間可能會存在依賴關係的,一旦某一個觸發器被觸發了,那麼依賴這個觸發器的其他觸發器都不須要再報警。
咱們能夠來試想一下這樣的場景:
咱們的多臺主機是經過交換機的網絡鏈接線來實現被監控的。若是交換機出了故障,咱們的主機天然也沒法繼續被監控,若是此時,咱們的全部主機通通報警……想一想也是一件很可怕的事情。要解決這樣的問題,就是定義觸發器之間的依賴關係,當交換機掛掉,只它本身報警就能夠了,其他的主機就不須要在報警了。這樣,也更易於咱們判斷真正故障所在。
注意:目前zabbix不可以直接定義主機間的依賴關係,其依賴關係僅能經過觸發器來定義。
咱們來簡單舉一個例子,示範一下如何定義一個依賴關係:
打開任意一個觸發器,上面就有依賴關係,咱們進行定義便可:
因爲當前咱們只定義了一個觸發器,就不演示了,過程就是這樣~添加之後點擊更新便可。
觸發器能夠有多級依賴關係,好比咱們看下面的例子:
咱們須要去基於一個對應的事件爲條件來指明該作什麼事,通常就是執行遠程命令或者發警報。
咱們有一個告警升級的機制,因此,當發現問題的時候,咱們通常是先執行一個遠程操做命令,若是可以解決問題,就會發一個恢復操做的訊息給接收人,若是問題依然存在,則會執行發警報的操做,通常默認的警報接收人是當前系統中有的zabbix用戶,因此當有人須要收到警報操做的話,咱們則須要把它加入咱們的定義之中。
其次,每個用戶也應該有一個接收告警信息的方式,即媒介,就像咱們接收短信是須要有手機號的同樣。
咱們的每個監控主機,可以傳播告警信息的媒介有不少種,就算咱們的每一種大的媒介,可以定義出來的實施媒介也有不少種。而對於一個媒介來講,每個用戶都有一個統一的或者不一樣的接收告警信息的端點,咱們稱之爲目標地或者目的地。
綜上,爲了可以發告警信息,第一,咱們要事先定義一個媒介,第二,還要定義這個媒介上用戶接收消息的端點(固然,在用戶上,咱們也稱之爲用戶的媒介)。
咱們能夠去看一下系統內建的媒介類型:
這只是大的媒介類型,裏面還有更多的細分,咱們以Email
爲例:
一樣的,同一個類型咱們也能夠定義多個,仍是以Email
爲例,咱們能夠定義一個騰訊的服務器,一個網易的服務器,一個阿里的服務器等等。
咱們仍是以Email
爲例。來簡單的定義一個媒介:
這樣定義之後,咱們去更新一下就能夠了。
媒介定義好了,那麼咱們怎麼纔可以而後用戶接收到郵件呢?好比讓咱們的Admin用戶接收郵件,咱們應該怎麼操做呢?具體步驟以下:
進入 管理 ---> 用戶 ---> Admin ---> 報警媒介
咱們來添加一條進來:
添加事後是這樣的:
而後咱們更新就能夠了。
一個用戶能夠添加多個接收的媒介類型。
咱們以前說過了,動做是在某些特定條件下觸發的,好比,某個觸發器被觸發了,就會觸發咱們的動做。
如今,我麼基於redis來定義一個動做。
首先,咱們在agent端使用yum安裝一下redis
:
[root@node1 ~]# yum install redis -y
修改一下配置文件:
[root@node1 ~]# vim /etc/redis.conf bind 0.0.0.0 #不作任何認證操做
修改完成之後,咱們啓動服務,並檢查端口:
[root@node1 ~]# systemctl start redis [root@node1 ~]# ss -nutlp | grep redis tcp LISTEN 0 128 *:6379 *:* users:(("redis-server",pid=5250,fd=4))
接着,咱們就能夠去網站上來定義相關的操做了:
進入 配置 ---> 主機 ---> node1 ---> 監控項(items)---> 建立監控項
填寫完畢之後,咱們點擊下方的添加。
該監控項已成功添加。
咱們能夠去查看一下他的值:
檢測中 ---> 最新數據
定義好了監控項之後,咱們亦可來定義一個觸發器,當服務有問題的時候,咱們才能及時知道:
進入 配置 ---> 主機 ---> node1 ---> 觸發器(trigger)---> 建立觸發器
填寫完畢之後,咱們點擊下方的添加。
該觸發器已成功添加。
咱們去查看一下:
監測中 ---> 最新數據
咱們來手動關閉redis服務來檢測一下:
[root@node1 ~]# systemctl stop redis.service
進入 監測中 ---> 問題
能夠看到,如今已經顯示的是問題了。而且有持續的時間,當咱們的服務被打開,會轉爲已解決狀態:
[root@node1 ~]# systemctl start redis.service
如今咱們就能夠去定義action了。
進入 配置 ---> 動做 ---> 建立動做(注意選擇事件源爲觸發器)
咱們能夠進行操做添加:
咱們能夠看出,還須要在虛擬機上進行兩項操做,一是修改sudo配置文件使zabbix用戶可以臨時擁有管理員權限;二是修改zabbix配置文件使其容許接收遠程命令。咱們進行以下操做:
[root@node1 ~]# visudo #至關於「vim /etc/sudoers」 ## Allow root to run any commands anywhere root ALL=(ALL) ALL zabbix ALL=(ALL) NOPASSWD: ALL #添加的一行,表示不須要輸入密碼 [root@node1 ~]# vim /etc/zabbix/zabbix_agentd.conf EnableRemoteCommands=1 #容許接收遠程命令 LogRemoteCommands=1 #把接收的遠程命令記入日誌 [root@node1 ~]# systemctl restart zabbix-agent.service
咱們添加了第一步須要作的事情,也就是重啓服務,若是重啓不成功怎麼辦呢?咱們就須要來添加第二步:
添加完成之後,咱們能夠看一下:
操做添加完了,若是服務自動恢復了,咱們能夠發送消息來提示:
至此,咱們的動做設置完畢,能夠點擊添加了,添加完成會自動跳轉至以下頁面:
如今咱們能夠手動中止服務來進行測試:
[root@node1 ~]# systemctl stop redis.service
而後咱們來到問題頁面來查看,發現確實有問題,而且已經解決:
咱們能夠去server端查看是否收到郵件:
也能夠去agent端查看端口是否開啓:
[root@node1 ~]# systemctl stop redis.service [root@node1 ~]# ss -ntl State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 *:6379 *:* LISTEN 0 128 *:111 *:* LISTEN 0 5 192.168.122.1:53 *:* LISTEN 0 128 *:22 *:* LISTEN 0 128 127.0.0.1:631 *:* LISTEN 0 128 *:23000 *:* LISTEN 0 100 127.0.0.1:25 *:* LISTEN 0 128 *:10050 *:* LISTEN 0 128 :::111 :::* LISTEN 0 128 :::22 :::* LISTEN 0 128 ::1:631 :::* LISTEN 0 100 ::1:25 :::*
能夠看出端口正常開啓,咱們的動做觸發已經完成。
補充:咱們也可使用腳原本發送警報,咱們的腳本存放路徑在配置文件中能夠找到,定義爲:
AlterScriptsPath=/usr/lib/zabbix/alertscripts
接下來,咱們來一波完全一點的操做,咱們來手動修改一下redis服務的監聽端口,這樣,咱們就不能經過重啓服務恢復了:
[root@node1 ~]# vim /etc/redis.conf #port 6379 port 6380 #註釋掉原來的端口,更換爲新的端口 [root@node1 ~]# systemctl restart redis
而後,咱們來網頁查看一下狀態:
進入 監測中 ---> 問題,能夠看到是報錯的:
這樣,在通過了重啓服務之後仍是沒能把解決問題,就會發郵件告警:
咱們再把服務端口改回來,而後重啓服務。這樣,等到問題自動解決了之後,咱們會再次收到郵件:
這樣,咱們的動做設定已經所有測試完成。
數據日積月累,若是咱們想要更直觀的瞭解到各項數據的狀況,圖形無疑是咱們的最佳選擇。
zabbix提示了衆多的可視化工具提供直觀展現,如graph、screen及map等。上文中咱們也看到過一些簡單的圖形展現。
若是咱們想要把多個相關的數據定義在同一張圖上去查看,就須要去自定義圖形了~
自定義圖形中能夠集中展現多個時間序列的數據流。支持「線狀圖(normal)」、「堆疊面積圖(stacked)」、「餅圖(pie)」 和「分離型餅圖(exploded)」四種不一樣形式的圖形。
具體的設置過程以下:
進入 配置 ---> 主機 ---> node1 ---> 圖形,選擇右上角建立圖形:
咱們來看一看四種狀態:
包括咱們的主機均可以自定義,不過通常來講,線型是看的最清晰的,咱們一般會使用這個。
咱們也能夠克隆一個packets來更改成bytes用~一樣的,咱們若是想添加別的內容,也均可以添加的。
咱們一共添加了三個圖形,咱們能夠在 監測中 ---> 圖形 來查看
咱們建立的自定義圖形也能夠放在一個聚合圖裏顯示,具體的設置方法以下:
進入 監測中 ---> 聚合圖形 ---> 選擇右上角建立聚合圖形
咱們還能夠選擇分享:
定義好了添加便可。
定義完成之後,咱們須要編輯一下,來指定保存哪些圖:
依次添加便可,添加完成以後是這樣嬸兒的~:
由於咱們只有三張圖,因此添加的有重複的,一般狀況下是不須要這樣的。
若是咱們有多個聚合圖形想要按順序展現的話,咱們就能夠定義一個幻燈片。
具體步驟以下:
進入 監測中 ---> 聚合圖形 ---> 右上角選擇幻燈片演示 ---> 建立幻燈片
而後咱們打開便可。打開之後顯示的是圖片1,5s之後會自動切換爲圖片2。
這樣就能夠實現幻燈片演示,咱們就不須要去手動切換了。
在拓撲圖中,咱們能夠定義成一個複雜的網絡鏈接圖,咱們可使用一臺主機來鏈接另外一臺主機,這樣的話,咱們就能夠查看出究竟是哪一個連接出了問題。
咱們就不來演示了,看一下過程便可:
進入 監測中 ---> 拓撲圖 ---> 全部地圖 ---> Local network(默認就有的)
經過 Ping 和 Traceroute 就能夠實驗咱們上述的功能。
以前咱們說過,每個主機的監控項都不少,咱們一個一個的添加實在是太頭疼了,更況且,可能不止一個主機。
可是咱們能夠把一個redis的監控項添加進一個模板裏,這樣更方便於咱們之後的添加。
具體操做以下:
進入 配置 ---> 模板 ---> 選擇右上角建立模板
填寫完之後,咱們點擊下方的添加便可。
咱們能夠基於組過濾一下,就能看到咱們剛剛定義的模板:
同樣的,咱們能夠向裏面添加應用集、監控項、觸發器、圖形等等,添加完成之後,後期咱們再有主機須要添加就直接套用模板便可。
須要注意的一點是,咱們如今添加的是模板,因此不會當即採用數據,只有連接到主機上之後,纔會真正生效。
咱們也能夠直接導入一個模板,在互聯網上能夠找到不少,導入的步驟以下:
一樣的,咱們建立好的模板也能夠導出爲文件:
咱們任意選中一個準備好的模板,而後頁面的最下方就有導出按鈕:
所以,咱們就能夠很是方便的進行應用了~
咱們的軟件已經建立了許多模板,咱們可使用一個模板來看看效果。
進入 配置 ---> 主機 ---> node1 ---> 模板
咱們就能夠選擇要添加的模板了:
到這裏咱們就能夠點擊更新了。一旦咱們成功連接至模板,咱們的主機數據就會更新了:
注意:一、一個主機能夠連接多個模板,但儘可能不要讓一個指標被採樣兩次。
二、若是咱們有多個主機,同時這些主機也在一個主機組裏,這樣的話,咱們只須要在這個主機組裏添加模板,就可以讓在主機組裏的全部主機進行tongb
當咱們一個主機的模板不想要用了,咱們就能夠移除模板連接,具體操做步驟以下:
進入 配置 ---> 主機 ---> node1 ---> 模板
咱們就能夠把不須要的模板移除:
咱們來刪除掉試試看,移除並清理之後,咱們點擊更新。就會自動跳轉至以下界面:
能夠看出,咱們的模板已經被移除了。
宏是一種抽象(Abstraction),它根據一系列預約義的規則替換必定的文本模式,而解釋器或編譯器在遇到宏時會自動進行這一模式替換。
相似地,zabbix基於宏保存預設文本模式,而且在調用時將其替換爲其中的文本。
zabbix有許多內置的宏,如{HOST.NAME}、{HOST.IP}、{TRIGGER.DESCRIPTION}、{TRIGGER.NAME}、{TRIGGER.EVENTS.ACK}等。
詳細信息請參考官方文檔
宏一共有三種級別,分別是全局宏、模板宏、主機宏。
不一樣級別的宏的適用範圍也不同。
全局宏也能夠做用於全部的模板宏和主機宏,優先級最低。
模板宏則能夠做用於全部使用該模板的主機,優先級排在中間。
主機宏則只對單個主機有效,優先級最高。
宏的類型分爲系統內建的宏和用戶自定義的宏。
爲了更強的靈活性,zabbix還支持在全局、模板或主機級別使用用戶自定義宏(user macro)。
系統內建的宏在使用的時候須要{MACRO}
的語法格式,用戶自定義宏要使用{$MACRO}
這種特殊的語法格式。
宏能夠應用在item keys和descriptions、trigger名稱和表達式、主機接口IP/DNS及端口、discovery機制的SNMP協議的相關信息中……
宏的名稱只能使用大寫字母、數字及下劃線。
進一步信息請參考官方文檔。
若是咱們想要在咱們的監控項(items)上使用宏,咱們就要先去定義一個宏,而後去建立監控項,直接引用定義好的宏便可。具體操做步驟以下:
進入 管理 ---> 通常 ---> 右上角選擇宏
這樣,咱們的全局宏就添加好了。
進入 配置 ---> 主機 ---> 全部主機 ---> 監控項 ---> 右上角建立監控項
填寫完成之後,點擊添加。而後咱們就能夠看到這個調用宏的監控項已經添加成功:
咱們能夠來查看一下這個監控項如今的狀態:
進入 監測中 ---> 最新數據
若是咱們把服務停掉。就會變成down
的狀態:
[root@node1 ~]# systemctl stop redis
發現咱們的監控項是能夠正常使用的。
若是咱們把node1節點上的redis服務監聽端口手動改掉的話,咱們剛剛定義的監控項就不能正常使用了,這樣的話,咱們就須要去修改宏。
可是,這畢竟只是個例,因此咱們不須要去修改全局宏,只用修改模板宏或者主機宏就能夠了。
下面分別說一下,模板宏和主機宏的不一樣修改操做:
模板宏
模板宏的修改,咱們須要進入:配置 ---> 模板 ---> redis stats(相應的模板) ---> 宏
在這裏點擊添加就能夠了。
主機宏
主機宏的修改,咱們須要進入:配置 ---> 主機 ---> 全部主機 ---> node1 ---> 宏
在這裏點擊添加就能夠了。