企业级监控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界面上去更改

定义宏