柴少的官方网站-zabbix之自动发现、注册和action（五）

2017年07月28日 14:01:59

zabbix之自动发现、注册和action（五）

一、主机的自动添加

随着主机数量的增多，一台台添加肯定不合适，要么对zabbix的表结构很熟悉，通过操纵mysql表数据来完成主机的动态增加，要么通过zabbix api调用传送json数据来是实现zabbix的主机自动增加，这些都比较高级复杂点，zabbix的自动发现（Discovery）功能，也能很好的解决这个问题。

官网参考链接：https://www.zabbix.com/documentation/3.2/manual/discovery

1.1 自动发现规则的创建（网络发现）

图片.png

下面是参数解释：

Name：规则的惟一名称。例如“Local network”
Discovery by proxy：通过什么来执行发现，是没有代理还是通过代理proxy来执行发现
IP range：用于发现的IP地址范围。 它可能有以下格式：单IP：192.168.1.33、IP地址范围：192.168.1-10.1-255。、IP掩码：192.168.4.0/24、列表：192.168.1.1-255,192.168.2.1-100,192.168.2.200,192.168.4.0/24
Delay (in sec)：此参数定义Zabbix执行规则的频率。在先前发现实例的执行结束之后测量延迟，因此没有重叠。默认是3600秒即一小时发现一次。
Checks：Zabbix将使用此列表进行发现。支持的检查：SSH，LDAP，SMTP，FTP，HTTP，HTTPS，POP，NNTP，IMAP，TCP，Telnet，Zabbix代理，SNMPv1代理，SNMPv2代理，SNMPv3代理，ICMP ping。
Device uniqueness criteria：设备唯一的名称。IP地址 - 不处理多个单IP设备。 如果具有相同IP的设备已经存在，则会被认为已经被发现，并且不会添加新的主机。发现类型检查 - SNMP或Zabbix代理检查。
Enabled：发现规则是否是启用状态。

客户端的配置

# vim /etc/zabbix/zabbix_agentd.conf

Server=192.168.1.103    #在Server这里指定下服务器的IP地址

图片.png

#上图是在服务器上面查看发现的主机IP地址。

博文来自：www.51niux.com

创建action动作

图片.png

#注意上面哪个uptime时间并不是机器本身运行存活的时间，而是被发现存活的时间，如我们新发现了一台机器并不立马执行操作，要等到其值为10分钟的时候才会操作，如下图：

图片.png

#从上图可以看到只是发现了设备，已检测的主机那里还是空的，说明还没有把这个主机添加到监控里面，要等到它符合了条件才会添加到监控里面去。

下面是条件已经满足之后要执行的操作：

图片.png

下面是可以操作的项：

图片.png

Sending notifications   #发送通知
Adding/removing hosts   #增加/移除监控设备
Enabling/disabling hosts  #开启/关闭监控设备
Adding hosts to a group   #增加一个监控设备到组
Linking hosts to/unlinking from a template  #（取消）链接设备到一个模板
Executing remote scripts    #执行远程脚本

最后看一下自动发现后添加主机的效果：

图片.png

1.2 主动注册

主动注册（agent auto-registration）功能主要用于Agent主动且自动向Server注册。与前面的Network discovery具有同样的功能，但是这个功能更适用于特定的环境，当一个条件未知（如agent端的IP地址段、agentg端的操作系统版本等信息）时，Agent去请求Server仍然可以实现自动添加监控的功能。比如云环境下的监控，云环境中，IP分配就是随机的，这个功能就可以很好的解决类似的问题，如果云主机要加到zabbix监控里面来的话。

使用Host metadata注册形式

Host metadata是zabbix 2.2新增加的功能，该功能在zabbix-agent端可以自定义条件，在选择自动注册的时候，zabbix-server端可以根据Host metadata来选择条件，从而实现更多的条件筛选。

客户端的操作：

# vim /etc/zabbix/zabbix_agentd.conf

Server=192.168.1.103
ListenPort=10050
ListenIP=192.168.1.102
ServerActive=192.168.1.103    #这里主动模式下zabbix服务器的地址
Hostname=zwidc_web_192.168.1.102.test  
HostMetadata=linux zabbixtest.youshi   #这里其实就是类似于snmp的那个public口令一样，这里设置了两个元数据，一个是告诉自己是linux服务器另一个就是写一个通用的带有公司标识的字符串

