在本章中可以了解到Triggers（触发器）的配置和Actions（动作）的配置，详细介绍触发器的规则表达式、告警、告警升级等，
作为一个监控解决方案，告警是不可或缺的功能。当从监控对象上收集的监控项的值满足系统中设定的阈值即产生告警事件，依据告警事件的不同类型，产生相应的告警动作，给用户发送告警信息，或者执行命令等等。Zabbix中的告警流程如下图7-1所示。
图 8-1
我们知道在Zabbix中是通过监控项收集监控数据，然后这些数据会保存在数据库中。有时候在某个监控指标出现问题时想让系统能及时通知我们，这就需要告诉系统监控指标的数据在什么情况下是有问题的，也就是常说的阈值。而触发器就是通过逻辑表达式对监控指标的数据进行运算，将其结果与定义的阈值进行比较，从而判断该监控指标的状态是否正常。
在Zabbix中，无论触发器的表达式有多复杂，最终我们得到的结果不是True（真）就是False（假）。这个结果直接关系到触发器的状态，当结果为False时触发器的状态是OK，意味着该数据是正常的。结果为True时触发器的状态是PROBLEM，意味着该数据是有问题的，这个对应关系要记清楚。
如果在触发器中使用了基于时间的函数nodata()、date()、dayofmonth()、dayofweek()、time() 和now()时，Zabbix server会对触发器每隔30秒重新进行运算。如果同时使用了基于时间的函数和其他函数，当接收到一个新值并且每隔30秒将重新进行运算。
近日完成《深入浅出 zabbix 4.0》视频教程的录制并正式发布，该教程基于 zabbix 4.2 ，对Zabbix进行全面讲解。欢迎大家围观。课程链接：https://edu.51cto.com/sd/ce000
在触发器中使用的表达式非常灵活，通过它们也可以创建复杂的逻辑运算。让我们一起来看个简单的表达式的格式。
{<server>:<key>.<function>(<parameter>)}<operator><constant>
例如：{Testsrv:vfs.fs.size[/var,pused].delta(600)}>3
可以看到一个触发器表达式主要有两部分组成：
应用到监控项数据的函数。
对函数结果进行算术和逻辑运算。
在上面的例子中指定了完整的监控项key，即 Testsrv:vfs.fs.size[/var,pused]和应用的函数 delta(600)，其运算结果使用运算符大于号（>）和常量 3 进行比较。
我们可以在触发器表达式中引用多个监控项，每个监控项应用一个函数。同一个监控项也可以在表达式中使用两次，但是要明确指定完整的监控项，例如：
{test:log[/tmp/operations.log,,,10,skip].nodata(600)}=1 or
{test:log[/tmp/operations.log,,,10,skip].str(error)}=1
如果operations.log至少10分钟没有收到新的行，或者在log文件中发现一个错误，该触发器的状态会变为PROBLEM。
触发器表达式中不仅可以从同一主机引用监控项，也可以从不同的主机或代理服务器（如果你能访问它们）中引用监控项，例如：
{Proxy1:server1:agent.ping.last(0)}=0 and
{Proxy2:server2:agent.ping.last(0)}=0
如果主机server1和server2同时都ping不同时触发器的状态会变为PROBLEM。即便主机是被不同的代理服务器监控也一样工作的很好。
所有在Calculate checks中可以应用的函数都可以在触发器表达式中应用，更详细的可用函数的定义可以参考Zabbix官方网站（https://www.zabbix.com/documentation/3.0/manual/appendix/triggers/functions）。
很多触发器函数可以接收seconds（秒）和 #num参数，这两个参数的含义如下：
seconds：指定一个时间期间，单位为秒。触发器将使用指定期间内的监控项值进行函数运算。例如：sum（600）表示对最近600秒内监控项的值求和。600秒也可以写成10m（分钟），86400可以写成1d（天）。
#num：指定次数。触发器将使用指定的最近次数收集监控项的值进行函数运算。例如：sum（#5）表示最近5次收集的值进行求和。
需要注意的是使用last函数时#num的含义有所不同，#num表示最近第几次。例如某个监控项最近5次收集的值分别是3（最新的）、7、2、6、5，last（#2）将返回7，last（#5）将返回5。
在触发器中我们使用哪个参数比较好呢？建议在Passive（被动式）监控方式中各种监控项数据都是由Zabbix server定期的收集，在这种情况下使用seconds会比较好，如果你修改了相关监控项的监测时间间隔会对#num参数会有影响，从而影响触发器。而使用seconds参数可能更接近实际的监测，在日后触发器的维护中你能够更容易的理解触发器的定义。对于使用active（主动式）监控方式的监控项，尤其是trapper监控项和log文件，我们不能保证有一个稳定的、可靠的监测时间间隔，所以使用#num通常是最好的选择。
在avg、count、last、min和max函数中还支持使用第二个参数 time_shift，这个参数允许从过去的某个时间期间引用数据。例如：avg（1h，1d）将返回前一天1小时的平均值。在这里我们要注意，触发器只使用历史数据，因此使用time_shift参数时指定期间内的历史数据必须能正常访问。
Zabbix在触发器中支持下面的运算符（优先级由高到低）如表8-1所示。
表 8-1
优先级 | 运算符 | 定义 |
1 | - | 一元负号运算符（左侧没有操作数的减号） |
2 | not | 逻辑运算符 NOT |
3 | * | 乘 |
/ | 除 | |
4 | + | 加 |
- | 减 | |
5 | < | 小于 |
<= | 小于等于 | |
> | 大于 | |
>= | 大于等于 | |
6 | = | 等于 |
<> | 不等于 | |
7 | and | 逻辑运算符 AND |
8 | or | 逻辑运算符 OR |
注意not、and和or运算符必须是小写的，所有运算符中除了一元负号运算符和not运算符，都是从左到右结合。
下面我们结合一些例子更好的理解触发器的使用。
{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进行比较，如果最近一次的监控项值大于5时触发器的状态就会变为PROBLEM。
{www.zabbix.com:system.cpu.load[all,avg1].last()}>5or {www.zabbix.com:system.cpu.load[all,avg1].min(10m)}>2
最近一次的CPU负载平均值大于5或最近10分钟的负载平均值大于2时触发器的状态就会变为PROBLEM。
{www.zabbix.com:vfs.file.cksum[/etc/passwd].diff()}=1
监测/etc/passwd文件的前一个checksum值和最近一次的值不同时触发器的状态就会变为PROBLEM。
{www.zabbix.com:net.if.in[eth0,bytes].min(5m)}>100K
最近5分钟网络接口eth0接收的字节数大于100KB时触发器的状态就会变为PROBLEM。
{smtp1.zabbix.com:net.tcp.service[smtp].last()}=0and {smtp2.zabbix.com:net.tcp.service[smtp].last()}=0
监测不同主机上的SMTP服务都停止时触发器的状态就会变为PROBLEM。
{zabbix.zabbix.com:icmpping.count(30m,0)}>5
监测主机在过去30分钟超过5次ping不通时触发器的状态就会变为PROBLEM。
{zabbix.zabbix.com:tick.nodata(3m)}=1
例子中tick必须使用Zabbix tgapper监控方式，主机定期通过zabbix_sender发送tick的值到服务器，如果在3分钟（180秒）没有接收到数据时触发器的状态就会变为PROBLEM。
{zabbix:system.cpu.load[all,avg1].min(5m)}>2and {zabbix:system.cpu.load[all,avg1].time()}>000000 and {zabbix:system.cpu.load[all,avg1].time()}<060000
例子中使用了time函数，只在晚上00:00 – 06:00之间，最近5分钟CPU负载大于2时触发器的状态就会变为PROBLEM。
{MySQL_DB:system.localtime.fuzzytime(10)}=0
例子中使用了fuzzytime函数，当主机MySQL_DB的本地时间和Zabbix server的本地时间相差超过10s时触发器的状态就会变为PROBLEM。
{server:system.cpu.load.avg(1h)}/{server:system.cpu.load.avg(1h,1d)}>2
例子中使用了第二个参数time_shift，如果最近1小时CPU负载的平均值是昨天相同时间的2倍时触发器的状态就会变为PROBLEM。
{TemplatePfSense:hrStorageFree[{#SNMPVALUE}].last()}<{TemplatePfSense:hrStorageSize[{#SNMPVALUE}].last()}*0.1
当剩余存储容量低于总容量的10%时触发器的状态就会变为PROBLEM。
({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
当3台主机中至少有两台主机最新的CPU负载平均值超过5时触发器的状态就会变为PROBLEM。
{zbserver:grpsum["cluster","proc.num[listener]", last, 0].last(0)} /
{zbserver:grpsum["cluster","agent.ping", last, 0].last(0)} < 0.5
Aggregated 和Calculated 监控项在定义触发器时也是非常有用的。在例子中正常提供服务的服务器和可用服务器的比值低于0.5时触发器的状态就会变为PROBLEM。
有时候触发器必须在不同的情况下使用不同的条件，例如，机房温度超过20℃触发器状态变为PROBLEM，然后触发器一直处于PROBLEM状态，直到温度低于15℃恢复为OK状态。可通过定义下面的触发器来实现。
({TRIGGER.VALUE}=0 and {server:temp.last()}>20) or
({TRIGGER.VALUE}=1 and {server:temp.last()}>15)
在这个触发器定义中我们使用了{TRIGGER.VALUE}，{TRIGGER.VALUE}返回当前触发器的值。{TRIGGER.VALUE}为0是OK状态，{TRIGGER.VALUE}为1是PROBLEM状态。当触发器的状态是OK时，{TRIGGER.VALUE}=0的运算结果是1，{TRIGGER.VALUE}=1的运算结果是0，因此在温度超过20℃时，触发器返回的状态是1，也就是PROBLEM状态。
为了加深理解，在来看看这个例子，最近5分钟磁盘剩余空间的最大值小于10GB时触发器的状态就会变为PROBLEM，然后触发器一直处于PROBLEM状态，直到最近10分钟磁盘剩余空间的最小值大于40GB恢复为OK状态。
({TRIGGER.VALUE}=0and {server:vfs.fs.size[/,free].max(5m)}<10G) or
({TRIGGER.VALUE}=1and {server:vfs.fs.size[/,free].min(10m)}<40G)
在一个大型的基础架构中，某种应用服务或主机的可用性并不取决于其自身是否可用，它可能依赖于其他连接的设备的可用性。例如，交换机发生故障时你不仅收到路由器的告警通知，同时你也会收到所有连接到该交换机上主机的告警通知，实际上只是交换机发生故障，导致Zabbix server不能通过交换机对主机进行监控。由此可以看到交换机和主机之间的依赖关系，我们可以在主机上定义的触发器中设置对交换机可用性的依赖关系，当交换机发生故障时，与其连接的主机会在交换机不可用的情况下跳过任何触发器的监测，直到依赖的交换机变为可用，也就是交换机可用性的触发器状态变为OK。
这种触发器级别的依赖特性非常灵活和强大，具有最明显的优势，你可以定义在不同主机上的单个服务之间的依赖关系。例如，你有多个web服务器上的web应用连接到一个数据库服务器，如果数据库不可用时web应用也不会正常运行，因此你可以设置一个web监控触发器和数据库可用性之间的依赖关系。同一台服务器中可能运行着多个不同的服务或应用，你可以设置这些服务或应用的触发器和主机可用性之间的依赖，或者和其他服务或应用触发器的依赖关系。
触发器依赖虽然配置简单，但是也很容易变得复杂，增加维护工作量。因此我们要选择关键的、少量的依赖关系进行配置，这样可以帮助我们从大量告警通知中解脱出来，更专注于解决遇到的问题。
Trigger severity（触发器告警级别）是一个可以附加到触发器中的简单的标签。在web前端页面中使用不同的颜色显示告警级别，在用户配置中还可以为不同的告警级别定义不同的告警声音，相同的监控项可以在不同的级别上创建不同的动作，例如，我们创建2个触发器，其中一个在磁盘容量剩余10%时触发warning级别的告警，另一个在磁盘容量5%时触发critical告警。
Zabbix支持以下告警级别：
Not classified：未分类故障，显示为灰色。
Information：一般信息，显示为亮蓝色。
Warning：警告信息，显示为×××。
Average：一般故障，显示为橙色。
High：严重故障，显示为亮红色。
Disaster：灾难，显示为红色。
Zabbix中也可以自定义告警级别的名称，在Administration--> General --> Trigger severities页面中，自定义相应级别的名称，例如，Important。如果需要将自定义的名称翻译成本地语言，需要编辑<frontend_dir>/locale/zh_CN/LC_MESSAGES/frontend.po文件，在文件中添加2行内容：
msgid "Important"
msgstr "重大故障"
编辑完成后保存，执行下面的命令生成frontent.mo。
# msgfmt –vfrontend.po –o frontend.mo
在介绍创建触发器之前，我们先看看创建触发器时配置页面中各参数的含义，点击Configuration --> Hosts/Template --> Triggers 页面中，点击右上角的Create trigger按钮进入触发器配置页面。如下图8-2所示。
图 8-2
Trigger标签中各参数的含义如下：
Name：触发器名称。在名称中支持宏变量，包括：{HOST.HOST}、{HOST.NAME}、{HOST.CONN}、{HOST.DNS}、{HOST.IP}、{ITEM.VALUE}、{ITEM.LASTVALUE} 和 {$MACRO}。$1，$2，… ，$9可以引用表达式中的常量。$1 - $9会被解析为应用的常量的值，例如触发器名称为Processor load above $1 on {HOST.NAME}，如果定义的表达式为{New host:system.cpu.load[percpu,avg1].last()}>5，那么该触发器触发后名称为自动变为Processor load above 5 on New host。
Expression：用于计算触发器状态的逻辑表达式。
Multiple PROBLEM eventsgeneration：选中此项后，每次判断触发器的状态为PROBLEM时就会生成一个事件。需要对监控项故障一直发送告警通知的场景中使用此项。
Description：触发器的描述信息。可以包含用于解决特定问题的指令，负责人员的联系方式等。也可以像触发器名称一样包含宏变量。
URL：如果定义了URL，在Monitoring -->Triggers页面中点击触发器名称时可以看到一个URL连接，可以使用{TRIGGER.ID}、几个{HOST.*} 宏变量和用户定义的宏变量。如下图8-3所示。
图 8-3
Severity：设置触发器告警级别。
Enabled：勾选此项为启用触发器。
Dependencies标签如下图8-4所示。
图 8-4
点击Dependencies字段中的Add连接，在弹出页面中选择需要依赖的触发器点击Select按钮即可。
介绍完触发器配置页面各参数的含义，下面通过为Zabbix server主机中定义的agent.ping监控项创建触发器的过程来看看触发器创建的步骤。
1、 在Trigger标签中的Name字段中填写触发器的名称，例如Zabbixagent on {HOST.NAME} is unreachable for 5 minutes。在名称中我们使用了宏变量{HOST.NAME}，这样我们在通知中能看到是哪个主机触发告警。
2、 在Expression字段中我们填写表达式。如果对表达式足够熟悉，在这里自己手工输入就可以。或者点击右侧的Add按钮在弹出页面中选择和设置各项参数。如下图8-5所示。
图 8-5
在本例中监控项选择Zabbix server主机中定义的Agent.ping，Function中选择No datareceived during period of time T,then N = 1,0 – otherwise ，Last of（T）中设置时间参数，N中设置常量。点击 Insert按钮返回。此时我们会看到Expression字段中已经有了一个表达式。如下图8-6所示。
图8-6
3、 点击Expression字段下面的Expression constructor测试表达式，在这里也可以构造复杂的表达式。如下图8-7所示。
图 8-7
勾选需要测试的表达式，点击Test进入测试页面，选择表达式返回值VALUE为1，点击Test按钮可以看到表达式的结果，TRUE为1，FALSE为0。如下图8-8所示
图 8-8
4、 需要每次都生成告警事件时选中MultiplePROBLEM events generation。
5、 填写触发器的描述信息。
6、 可选填写触发器的相关URL。
7、 选择触发器的告警级别。
8、 如启用该触发器勾选此项。
9、 该触发器依赖其他触发器时，到Dependencies标签页面中添加。
10、点击Add按钮保存。
Zabbix中的Event（事件）是基于时间戳的，记录某一时刻发生了什么事。事件本身没有什么意义，但在Zabbix告警体系中有很重要的位置，事件是系统生成动作（如发送告警邮件）的基础。
Zabbix中生成的事件类型主要有以下几种：
trigger events（触发器事件）：每当一个触发器的状态发生变化时（OK --> PROBLEM --> OK）生成事件，是Zabbix中使用最频繁和最重要的事件来源。
discovery events（发现事件）：当检测到主机或服务时生成事件。例如，每次Zabbix监测到Service Up或Service Down，Host Up 或Host Down，Host Discovered或Host Lost等。
auto registration event（自动注册事件）：当 active agent 是由服务器自动注册时生成事件。
internal events（内部事件）：当一个监控项或low-level discovery规则变为unsupported（不支持）/ normal（正常），触发器的状态变为unknown（未知）/ normal时生成事件。
在Monitoring --> Events页面中点击事件的日期和时间可以浏览每个事件的详细情况。
当系统中产生相应的事件后，需要发送通知或执行命令等，在Zabbix中如何解决的呢？实际上Zabbix提供了独立的Actions（动作）组件，对系统中产生的多种类型的事件作出响应，动作是完全独立于主机和模板的，每个动作是全局定义的。
每个动作由三个部分组成，分别是：
动作的定义
触发动作的条件
动作执行的操作
在Configuration --> Actions页面右上角，点击Event source下拉框选择事件源，然后点击Createaction按钮进入配置页面。如下图8-9所示。
图 8-9
Action标签中各参数的含义如下：
Name：唯一的动作名称。
Default subject：默认标题，可以包含宏变量。
Default message：默认信息内容，可以包含宏变量。
Recovery message：勾选后，故障恢复正常时（PROBLEM --> OK）会发送一次恢复信息。需要注意的是，要接收一个恢复信息，在action conditions中必须设置Triggervalue=Problem。Trigger value=OK不需要设置，否则恢复信息不会发送。恢复信息从PROBLEM事件中继承acknowledgment状态和历史（当使用{EVENT.ACK.HISTORY} 和{EVENT.ACK.STATUS}宏变量时）。如果在恢复信息中使用 {EVENT.*} 宏变量，它将从PROBLEM事件引用。{EVENT.RECOVERY.*} 宏变量只能在恢复信息中扩展使用，它将从recovery/OK事件引用。
Recovery subject：恢复信息标题。可以包含宏变量。
Recovery message：恢复信息，可以包含宏变量。
Enabled：勾选此项为启用该动作。
在这个配置页面，我们可以给动作配置一个唯一的名称，定义一个默认的信息，在信息中可以引用特定事件有关的数据，例如主机、监控项或触发器的名称，监控项和触发器的值，还有URL等。
当我们创建动作时，系统在默认的信息中已经使用了一些宏变量。实际上，由于动作是全局的，所有在Zabbix中定义的宏变量都可以在动作的信息中使用。另外触发器能够从多个主机监测多个监控项，你可以引用所有涉及到的主机和监控项（最多9个不同的主机或监控项）。通过使用这些宏变量可以提供丰富的信息内容，当你看到发送的信息时能够了解故障相关的详细信息。
默认的信息可以通过多种方式发送，例如通过邮件、SMS、chat等，可以在动作中定义使用不同的告警发送方式发送信息。
一个事件只有匹配定义的conditions时action才会执行。在Conditions标签页面中我们可以定义基于事件的主机、触发器和触发器值的conditions，在这里可以通过AND/OR结合不同的单一条件组合成我们需要的conditions。如下图8-10所示。
图 8-10
Conditions标签页面中各参数的含义如下：
Type of calculation：运算类型（各condition之间的逻辑运算符）。选项有：
AND：所有条件必须同时满足。
OR：满足条件中的一个即可。
AND/OR：条件的组合。不同类型的条件用AND，同类型的条件用OR。例如。
Host group = Oracle servers
Host group = MySQL servers
Trigger name like 'Database is down'
Trigger name like 'Database is unavailable'
结果为：
(Host group= Oracle servers or Hostgroup = MySQL servers) and (Trigger name like 'Database is down' orTrigger name like 'Database is unavailable')
Custom expression：用户自定义的计算公式，公式中必须包括所有的条件（大写的A、B、C等），and或者or（小写），也可以包括空格、制表符和括号。在AND/OR中的例子表示成(A or B) and (C or D)，自定义的表达式可以是多种形式的，如：(A and B) and (C or D) ，(A and B) or(C and D) ，((A or B) and C) or D 等等。
Conditions：添加的条件。
New condition：选择要添加的条件，根据不同的事件来源可供选择的项目会有所不同。支持的操作符有：
= 等于
<> 不等于
like 包含
not like 不包含
每次创建动作时，系统会自动添加两个条件（可以删除）：
Trigger value = PROBLEM：只在PROBLEM时发送信息。如果你想接收一个恢复信息，这个条件必须设置。
Maintenance status = notin maintenance：主机维护期间不发送信息。
如果触发器的状态从OK变成PROBLEM，当前触发器的状态为PROBLEM。如果触发器的状态从PROBLEM变成OK，当前触发器的状态为OK。
通过Operations标签中的设置，可以定义动作中实际要采取的操作，主要有两方面组成：一方面是定义操作的steps（步骤），另一方面是定义每个步骤中实际的操作。
最简单的场景就是只定义了一个步骤，在这个步骤中将默认的信息发送给一组已定义的收件人。但在实际环境中，特定需求会让场景变得越来越复杂，需要定义多个步骤和操作。
点击Operations标签并点击Actionoperations中的New链接，操作的配置页面如下图8-11所示。
图8-11
Operations标签页面中各参数的含义如下：
Default operation step duration：每个操作步骤中默认的时间间隔，最小为60秒。
Action operations：显示动作中定义的操作。
Operation details：每个操作的详细配置。
Step：定义操作的步骤。如上图中是从1到1。这里需要注意如果定义成0意味这个这个步骤会一直执行下去，直到触发器的状态发送变化。
Step duration：步骤中使用的时间间隔。最小为60秒，如设置为0则使用Default operation step duration 中定义的值。多个操作可以分配给相同的步骤，如果这些操作使用不同的Step duration，则使用定义最短的时间间隔。
Operation type：操作类型是send message。
Send to user groups：点击Add去选择接收信息的用户组，这个用户组在主机上至少要有读权限。
Send to users：点击Add去选择接收信息的用户，这个用户在主机上至少要有读权限。
Send only to：发送信息到所有定义的media（告警方式）或选定的用户。
Default message：如果选中，将发送定义的默认信息。
Subject：自定义信息的标题。
Message：自定义信息的内容，内容中可以使用宏变量。
Operation type：操作类型是remote command
Target list：选择在当前主机（current host）、其他主机或主机组中执行命令。
Type：选中命令的类型：IPMI、Custom script、SSH、Telnet或Global script。
Execute on：在Zabbix agent或Zabbix server上执行。
Commands：需要执行的命令。
Conditions：执行操作的条件，Not Ack为仅在没有对事件响应时执行，Ack为仅在对事件响应后执行。
在所有事件中都可以定义的操作有：
发送信息（sendmessage）
执行远程命令（remotecommand）
Discovery 事件中可以定义的操作有：
add host（添加主机）
remove host（删除主机）
enable host（启用主机）
disable host（禁用主机）
add to group（添加到组）
delete from group（从组中删除）
link to template（链接到模板）
Unlink to template（取消到模板的链接）
set host inventory mode（设置主机资产记录的模式）
auto-registration事件中可以定义的操作有：
add host（添加主机）
disable host（禁用主机）
add to group（添加到组）
link to template（链接到模板）
set host inventory mode（设置主机资产记录的模式）
当出现故障时通过发送告警信息是通知管理者最简单有效的方法，也是Zabbix中使用最多的方法。
为了能正常发送和接收信息，首先需要定义media（告警方式）和使用该media的信息接收人（用户），其次需要配置动作。信息接收人必须对这些主机产生的事件有读权限，能够正常访问触发器的表达式，否则信息发送不会成功。
信息发送的情况可以通过Monitoring --> Events页面中查看，在页面Actions列中可以看到完成动作的统计信息，绿色的数字表示发送信息，红色的In progress表示正在执行action，Failed表示动作执行失败。如果点击事件的日期和时间的链接，在事件详细页面中的Message action中可以看到该事件中详细的信息发送成功或失败的情况。在Reports --> Action log页面中可以看到所有动作详细情况。
在Operations标签中，点击New链接添加step，选择Operation type为Send message，如下图8-12所示。
图 8-12
在上图8-12中，配置了step 1 到 5，每过10分钟发送一次信息。
当满足条件时可以在被监控主机上执行事先定义好的命令，完成一些特定的任务，例如：
一些应用（web 服务器、中间件、CRM等）没有响应时自动重启。
服务器不响应时使用IPMI重启服务器。
磁盘空间满后清除无用的文件释放空间。
根据CPU负载情况把虚拟机从一个物理机迁移到另一个物理机。
当一个云基础设施中的资源（CPU、内存、磁盘等）添加或删除新的节点。
配置远程命令的动作和发送信息的动作类似，不同的只是定义的操作类型不同。配置远程命令的动作时有一些限制，远程命令不能超过255个字符；不支持active agent方式；不支持由Zabbix proxy监控的Zabbix agent上执行远程命令（如果需要建议从Zabbix server 直接连接到agent）。远程命令中可以包含宏变量，也可以执行多行命令。需要在Zabbix agent上支持命令（customscripts）时，必须在zabbix_agentd.conf中将EnableRemoteCommands参数设置为1，并重启zabbix agent服务使配置生效。
下面通过一个例子看一下配置远程命令的步骤。
在Configuration --> Actions页面右上角，点击Event source下拉框选择事件源，然后点击Createaction按钮进入配置页面。在Action标签中配置名称和默认信息，在Conditions标签中配置条件，如下图8-13所示。
图 8-13
在Operations标签中添加操作，operationtype选择remote command。如下图8-14所示。
图 8-14
在本例中Zabbix将通过命令 sudo/etc/init.d/apache restart重新启动Apache服务，要确认命令可以在Zabbix agent上执行，需要配置zabbix用户能够执行sudo。
# visudo
zabbix ALL=NOPASSWD: ALL # 允许zabbix用户运行所有的命令时不需要密码
或者配置zabbix用户只执行重启apache服务
zabbix ALL=NOPASSWD: /etc/init.d/apache restart #只允许重启apache服务
即使动作依赖于一个单一的事件，也并不是说它只能执行一个单一的操作，实际上，它可以执行任意数量的操作，甚至是在无限长的时间内或直到执行操作的条件发生变化。完成这些需要我们配置Escalation（告警升级）。在多个Escalationstep中可以同时发送告警信息或自动化执行命令，可以将告警信息发送到不同的用户组或用户，也可以在故障没有解决或事件没有acknowledged（响应）之前同一信息定期重复发送。
通过Escalation配置可以实现灵活多变的告警，我们可以实现：
发生故障后第一时间通知用户。
可以重复发送告警通知直到故障解决。
延迟发送告警通知。
告警信息可以逐级发送，根据情况可以设置将信息发送给部门经理或更高级的用户。
远程命令可以发生故障后立即执行，也可以在一段时间内没有解决故障后执行。
可以发送故障恢复信息。
下面我们通过举两个例子来看看，例子一的配置如下图8-15所示。
图 8-15
从上图8-15中我们看到step 1是立即执行的，发送信息到一个用户组，然后延迟1分钟执行后续步骤。一分钟后开始执行step 2，在主机上执行远程命令。在step 2中使用了默认的时间间隔3600秒，因此在过了1小时后开始执行step 3，步骤3、4、5的配置是相同的，每隔10分钟会发送信息到用户组。30分钟后开始执行step 6，在这个步骤中我们添加了一个条件Event acknowledged = Not Ack，因此事件还没有响应时会发送信息到admin用户。你可能注意到step 6的下一个步骤是step 0，step 0 的意思是永远执行这一步，它会按照步骤中设置的Duration(sec)这个时间间隔不断重复的执行下去，直到触发器的状态发生变化。但是如果你在动作中没有使用Trigger value = PROBLEM这个条件，即使触发器状态变成OK时step 0也会一直执行下去，因此需要设置step 0时一定要小心。
例子二配置如下图8-16所示。
图 8-16
动作中默认操作步骤时间间隔是1800秒，开始执行后Step 1 - 4 分别在0:00、0:30、1:00、1:30给MySQL administrators发送信息。Step 5和6在2:00和2:10给Database manager发送信息（step 6不是3:00发送信息，是因为后面step 5 - 7中设置的600秒覆盖了step 5-6中的设置）。Step 5 - 7在2:00、2:10、2:20发送信息（step duration设置时600秒）。Step 11在4:00发送信息（step 8 – 11使用默认的时间间隔1800秒）。
在实际环境中使用告警升级时需要注意下面一些情况：
在主机进入维护状态时，正在执行的动作中定义的操作会继续执行，维护状态只影响动作，对动作中定义的操作没有任何影响。
动作中定义的Timeperiod结束时，正在执行的动作中定义的操作会继续执行，Timeperiod只影响动作，对动作中定义的操作没有任何影响。
维护状态中发生故障，并在维护状态结束后还没有解决时，动作中定义的告警升级步骤在维护结束后开始执行。
在无数据的维护期间发生故障直到维护结束后还没有解决时，必须等触发器触发后才能执行定义的告警升级步骤。
不同告警升级步骤的配置重叠时，每一个新的告警升级的执行将取代前面的告警升级，前面的告警升级不管有多少步骤，至少执行一步。
告警升级执行过程中，如果出现动作禁用、基于触发器的事件删除、触发器禁用或删除、触发器相关的主机或监控项禁用、监控项禁用或删除、主机禁用等情况时，正在发送中的信息和告警升级中配置的其他信息会被发送。只是后面发送的信息中会加上(NOTE: Escalation cancelled)，比如说动作禁用时会在信息前加上NOTE: Escalation cancelled: action '<Action name>' disabled，通过这种方法通知用户取消告警升级。取消的原因也可以通过设置Debug Level = 3从日志文件中查看。
告警升级执行过程中动作被删除后，不会在发送信息。设置Debug Level = 3时从日志文件中可以查看，如escalationcancelled: action id:334 deleted。
本文出自 http://ustogether.blog.51cto.com/8236854/1929384，如需转载请与作者联系。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
