Zabbix-触发器详解

最近一直在学习zabbix，感觉zabbix中 监控项 和 触发器 的配置非常重要，无论是我们监控日志还是自定义监控一些内容，默认自带的往往不够用，还需要自定义地去配置监控项和触发器。

转载自： https://www.zabbix.com/documentation/3.4/zh/manual/config/triggers

概述

---

触发器是“评估”由项目采集的数据并表示当前系统状况的逻辑表达式。

当监控项用于采集系统的数据时，始终遵循这些数据是非常不切合实际的，因为这些数据始终在等待一个令人担忧或者值得关注的状态。然而这个“评估”数据的工作可以留给触发器表达式。

触发器表达式允许定义一个什么状况的数据是“可接受”的阈值。因此，如果接收的数据超过了可接受的状态，则触发器会被触发 - 或将状态更改为 PROBLEM 。

一个触发器可以拥有下面几种状态：

值	描述
OK	这是一个正常的触发器状态，在旧版本的 Zabbix 中称为 FALSE。
PROBLEM	通常意味着触发了某些事情。例如，处理器的负载较高。在旧版本的 Zabbix 中称为 TRUE。

每当 Zabbix server 接收到作为表达式一部分的新值时，都会重新计算触发器状态（表达式）。

如果在表达式中使用基于时间的函数(nodata(), date(), dayofmonth(), dayofweek(), time(), now())，触发器就会由 Zabbix timer 进程每 30 秒重新计算一次。如果在表达式中同时使用基于时间和非基于时间的函数，当接收到一
个新值和每隔 30 秒都会重新计算触发器的状态。

你可以构建不同复杂程度的触发器表达式。

---

触发器表达式

---

触发器中使用的表达式是非常灵活的。你可以使用他们去创建关于监控统计的复杂逻辑测试。

配置一个触发器，请执行以下操作：

• 点击 Zabbix 上方菜单栏的 Configuration → Hosts

• 在 Host 那一行点击 Triggers

• 在右上角点击 Create Trigger（或者在触发器名称上编辑一个现有的触发器）

• 在打开的页面输入触发器的参数

一个简单有效的表达式看起来像：

{<server>:<key>.<function>(<parameter>)}<operator><constant>

即

{主机：key.函数(参数)}<表达式>常数

函数：触发器函数允许引用收集的值，当前时间和其他因素。

函数参数：

大多数数字型的函数接受秒数来作为参数。

你可以使用前缀 # 来指定参数具有不同的含义：