#自动注册和自动发现对于自动创建主机的时候，主机名的区别：

#如上面的Hostname=zwidc_web_192.168.1.102.test，我们想自动注册的动作所创建的主机名的名称是zwidc_web_192.168.1.102.test而非192.168.1.102，因为我们最终集群是要变成客户端主动发送数据给proxy端，然后proxy端主动提交数据到服务端，所以如果我们想让主机自动创建的时候是这种带有机房标识的方式，就要选择自动注册的形式，自动发现zabbix服务端自动添加主机的名称是IP，因为主动默认主机名不对称就会提交不了数据了。

#然后再自动注册动作那里除了选择元数据以外，还要选择proxy代理，这样如果是多机房的话，在添加主机的时候就会给它分配好对应机房的proxy代理。

服务器的操作：

图片.png

下面查看下效果：

图片.png

1.3 关于交换机的自动发现：

交换机型号有很多种，思科的、华为的、H3C的，不同的交换机OID是不一样的，做模板的时候就得做不同交换机的模板，并且自动发现这里是可以选择SNMP然后根据你的写的SNMP community和SNMP OID做判断的，这里做自动发现不能再OID这里做想法，要在SNMP community做想法（当然可以设置多条snmp发现规则这个确实是有用的，但是action那里的判断就不好做了，所以自动发现这里还是要一个厂商的交换机一个自动发现，如果你交换机并不单一的话），不同厂商的交换机SNMP community不同，通用的OID就用.1.3.6.1.2.1.1.5（交换机名称，这个是通用的，如果只是想是交换机就发现而不分类的话），然后动作那里它那里的判断是指望不上的，所以判断一个交换机的厂商的重任就要交到自动发现这里了，然后action那里根据选择自动发现的规则来进行相应的操作如关联对应的模板啊。当然如果交换机比较少的话，还是手工添加主机吧。

自动发现规则如下图：

#上图的意思就是找一个只有这个品牌独有的OID值，别的品牌的交换机用这个OID值取不到值，取不到值就不会被匹配了。

动作如下图：

#不同的发现规则就定义不同的动作，同理可以再顶一个思科交换机的发现规则，再定义一个思科交换机的动作，然后因为交换机之间的OID值不同，以及各种值呈现规则的不同，就可以让其套用匹配的模板。

博文来自：www.51niux.com

二、Low level discovery功能

官网链接：https://www.zabbix.com/documentation/3.2/manual/discovery/low_level_discovery

2.1 Low level发现功能介绍

很强大的一个功能，如果你仔细参考其他模板的话，会发现已经用到了此功能，比如网卡名称不一致的情况，多硬盘的情况。

在配置Items的过程中，有时需要对类似的Items镜像添加，这些Items具有一些共同的特性，表现为某些特定的参数是变量，而其他设置都是一样的。例如，一个程序有多个端口，需要对端口配置Items。又比如，磁盘分区、网卡名称等存在着不确定性，所以这些配置固定的items会出现无法通用的问题，因而在zabbix 2.0以后的版本中增加了Low level discovery功能。

这个功能都对哪些支持呢：

发现文件系统
发现网络接口
发现和CPU内核的CPU
SNMP oid的发现
发现使用ODBC SQL查询
发现Windows服务
用户可以自定义自己的类型的发现，他们遵循一个特定的JSON提供协议。

2.2 Low level discovery的使用过程

使用过程分为两步：

自动发现特定变量的名称
添加对变量的Items

zabbix中Low level discovery的Key返回值是一个JSON格式（如果是自定义的规则，可以通过网站验证获取到的值是否为正确的JSON格式数据）自带的Key，如下：

vfs.fs.discovery   #适用于zabbix agent监控方式
snmp.discovery     #SNMP agent监控方式
net.if.discovery   #适用于zabbix agent监控方式
system.cpu.discovery  #适用于zabbix agent监控方式

#可以用zabbix-get来查看key获取的数据，对于snmp,不能通过zabbix-get来验证，只能在web页面中进行配置使用。

如下面zabbix-get的例子：

# /usr/local/zabbix/bin/zabbix_get -s 192.168.1.106 -k net.if.discovery

{"data":[{"{#IFNAME}":"eno16777736"},{"{#IFNAME}":"lo"}]}

#上面就是格式，一个字典的形式，data就是数据，下面一个宏{#IFNAME}是LLD宏名称表示一个网卡eno16777736,另一个网卡是lo

