2. 触发器
2.1 什么是触发器
当监控的值发现变化后，对应的值不符合预期，则应该通过触发器通知管理人员介入；
比如：监控TCP的80端口，如果存活则符合预期，如果不存活则不符合预期，应该通过触发器通知。
2.2 触发器严重性
触发器严重性定义了触发器的重要程度，Zabbix支持下列触发器的严重程度：
| 严重性 | 定义 | 颜色 |
|---|---|---|
| 未分类 | 未知严重性 | 灰色 |
| 信息 | 提示 | 浅灰色 |
| 警告 | 警告 | 黄色 |
| 一般严重 | 一般问题 | 橙色 |
| 严重 | 发生重要的事情 | 浅红色 |
| 灾难 | 灾难，财务损失等 | 红色 |
- 通过不同颜色代表不同的严重程度
- 报警音频，不同的音频代表不同的严重程度
- 用户媒介，不同的用户媒介代表不同的严重程度。例如SMS-高严重性，email -其他
- 通过触发器执行对应的条件动作
2.3 配置一个触发器
配置一个触发器，监控主机TCP80端口是否存活，如果不存活则通知，存活则不通知
- 配置→主机
- 点击主机一行的触发器
- 点击右上角的创建触发器（或者点击触发器名称去修改已存在的触发器）
- 在窗口中输入触发器的参数
-
为主机配置触发器，监测80端口是否存活
-
关闭80端口后，zabbix会提示端口不存活
3.打开80端口后，zabbix会提示恢复，以及该问题的持续多长时间
2.4 触发器表达式
| 函数名称 | 作用 |
|---|---|
| avg() | 监控项的平均值 |
| min() | 监控项的最小值 |
| max() | 监控项的最大值 |
| last() | 注意last的#num 参数和在其他函数中的作用不一样，例如返回值：3，4，7，2，8 |
| diff() | 对比上次文件的内容 |
| nodata() | 监控一段时间内是否返回数据：时间不少于30秒，因为timer处理器每30秒调用一次 |
2.4.1 触发器示例场景1
www.zabbix.com的处理器负载过高
www.zabbix.com:system.cpu.load[all,avg1].last()>5
服务器是www.zabbix.com，监控项键值是system.cpu.load[all,avg1]
通过使用函数“last()”获取最新的值。最后>5 意味着当www.zabbix.com最新获取的处理器负载值大于5时触发器就会处于异常状态。
2.4.2 触发器示例场景2
当前处理器负载大于5或者最近10分钟内最小值大于2，表达式为True
{www.zabbix.com:system.cpu.load[all,avg1].last()>5} and {www.zabbix.com:system.cpu.load[all.avg1].min(10m)>2}
2.4.3 触发器示例场景3
监控/etc/passwd 文件是否被修改，当文件/etc/passwd的checksum值与最近的值不同时，表达式为true。
{www.zabbix.com:vfs.file.cksum[/etc/passwd].diff()}=1
2.4.4 触发器示例场景4
最近5分钟，如果eth0上接受字节数大于100kb时，则表达式为真
{www.zabbix.com:net.if.in[eth0,bytes].min(5m)}>100k
2.4.5 触发器示例场景5
当www.zabbix.com在30分钟内超过5次不可达（值为0状态），则表达式为真
{www.zabbix.com:icmpping.count(30m,0)}>5
2.4.6 触发器示例场景6
比较今天的平均负载和昨天同一时间的平均负载, 使用第二个“时间偏移参数”
如果最近一小时的平均负载超过昨天相同小时负载的2倍，触发器将会触发
{server:system.cpu.load.avg(1h)}/{server:system.cpu.load.avg(1h,1d)}>2
2.4.7 触发器示例场景7
如果表达式中至少有2个触发器大于5，触发器将触发
({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
2.4.8 触发器示例场景8
使用nodata()函数:如果在180秒内没有接收到数据，则触发为异常状态
{www.zabbix.com:tick.nodata(3m)}=1
2.5 触发器滞后
有时候我们需要触发器处于OK和问题状态直接的区间，而不是一个简单的“阈值报警”就完事了。
例如，我们希望定义一个触发器，当机房温度超过20℃时，触发异常，我们希望它保持在那种状态，直到温度下降到15℃以下，为了做到这一点，我们首先要定义问题事件的触发表达式，然后再定义事件成功迭代中选择恢复表达式为OK事件输入恢复表达式
2.5.1 滞后示例1
机房温度过高
问题表达式：当机房温度大于20℃
{server:temp.last()}>=20
恢复表达式：当机房温度小于或者等于15℃
{server:temp.last()}<=15
2.5.2 滞后示例2
磁盘剩余空间过低
问题表达式：在最近5分钟内最大值小于10G
{server:vfs.fs.size[/,free].max(5m)}<10G
恢复表达式：最近10分钟内最小值大于40G
{server:vfs.fs.size[/,free].min(10m)}>40G
2.6 自定义触发器场景
2.6.1 配置单条件触发器
-
自定义单条件触发器：设置内存低于30%进行警告，点击对应主机→创建触发器
- 1.获取内存剩余百分比：
- 剩余30%可用，则需要告警通知；
- 剩余50%可用，就算恢复；
- 1.获取内存剩余百分比：
-
编辑触发器表达式
- 问题表达式：{server:Mem_pre.last()}<30
- 恢复表达式：{server:Mem_pre.last()}>50
-
使用dd if=/dev/zero of=/dev/null bs=500M count=1024 压低内存
2.6.2 配置多条件触发器
- 多条件触发器：设置内存低于30%并且swap使用大于1%进行告警
- 增加swap的监控UserParameter=Swap_pre,free -m |awk ‘/^Swap/{print $3*100/$2}’
- 编辑触发器表达式
- 问题表达式：{server:Mem_pre.last()}<30 and {server:Swap_pre.last()}>1
- 恢复表达式：{server:Mem_pre.last()}>30 and {server:Swap_pre.last()}<1
- 使用命令压测
- dd if=/dev/zero of=/dev/null bs=300M count=1024 只满足内存低于百分之30，不会告警
- dd if=/dev/zero of=/dev/null bs=800M count=1024 内存低于30%，并且swap使用超过1%
2.7 触发器依赖关系
2.7.1 什么是触发器依赖
有时候一台主机的可用性依赖于另一台主机。如果一台路由器宕机，则路由器后端的服务器将变得不可用。如果这两者都设置了触发器，你可能会收到两个主机宕机的通知，然后只有路由器是真正的故障。
这就是主机之间某些依赖关系可能有用的地方，设置依赖关系的通知会被抑制，而只发送根本问题的通知。
2.7.2 触发器依赖关系示例
例如，主机位于路由器2后面，路由器2在路由器1后面。
zabbix - 路由器1 - 路由器2 - 主机
如果路由器1宕机，显然主机和路由器2也不可达，然后我们不想收到主机、路由器1 和路由器2都宕机的3条通知。因此，在这种情况下我们定义了两个依赖关系：
'主机宕机' 触发器依赖于 '路由器2宕机' 触发器
'路由器2宕机' 触发器依赖于'路由器1宕机'触发器
2.8 触发器依赖场景配置
2.8.1 依赖场景环境说明
- 假设192.168.20.47充当路由器节点，192.168.20.48充当主机节点
- 1.模拟当192.168.20.48的80端口如果不存活，需要检查192.168.20.47的80端口是否存活；
- 2.如果路由器节点的80端口存活，则触发主机节点的80端口不存货警告；
- 3.如果路由节点80端口不存货，则仅触发路由节点的警告，而不触发主机的警告；
2.8.2 定义触发器表达式
路由节点：定义监控项，配置触发器
主机节点：定义监控项，配置触发器
2.8.3 模拟路由与主机故障
模拟路由器、节点t故障时，会同时受到两个告警
2.8.4 配置触发器依赖关系
在服务器节点上对应的触发器上配置依赖关系，依赖路由节点对应的触发器
2.8.5 再次模拟路由与节点故障
关闭“路由器”的80端口，以及主机节点80端口，此时只有路由器会警告
启动“路由器”80端口，关闭主机节点80端口，此时只有主机节点会警告
1784
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
