概述

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

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

触发器表达式允许定义一个什么状况的数据是“可接受”的阈值。因此，如果接收的数据超过了可接受的状态，则触发器会被触发 - 或将状态更改为 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（或者在触发器名称上编辑一个现有的触发器）

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

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

{:.()}

即

{主机：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。

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

Zabbix-触发器详解_触发器

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