#还有虚拟机发现关键字字段：https://www.zabbix.com/documentation/3.2/manual/vm_monitoring/discovery_fields

2.3 正则表达式

zabbix正则表达式的介绍：

还得要了解下正则表达式，不然的话这个Low level discovery功能也用不起来。

POSIX扩展正则表达式对zabbix的支持：https://en.wikipedia.org/wiki/Regular_expression#POSIX_extended #正则表达式我们已经不陌生了

在zabbix里面使用正则表达式的方式一种就是手动输入一个正则表达式，一个就是使用全局正则表达式zabbix中创建的正则表达式。

如果要引用正则表达式，可以再全局那里定义好，然后引用的话直接@引用就可以了，当然也可以直接在要输入正则正则表达式的地方直接手工输入。

zabbix正则表达式全局的定义：

图片.png

下面是上图参数介绍：

Name（名称）  #设置正则表达式的名字。 Unicode字符是允许的。
Expressions（表达式）  #点击添加可以创建新的表达式
Expression type（表达式类型）  #选择表达式类型:  Character string included（字符串已包含）：匹配字符串，Any character string included（包含任何字符串）：匹配任何子字符串从一个以逗号分隔的列表，
#Character string not included（字符串未包含）：除了子字符串匹配任何字符串，Result is TRUE（结果为真）：与正则表达式相匹配，Result is FALSE（结果是假的）：不匹配正则表达式
Expression（表达式）：输入子字符串或正则表达式。

2.4 Low level discovery与正则表达式结合

我们先来看一下zabbix自带模板里面是怎么结合的：

图片.png

#再看一下监控项原型，就跟items里面的定义一样的，就是里面有个{#FSNAME}LLD宏引用。那么{#FSNAME}和上上图的{#FSTYPE}怎么来的呢？看下图的取值的部分内容：

# /usr/local/zabbix/bin/zabbix_get -s 192.168.1.106 -k "vfs.fs.discovery"

{"data":[{"{#FSNAME}":"/","{#FSTYPE}":"rootfs"},{"{#FSNAME}":"/sys","{#FSTYPE}":"sysfs"},

#剩下的自己点开看看大概流程就清楚了。

2.5 自定义发现规则

我们来用一个自定义的规则操作的整个过程来捋顺一下这个流程。zabbix自带的这个系统发现规则并不是很好，因为会将/boot等一些没必要的搞出来，我想自己定一个符合我实际场景的。

首先客户端的操作：

# vim /etc/zabbix/zabbix_agentd.conf

EnableRemoteCommands=0   #不允许在本地执行远程命令
Include=/etc/zabbix/zabbix_agentd.conf.d/
UnsafeUserParameters=1   #允许特殊字符

#mkdir /etc/zabbix/scripts/

# cat /etc/zabbix/scripts/disk_partition #用shell写了一个自动发现的脚本

#!/bin/bash
Disk_Site_discovery () {
   Disk_Site=`lsblk  -l|awk {'print $NF'}|grep -v "[A-Z]"|grep  "^/"|grep -v boot`
   Disk_Site_Num=`echo  ${Disk_Site}|awk {'print NF'}`
   Disk_Site_partition=($Disk_Site)
   printf '{\n'
   printf '\t"data":[\n'
   for((i=0;i<${Disk_Site_Num};i++))
   {
     if [ `expr $i + 1 ` != ${Disk_Site_Num} ];then   #因为最后一个数据是没有逗号的所以要判断
       printf "\t{\"{#SITENAME}\":\"${Disk_Site_partition[$i]}\"},\n"
     else
       printf "\t{\"{#SITENAME}\":\"${Disk_Site_partition[$i]}\"}\n"
     fi
   }
   printf '\t]\n'
   printf '}\n'
}
case "$1" in
disk_site_discovery)
   Disk_Site_discovery
;;
*)
echo "Usage:$0 disk_site_discovery"
;;
esac

# chmod +x /etc/zabbix/scripts/disk_partition

# cat /etc/zabbix/zabbix_agentd.conf.d/disk_site_discovery.conf #自定义key文件

UserParameter=disk.site.discovery,/etc/zabbix/scripts/disk_partition  disk_site_discovery #这就相当于定义了一个自定义的key：disk.site.discovery，逗号后面就是允许的自定义脚本，disk_site_discovery就是传给脚本的$1

然后是服务端的操作：

