最近一直在学习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