zabbix 触发器 Triggers
触发器 Triggers
触发器介绍
触发器是条件的定义,一个触发器是根据一个监控项的返回值,将之对比预先设置的阈值，当监控项返回了不符合预定义的值范围后,就进行触发下一步操作的警戒线,一般要对创建的监控项设置触发器以及触发方式和值的大小
可以在指定主机上创建触发器,只是针对指定主机有效
也可以在指定模板上创建触发器,则使用此模板的所有主机都有效,一个模板中可以有多触发器
触发器中使用的表达式是非常灵活的。你可以使用它们去创建关于监控统计的复杂逻辑测试。
触发器严重性
触发器严重性表示触发器的重要程度
Zabbix支持下列6种触发器的严重程度：
| 严重性 | 颜色 |
|---|---|
| 未分类 | 灰色 |
| 信息 | 浅蓝色 |
| 警告 | 黄色 |
| 一般严重 | 橙色 |
| 严重 | 浅红色 |
| 灾难 | 红色 |
严重性功能
- 通过不同的颜色区分不同的严重程度
- 报警音频，不同的音频代表不同的严重程度
- 用户媒介，不同的用户媒介（通知渠道）代表不同的严重程度。例如，短信 - 高严重性，email - 其他。
- 不同的严重性通过触发器执行对应的条件动作
触发器表达式格式
一个简单的表达式格式：
{:.()}
触发器官方文档
https://www.zabbix.com/documentation/6.0/zh/manual/config/triggers/expression
函数官方文档
https://www.zabbix.com/documentation/5.0/zh/manual/appendix/triggers/functions
https://www.zabbix.com/documentation/6.0/manual/appendix/triggers/functions
触发器表达式常用函数
| 函数名称 | 说明 | 范例 |
|---|---|---|
| avg() | 监控项的平均值 | [avg(#5) → 最新5个值的平均值] [avg(1h) → 最近一小时的平均值] [avg(1h,1d) → 一天前的一小时内的平均值] |
| min() | 监控项的最小值 | [CPU使用率最近5分钟的最小值大于6][system.cpu.load.min(5m)>6][CPU最近5次最小的值大于2][system.cpu.load.min(#5)>2] |
| max() | 监控项的最大值 | [max(#5) → 最新5个值的最大值] [max(1h) → 最近一小时的最大值] |
| last() | 最后的第几个值 | [注意last的 #num 参数和在其它函数中的作用不同] [例如:返回值 3, 7, 2, 6, 9] [last() 通常等同于 last(#1)] [last(#5) - 第五个最新值 ,注意:不是五个最新值] [last(#2)将返回值为7，last(#5)返回值为9] [last(#10,30) 表示每隔30s采样一次,取倒数第10个值] |
| diff() | 比对上一次文件的内容 | 返回值为1,表示发生变化,返回值为0,表示没有变化 |
| nodata() | 监控一段时间内是否返回数据 | [时间不少于30秒，因为timer处理器每30秒调用一次] [返回1 - 指定评估期没有接收到数据] [返回0 - 其它] |
触发器示例：
#示例
www.zabbix.com 主机的处理器负载过高
{www.zabbix.com:system.cpu.load[all,avg1].last()}>5
'www.zabbix.com:system.cpu.load[all,avg1]' 给出了被监控参数的简短名称。它指定了服务器
是“www.zabbix.com”，监控项的键值是“system.cpu.load[all,avg1]”。通过使用函数“last()”获
取最新的值。最后，“>5”意味着当www.zabbix.com最新获取的处理器负载值大于5时触发器就会处于异常状
态#示例
www.zabbix.com is overloaded
{www.zabbix.com:system.cpu.load[all,avg1].last()}>5 or
{www.zabbix.com:system.cpu.load[all,avg1].min(10m)}>2
当前处理器负载大于5或者最近10分钟内最小值大于2，表达式为true。#示例
/etc/passwd文件被修改
使用函数diff：
{www.zabbix.com:vfs.file.cksum[/etc/passwd].diff()}=1
当文件/etc/passwd的checksum值与最近的值不同时，表达式为true。
类似的，表达式可以用于监控重要文件的修改, 如/etc/passwd, /etc/inetd.conf, /kernel等#示例
有用户正在从互联网上下载一个大文件
使用min函数:
{www.zabbix.com:net.if.in[eth0,bytes].min(5m)}>100K
在过去5分钟内，eth0上接收字节数大于100kb时，表达式为true。#示例
SMTP服务群集的两个节点都停止。 注意在一个表达式中使用两个不同的主机:
{smtp1.zabbix.com:net.tcp.service[smtp].last()}=0 and
{smtp2.zabbix.com:net.tcp.service[smtp].last()}=0 当SMTP服务器smtp1.zabbix.com和smtp2.zabbix.com都停止，表达式为true#示例
Zabbix agent需要升级
使用str()函数:
{www.zabbix.com:agent.version.str("beta8")}=1
如果Zabbix agent版本是beta8（可能是1.0beta8），则表达式为真。#示例
服务器无法访问
{www.zabbix.com:icmpping.count(30m,0)}>5
当主机“www.zabbix.com”在30分钟内超过5次不可达，则表达式为真#示例
3分钟内没有心跳检查
使用nodata()函数:
{www.zabbix.com:tick.nodata(3m)}=1
要使用这个触发器，'tick'必须定义成一个
Zabbix[:manual/config/items/itemtypes/trapper|trapper]]监控项。主机应该使用
zabbix_sender定期发送这个监控项的数据。
如果在180秒内没有接收到数据，则触发值变为异常状态。
注意:nodata可以在任何类型的监控项中使用。#示例
夜间的CPU负载
使用time()函数:
{zabbix:system.cpu.load[all,avg1].min(5m)}>2 and
{zabbix:system.cpu.load[all,avg1].time()}>000000 and
{zabbix:system.cpu.load[all,avg1].time()}<060000
仅在夜间(00:00-06:00)，触发器状态变可以变为真。#示例
检查客户端本地时间是否与Zabbix服务器时间同步
使用fuzzytime()函数:
{MySQL_DB:system.localtime.fuzzytime(10)}=0 当MySQL_DB服务器的本地时间与Zabbix server之间的时间相差超过10秒，触发器将变为异常状态。#示例
比较今天的平均负载和昨天同一时间的平均负载（使用第二个“时间偏移”参数）。
{server:system.cpu.load.avg(1h)}/{server:system.cpu.load.avg(1h,1d)}>2
如果最近一小时平均负载超过昨天相同小时负载的2倍，触发器将触发。#示例
使用了另一个监控项的值来获得触发器的阈值：
{Template PfSense:hrStorageFree[{#SNMPVALUE}].last()}<{Template
PfSense:hrStorageSize[{#SNMPVALUE}].last()}*0.1
如果剩余存储量下降到10%以下，触发器将触发。#示例
使用评估结果获取超过阈值的触发器数量:
({server1:system.cpu.load[all,avg1].last()}>5) +
({server2:system.cpu.load[all,avg1].last()}>5) +
({server3:system.cpu.load[all,avg1].last()}>5)>=2
如果表达式中至少有两个触发器大于5，触发器将触发。
滞后
有时我们需要一个OK和问题状态之间的区间，而不是一个简单的阈值。
例如，我们希望定义一个触发器，当机房温度超过20C时，触发器会出现异常，我们希望它保持在那种
状态，直到温度下降到15C以下。
为了做到这一点，我们首先定义问题事件的触发器表达式。然后在事件成功迭代中选择恢复表式，
并为OK事件输入恢复表达式。
请注意，只有首先解决问题事件才会评估恢复表达式。如果问题条件仍然存在，则不能通过恢复表达式来解决问题
示例 1
机房温度过高。
问题表达式:
{server:temp.last()}>20
恢复表达式:
{server:temp.last()}<=15
示例 2
磁盘剩余空间过低。
问题表达式: it is less than 10GB for last 5 minutes
{server:vfs.fs.size[/,free].max(5m)}<10G
恢复表达式: it is more than 40GB for last 10 minutes
{server:vfs.fs.size[/,free].min(10m)}>40G
自定义触发器
配置单条件触发器
自定义单条件触发器：设置内存低于 30% 进行告警，点击对应主机→ 创建触发器获取内存还剩余的百分比：
剩余 30% 可用，则需要告警通知；剩余 50% 可用，就算恢复；
编辑触发器表达式
#问题表达式:
{Webserverb:mem_use_percent.last()}<30
#恢复表达式:
{Webserver:mem.use_percent.last()}>60
#测试内存
dd if=/dev/zero of=/dev/null bs=1000M count=1024
配置多条件触发器
自定义多条件触发器：设置空闲内存低于 30%并且swap使用大于1% 进行告警
#增加swap的自定义监控项
UserParameter=swap_use,free |awk '/^Swap/{print $3*100/$2}'
#编辑触发器表达式
#问题表达式：
{Webserver:mem_unuse_percent.last()}<=30 and{Web:swap_use.last()}>=1#恢复表达式：
{Webserver:mem_unuse_percent.last()}>=50
#使用命令压测
dd if=/dev/zero of=/dev/null bs=500M count=1024
#只满足内存低于30%，所以不会警告
dd if=/dev/zero of=/dev/null bs=1000M count=1024
#内存低于30%，并且swap使用超过1%
触发器依赖关系
什么是触发依赖
有时候一台主机的可用性依赖于另一台主机。如果一台路由器宕机，则路由器后端的服务器将变得不可用。
如果这两者都设置了触发器，你可能会收到关于两个主机宕机的通知，然而只有路由器是真正故障的。
这就是主机之间某些依赖关系可能有用的地方，设置依赖关系的通知会被抑制，而只发送根本问题的通知。
触发器依赖关系示例
例如，主机位于路由器2后面，路由器2在路由器1后面。
Zabbix - 路由器1 - 路由器2 - 主机
如果路由器1宕机，显然主机和路由器2也不可达，然而我们不想收到主机、路由器1和路由器2都宕机的3条通知。
因此，在这种情况下我们定义了两个依赖关系：
'主机宕机' 触发器依赖于 '路由器2宕机' 触发器
'路由器2宕机' 触发器依赖于 '路由器1宕机' 触发器
触发器依赖案例
依赖场景环境说明
假设:充当R 路由节点，H 充当主机节点
- 模拟当H节点的80端口如果不存活，需要检查R节点的80端口是否存活
- 如果R路由节点的80端口存活，则触发H主机节点的80端口不存活警告
- 如果R路由节点的80端口不存活，则仅触发路由节点的警告，而不触发主机节点的警告
定义触发器表达式
R路由节点：定义监控项，配置触发器
H主机节点：定义监控项，配置触发器
模拟路由与主机故障
模拟R路由器、H主机节点同时障时，会同时收到两个告警，显然不符合预期效果
配置触发器依赖关系
在H服务器节点上对应的触发器上配置依赖关系，依赖R路由节点对应的触发器
再次模拟路由与节点故障
- 关闭 “路由器” 80端口，以及主机节点80端口；此时只有路由节点会警告
- 启用 “路由器” 80端口，关闭主机节点80端口，此时只有主机节点会警告