首先看能不能获取到自定义key值：

# /usr/local/zabbix/bin/zabbix_get -s 192.168.1.106 -k disk.site.discovery #先来看下能取到值吗

{   #主要要的就是这种json格式，这里将一个系统中根分区和挂载目录都取出来了，哪些/boot啊以及/分区下的/proc啊就不要了
    "data":[
    {"{#SITENAME}":"/"},
    {"{#SITENAME}":"/data01"},
    {"{#SITENAME}":"/data02"}
    ]
}

#注意，json格式最后一个数据是没有逗号的，不然添加完zabbix会有报错：Value should be a JSON object.

然后我们要顶一个全局的正则表达式：

图片.png

#首先因为之前我们已经创建了对根分区的items，所以这时候如果我们不进行排除的话，就会报错提示你/分区的items已经存在了，然后为了要定义全局的，因为自动发现规则那里手工定义的条件只能为真，也许是我匹配的方式不对

然后为一个主机添加自定义的规则：

图片.png

#上图中的参数介绍：

Name : 发现规则名称
Type : 执行发现的检查类型; 应该是Zabbix代理或Zabbix代理（活动）文件系统发现。
Key  ：键，主要是为了返回一个JSON
Update interval (in sec) ： 此字段指定Zabbix执行发现的频率。 一开始，当您只是设置文件系统发现时，您可能希望将其设置为一小段时间，但一旦知道它可以将其设置为30分钟或更长时间，因为文件系统通常不会更改。
#注意：如果设置为“0”，则不会轮询该项。 但是，如果灵活间隔也存在非零值，则在灵活间隔持续时间内将轮询该项。
Custom intervals ：您可以创建用于检查项目的自定义规则：灵活 - 创建更新间隔的异常（不同频率的间隔）计划 - 创建自定义轮询时间表。
Keep lost resources period (in days) ： 该字段允许您指定发现的实体将被发现状态变为“不再发现”（最多3650天）后将被保留（不会被删除）的天数。注意：如果设置为“0”，将立即删除实体。 不建议使用“0”，因为只有错误地编辑过滤器才能在所有历史数据中被删除的实体中出现。
Description ：描述信息
Enabled ： 是否启用

图片.png

#通过这个过滤器我们就将/分区给排除掉了，这样也就不会报错了，不然会提示你/分区已经存在。

然后我们再来添加一个监控项原型：

监控项原型也就是items，不过它会根据你{#SITENAME}的多少，创建同等数量的items。

图片.png

#从上图可以看出所有的框都跟items的参数是一个意思的，主要是键值那里，将{#SITENAME}这个自定义的lld宏变量引入了进去。这个键的意思就是采集我们自定义多挂载目录的剩余空间。

下面我们从最新数据里面查看下效果：

图片.png

#从图中可以看出，items里面自动多了两个分区的items，而且跟/分区是并存的，并且也可以采集到值。

最后来加一下触发器：

如果是图形化添加的话，下面的截图表明的地方要注意了：

图片.png

#下面是我们一个简单的触发器定义：

图片.png

现在让我们看看触发器添加的效果：

图片.png

#那现在有一个疑问，你看我是取到值了，所以会创建对应的分区，如果我取到的是一个空值呢，也就是说我这个系统就一个根分区，没有其他的分区，加载了这个自动发现规则会不会报错呢？

#答案是不会报错，空值的话就不会产生任何的items信息，就算你加了监控项原型。所以这个自动发现规则在多分区和就一个根分区情况下都是可以使用的，所以这种做到模板里面最好，这样如果是多盘的话也不用手工搞了。

#这样你的盘的动态增加和减少，对应的items和触发器也会跟着动态的增加和减少，因为是根据你客户端的取值来的嘛。比如你可以找一台机器一开始没挂载盘，然后都监控起来之后默默的挂载一块盘试一试。

#模板就应该具有通用性，所以前面就不应该加根分区的监控，这里就可以直接都监控上了，或者这里脚本再改改，将非/去掉，这样就不用再去写一个全局宏变量了，不过还是前者好一点，系统分区直接从一个宏变量里面获得。

#这样我们的网卡检测（不管是双网卡还是四个网卡，不管名称是em,eth还是光纤网卡的p2p,p1p，还是Centos7系统自定义的网卡名称等）都可以自动发现并监控起来，或者CPU其他的什么。

#前面提到过的web检测，没检测一个url都要在web页面操作，如果是大批量的web页面的url的200状态检测呢，显然用这种取lld宏变量的形式更好一点，就照着上面自定义脚本的意思，搞两个自定义键，输出两个值，一个是要检测的url,一个是检测的code状态，然后就是照着上面的json格式输出。我就先不写了，意思一样。下面是一个参考链接。

web url监控参考链接：http://itnihao.blog.51cto.com/1741976/1129725

#那么不管是多网卡还是单网卡的简单发现脚本就是：#cat /etc/zabbix/scripts/net_discovery

#!/bin/bash
Net_Site_discovery () {
   Net_Site=`ip addr|grep 'state UP'|awk -F "[: ]" {'print $3'}`
   Net_Site_Num=`echo  ${Net_Site}|awk {'print NF'}`
   Net_Site_partition=($Net_Site)
   printf '{\n'
   printf '\t"data":[\n'
   for((i=0;i<${Net_Site_Num};i++))
   {
     if [ `expr $i + 1 ` != ${Net_Site_Num} ];then
       printf "\t{\"{#SITENAME}\":\"${Net_Site_partition[$i]}\"},\n"
     else
       printf "\t{\"{#SITENAME}\":\"${Net_Site_partition[$i]}\"}\n"
     fi
   }
   printf '\t]\n'
   printf '}\n'
}
case "$1" in
net_site_discovery)
   Net_Site_discovery