函数内容	含义
sum(600)	600 秒内所有值的总和
sum(#5)	最后 5 个值的总和

函数 last 当以 # 作为前缀使用时，值具有不同的含义，它会让她会选择第 N 个的上一个值，所以给定值 3、7、2、6、5（按照时间顺序，第一个值 3 为最新值），last(#2)将返回值为 7 ，last(#5) 将返回值为 5。

avg, count, last, min and max 函数支持额外的第二个参数 time_shift（时间偏移量）。这个参数允许从过去一段时间内引用数据。例如，avg(1h,1d)将会返回一天前 1 小时的平均值。
触发器需要使用 history 历史数据来计算。如果历史数据不可用（特别是关于 time_shift 时间偏移量），则无法使用趋势信息，因此必须至少保持触发器函数所预期这段时间的历史信息。

你可以在触发器表达式中使用支持的单位符号，例如“5m”（分钟）可被“300”秒代替，“1d”（天）可被“86400”秒代替，“1k”代表“1024”bytes。

运算符：触发器支持的运算符（在执行中优先级递减）

not，and and or 运算符区分大小写，而且必须为小写。它们也必须被空格或括号包围。所有运算符中，除了 unary - and not，都有从左到右的关联性。

---

触发器示例

---

• 示例 1

触发器名称：Processor load is too high on www.zabbix.com。触发器表达式如下：

{www.zabbix.com:system.cpu.load[all,avg1].last()}

“www.zabbix.com:system.cpu.load[all,avg1]” 给出了被监控对象参数的简短名称。它指定了服务器是“www.zabbix.com”，监控项的键值是“system.cpu.load[all,avg1]”。通过使用函数“last()”获取最近一次获取的值。最后，“>5”表示来自主机 www.zabbix.com 的最后一次获取的负载值大于 5 时触发器就会进入 PROBLEM 状态。

• 示例 2

触发器名称：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，表达式为“TURE”，就会使触发器进入 PROBLEM 状态。

• 示例 3

触发器名称：/etc/passwd has been changed。触发器表达式如下：

使用了函数 diff :

{www.zabbix.com:vfs.file.cksum[/etc/passwd].diff()}=1

当文件/etc/passwd 检查的 checksum 值与最近的值不同时，表达式为“TURE”，就会使触发器进入 PROBLEM 状态。

同样的表达式还可以用于监控重要的文件，比如文件/etc/passwd、/etc/inetd.conf、/kernel 等等。

• 示例 4

触发器名称：Someone is downloading a large file from the Internet。触发器表达式如下：

使用函数 min :

{www.zabbix.com:net.if.in[eth0,bytes].min(5m)}>100K

当网络适配器“eth0”在 5 分钟内接收的字节大于 100KB，表达式为“TURE”，就会使触发器进入 PROBLEM 状态。

• 示例 5

触发器名称：Both nodes of clustered SMTP server are down。触发器表达式如下：

注意：在同一个表达式中使用了两个不同的主机

{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”都停止，表达式为“TURE”，就会使触发器进入 PROBLEM 状态。

• 示例 6

触发器名称：Zabbix agent needs to be upgraded。触发器表达式如下：

使用函数 str() :

{zabbix.zabbix.com:agent.version.str("beta8")}=1

如果 Zabbix agent 有 beta8 版本（大概为 1.0beta8），表达式为“TURE”，就会使触发器进入 PROBLEM 状态。

• 示例 7

触发器名称：Server is unreachable。触发器表达式如下：

{zabbix.zabbix.com:icmpping.count(30m,0)}>5

当主机“zabbix.zabbix.com”在 30 分钟内超过 5 次不可达，表达式为“TURE”，就会使触发器进入 PROBLEM 状态。

• 示例 8

触发器名称：No heartbeats within last 3 minutes。触发器表达式如下：

使用函数 nodata() :

{zabbix.zabbix.com:tick.nodata(3m)}=1

‘tick’ 必须为 ‘Zabbix trapper’ 类型。为了使这个触发器工作，监控项 ‘tick’ 必须要定义，这个主机应使用 zabbix_sender 定期发送此参数的数据，如果在 180 秒内还未收到 zabbix_sender 发送的数据，那么触发器的状态就会变成 PROBLEM 状态。

• 示例 9

触发器的名称为：CPU activity at night time。触发器表达式如下：

使用了函数 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

只有在凌晨 0 点到 6 点整，最后 5 分钟内 cpu load 大于 2，触发器的状态才会变更为 PROBLEM 状态。

• 示例 10

触发器名称：Check if client local time is in sync with Zabbix server time。触发器表达式如下：

使用了函数 fuzzytime() :

{MySQL_DB:system.localtime.fuzzytime(10)}=0

当 MySQL_DB 的本地时间与 Zabbix server 之间的时间相差 10 秒以上，就会使触发的状态变更为 PROBLEM。

• 示例 11

触发器名称为：Comparing average load today with average load of the same time yesterday (using a second time_shift parameter)。触发器表达式如下：

{server:system.cpu.load.avg(1h)}/{server:system.cpu.load.avg(1h,1d)}>2

如果最后一小时的平均 cpu load 超过前一天的同一小时两倍，就会使触发器的状态变更为 PROBLEM 状态。

• 示例 12

使用了另一个监控项来获得触发器的阈值：

{Template PfSense:hrStorageFree[{#SNMPVALUE}].last()}<{Template 
PfSense:hrStorageSize[{#SNMPVALUE}].last()}*0.1

如果 hrStorageFree 低于 10%，就会使触发器的状态变更为 PROBLEM 状态。

• 示例 13

使用 evaluation result 来获取触发器的数量超过阈值:

({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，就会使触发器的状态变更为 PROBLEM 状态。

---

滞后（Hysteresis）

---

有时候我们需要一个触发器状态 OK 和 PROBLEM 之间的间隔，而不是简单的阈值。例如，我们想定义一个触发器，当机房的室温超过 20 摄氏度时，我们希望它保持这个状态，直至温度低于 15 摄氏度，触发器的状态才会变更为 OK。

为了做到这一点，我们首先定义一个 PROBLEM 事件的触发器表达式，然后为 OK event generation 择’Recovery expression’，并为 OK 事件输入不同的表达式。

• 示例 1

触发器名称：Temperature in server room is too high。

Problem expression:

{server:temp.last()}>20

Recovery expression:

{server:temp.last()}<=15

• 示例 2

触发器名称：Free disk space is too low。

Problem expression: 在最近 5 分钟内文件系统/的空闲空间小于 10GB。

{server:vfs.fs.size[/,free].max(5m)}<10G

Recovery expression: 在最近 10 分钟内文件系统/的空闲空间大于 40GB。

{server:vfs.fs.size[/,free].min(10m)}>40G

---