;;
*)
echo "Usage:$0 net_site_discovery"
;;
esac

注：关于DNS反向解析的问题（如内网的IP地址都给反向解析成bogon）

内网做zabbix网络自动发现的时候，发现的主机都是bogon命名的方式

图片.png

然后改成自动注册，主机确实按照我定义的Hostname里面生成了对应的主机名称，但是DNS名称那里还是bogon。

$RA{MQ%G$L43~D(C4J$F[I_V.png$

在ganglia:http://blog.51niux.com/?id=85 也遇到过，不过那是公网形式的，这次是内网，bogon就是内网反向解析的结果，意思是一个未公开的网址，就是代表是私网的意思。

临时的解决办法还是：我这里是通过zabbix_proxy的形式，所以是在proxy的/etc/hosts那里，把整个内网IP网段都输入，然后对应的解析域名为空，类似于192.168.1.110 #IP后面是空，临时解决但是不知道彻底解决方法。

2.6 线上小例子：

怎么自动发现网卡之后让网络流量向cacti一样将流入和流出都放一张图上面？

图片.png

添加一个图形原型：

图片.png

#注意这里点击预览是没有数据的，但是可以看添加完之后的显示格式效果之类的。

查看流量图效果：

检测中==>图形

图片.png

#可以看到在图形这里出现了两个网卡。

图片.png

#从上图中可以看出，已经出现了cacti流量的效果图，在图片的头部还会显示主机名称和网卡名称这里就不截了。

再比如做个磁盘总量、使用量和空闲空间的图，一眼就能很清晰的看出来什么情况

图片.png

添加图形原型：

图片.png

查看效果：

检测==》图形

图片.png

#从这里可以看出多了很多图形

图片.png

#这里我选择了一个SSD的/data数据盘来演示效果，可以很直观的看到磁盘使用量和空闲的对比，也可以通过右上角的数据来查看实际的使用量和使用率。

三、action邮件报警

在上面的记录中已经多次提到了action，并使用action做了相应的动作，那么监控的重点是当问题出现时候能将报警通知到相关的人员，下来我们就来让报警触发并能通知到联系人。

3.1 创建收件人

报警邮件通知谁啊，需要定义啊，是单个人还是一个组，当然一般情况下都是创建了人然后归纳到对应的组里面。

用户组创建

官网链接：https://www.zabbix.com/documentation/3.2/manual/config/users_and_usergroups/usergroup

用户组允许用于组织和集团用户分配权限数据。主机的权限监控数据组分配给用户组,而不是个人用户。往往可能意义区分哪些信息是用于一组用户和——另一个。这可以通过将用户分组,然后分配不同的权限组。一个用户可以属于任何数量的组。

配置一个用户组：

图片.png

#这里就直接到用户组的创建界面了啊，创建一个运维组，下面是关于此界面的参数介绍：

Group name ： 组名称
Users      :  此组包含了哪些用户
Frontend access ： 如何验证的用户组。系统默认值——使用默认的认证，内部——使用Zabbix身份验证。 忽略了如果HTTP身份验证设置，禁用——访问ZabbixGUI是被禁止的
Enabled    ： 启用此用户组
Debug mode ：标记此复选框为用户激活调试模式。

下面是关于用户组权限的设置：

图片.png

创建用户：

先添加用户的信息：

图片.png

#上图中的参数所对应的意思：

Alias ： 独特的用户名作为登录名。
Name  ： 用户名(可选)。如果不是空的,可见在确认信息和通知收件人信息。
Surname ： 用户第二名(可选)。如果不是空的,可见在确认信息和通知收件人信息。
Password ： 两个字段用于输入用户密码。与现有密码,包含一个密码按钮,点击打开密码字段。
Groups  ： 属于哪个用户组
Language ： Zabbix前端的语言。php gettext扩展所需的翻译工作。
Theme ： 定义了前端的样子:系统默认值——使用默认系统设置，蓝色的——标准的蓝色主题，黑暗——选择黑暗的主题
Auto-login ： 启用如果你想Zabbix自动记住你和日志30天。 使用浏览器cookie。
Auto-logout (min 90 seconds) ： 选中该复选框以在设置的不活动秒数（最小值= 90秒）后启用自动用户注销。
Refresh (in seconds) ： 设置刷新率用于图形、屏幕、纯文本数据等。可以设置为0禁用。
Rows per page ： 您可以确定列表中每页显示多少行。
URL (after login) ： 成功登录后，您可以让Zabbix将您转移到特定的URL，例如触发器页面的状态。

然后创建一个报警媒介（Media）：

图片.png

关于媒体类型：https://www.zabbix.com/documentation/3.2/manual/config/notifications/media

#下面是报警媒介弹出框里面的参数的意思：

Type ： 选择哪种media作为报警类型
Send to ： 指定收件人的地址，以上面是Email为例，这里就是收件人邮箱地址
When active ： 限制发送消息的时间，这里是全天都会接收，可以选择只有工作日接收等，时间自己调整白
Use if severity ： 标记您要接收通知的触发严重性的复选框。请注意，对于非触发事件，使用默认严重性（“未分类”），因此如果要接收非触发事件的通知，请将其保留。
Status ： 用户媒体的状态，勾选是启用，不勾选是禁用。

下面再给此用户设置下权限：

图片.png

权限就是可以区分用户权限Zabbix通过定义各自的用户类型包括无特权的用户,然后在用户组访问主机组数据。

下面是用户类型的意思：

用户（Zabbix User）：用户访问监视菜单。 用户没有访问默认任何资源。 主办团体必须明确分配任何权限。
管理员（Zabbix Admin）：用户可以访问“监视和配置”菜单。 默认情况下，用户无权访问任何主机组。 必须明确给出对主机组的任何权限。
超级管理员（Zabbix Super Admin）：用户可以访问所有内容：监控，配置和管理菜单。 用户对所有主机组具有读写访问权限。 通过拒绝对特定主机组的访问，不能撤销权限。

#用户的权限授予：访问Zabbix中的任何主机数据仅授予主机组级用户组。这意味着个人用户不能被直接授予对主机（或主机组）的访问权限。只能通过被授予访问包含主机的主机组的用户组的一部分来授予对主机的访问权限。

3.2 创建Media

报警通知通过什么形式发送出去，就需要Media来创建了，所以我们先来创建一个用来发送报警邮件的Media

图片.png

#下面是上图参数的意思：

名称（Name）： Media媒介类型的名称
类型（Type）： 选择media的类型，有脚本、短信等
SMTP服务器（SMTP server）：SMTP服务器地址
SMTP服务器端口（SMTP server port）：一般SMTP端口是25，如果是TLS的端口就不是25了。
SMTP HELO（SMTP helo）：设置正确的SMTP helo值，通常是域名。
SMTP电邮（SMTP email）：此处输入的地址将用作发送邮件的发件人地址。
安全链接（Connection security）：无（None）--什么都没有，STARTTLS--使用CURLOPT_USE_SSL选项与CURLUSESSL_ALL值，SSL/TLS--使用CURLOPT_USE_SSL是可选的
认证（Authentication）：普通密码（Normal password ）
用户名称（Username）：邮箱的用户名
密码（Password）：邮箱的密码
已启用（Enabled）：是否启用

3.3 创建action

官网链接：https://www.zabbix.com/documentation/3.2/manual/config/notifications/action

图片.png

先选择出发action的触发条件：

图片.png

然后选择操作：

图片.png

#对上面两张图的参数进行下介绍：

Default operation step duration（默认操作步骤持续时间）：默认情况下的一个操作步骤的持续时间（最少60秒）。例如，一小时的持续时间意味着如果执行操作，则在下一步之前会经过一小时。
Default subject（默认收件人）：默认消息通知。 这个主题可能包含宏。
Default message（默认消息）：通知的默认消息。 消息可能包含宏。
Pause operations while in maintenance（维护期间暂停操作）：标记此复选框以延长维护期间的操作。如果取消选中此复选框，即使在维护期间，操作也将立即执行。他的选择是自Zabbix 3.2.0支持的。
Operations（操作）：点击new的会添加新的操作，这里也就是对操作的管理。
Steps（步骤）：左边是From是从第几次开始，右边是到第几次截止，0为无穷大。（这里就是Escalation升级报警的设置了）
Step duration（步骤持续时间） ：这些步骤的自定义持续时间（0 =使用默认步骤持续时间）。 我们这里自定义了60秒执行一次操作。
Operation type（操作类型）：有两种类型。发送消息 - 发送消息给用户，远程命令 - 执行远程命令更多操作可用于发现和基于自动注册的事件
Send to user groups（发送到用户群组）：单击添加以选择要发送消息的用户组。用户组必须至少具有“读取”权限给主机才能通知。
Send to users（发送到用户）：单击添加以选择要发送消息的用户。用户必须至少具有“读取”权限给主机才能通知。
Send only to（仅送到）：发送消息到所有定义的媒体类型或只选一个。
Default message（默认信息）：如果选择，将使用默认消息。
Subject（条件）：自定义消息的主题。 主题可能包含宏。

图片.png

#这是一个简单的Escalation的例子，1-3次的时候是每分钟发送一次邮件发送给运维用户组，然后从4-8次开始120秒发送一次邮件给其他的收件人，注意1-4次这四封邮件还是60秒一次呢，是从第四封邮件之后才开始2分钟一封邮件，然后第9封邮件之后，再发送给另一个人，报警的频率是随着发送报警的次数不断变化的，收件人也可以随着报警次数也就是问题待处理时间的增长而改变的。

#注意：上面参数解释的时候已经提到过了，收件用户（也就是所在的用户组）要具有主机的读权限，如果收件人没有对主机的读权限的话，那么你是收不到报警信息的。

然后是恢复操作：

IR5H98P$0(9_U7FP~8~~~]Y.png

#这里的参数就不用解释了，如果注释简单的判断触发器的状态从PROBLEM变成OK，就发恢复回来，就可以这样简单定义一下，如果需要一些复杂的条件来判断那么就可以单独定义一个action来做恢复报警的动作。

下面让我们来看下收到的报警和恢复报警的内容：

报警状态的邮件：

报警标题：PROBLEM: 内存剩余192.168.1.107

报警内容：

Trigger: 内存剩余192.168.1.107
Trigger status: PROBLEM
Trigger severity: Average
Trigger URL:
Item values: 
1. 内存剩余 (192.168.1.107:vm.memory.size[available]): 3.43 GB
2. *UNKNOWN* (*UNKNOWN*:*UNKNOWN*): *UNKNOWN*
3. *UNKNOWN* (*UNKNOWN*:*UNKNOWN*): *UNKNOWN*
 
Original event ID: 3224

报警恢复状态的邮件：

报警标题：OK: 内存剩余192.168.1.107

恢复报警内容：

Trigger: 内存剩余192.168.1.107
Trigger status: OK
Trigger severity: Average
Trigger URL: 
Item values: 
1. 内存剩余 (192.168.1.107:vm.memory.size[available]): 3.44 GB
2. *UNKNOWN* (*UNKNOWN*:*UNKNOWN*): *UNKNOWN*
3. *UNKNOWN* (*UNKNOWN*:*UNKNOWN*): *UNKNOWN*
Original event ID: 3205

#从这个警告和恢复的报警里面可以看到，有些变量的值是没取到的下来还是要按照自己的情况就行必要的更改的。

zabbix通过脚本报警的示例链接：http://www.ywnds.com/?p=6574

zabbix通过微信报警的示例链接：http://www.cnblogs.com/cp-vbird/archive/2016/10/09/5942313.html