通常，一个报警的产生，是这样的一个过程。
如果某种条件符合，那么报警。
抽象成计算机语言，就是：
if (ConditionA == true){
Alet();
}
还可以选择给谁报警（哪个用户）、怎样报警（报警途径），具体如下：
if (ConditionA == true){
Alert(userA.email);
Alert(userB.sms);
}
如果处理问题不一定要报警，可以在服务器对于一些简单问题上运行一些命令的初步处理，比如Nginx挂了，自己就可以尝试的重启服务，则这又成了：
if (ConditionA == true){
Alert(email);
Alert(sms);
Excute(command);
}
再扩展一些，可能条件更复杂一些：
if (ConditionA == true && ConditionB != true){
Alert(email);
Alert(sms);
Excute(command);
}
这就是Zabbix的“报警”了，为什么这里的“报警”需要加上引号呢？ 其实，发生问题后，去执行一些命令，这已经不是狭义上的“报警”了。在Zabbix 中，这个被定义为Action（动作） ，就是当某种Condition符合时，会进行一些操作，这些操作就叫做Action。 Condition译为“条件”，在Zabbix中，Action的触发是需要条件的，比如属于某个Host Group的Host，某个Trigger是Problem状态了，等等，，
在Zabbix中，报警的途径是依附于用户的。即不能直接将一个Action设置为给某个邮箱发邮件，一定要设置Action向某个用户发送报警，发送报警的途径是邮箱，那么就会发送到用户的预先设置邮箱地址。 这个邮箱地址叫做用户的Media ，即联系方式。
下面来介绍Action的设置。
1，Action
Action是Zabbix非常强大的功能，可以基于Event的不同状态，执行不同的操作。 最常见的就是报警时，将报警通过各种方式发送给对应的用户。
目前Zabbix支持Action动作根据下面所列出的Events触发。
- Trigger Events：当Trigger的状态变化，即从OK 到 Problem 或从 Problem 到OK时都会产生。
- Discovery Events：当发生网络Discovery的时候产生。
- Auto Registration Events： 当有新的Zabbix Agent自动注册到Zabbix的时候产生。
- Internal Events：当Item变为“异常”状态 或者Trigger变为“未知”状态时产生。
下面进入Action的配置。
- 从菜单栏的“Configuration” → “Actions” 进入界面。
- 在“Event source”下拉框中，可以选择只显示依赖于某种源头的Action。
- 单击Action条目后，可以看到三个标签：“Action”、“Condition”、“Operations”。 “Action”用来定义Action本身的一些属性和说明；“Condition”用来定义触发Action的各种条件组合关系；“Operations”定义的是Action触发后的一些操作。
默认是建立基于Trigger Events的Action，如果需要其他的，选择对应的选项即可。
“Action”标签，有下面的属性可以设置。
- Name：唯一的Action名字。
- Default subject：报警的默认标题。
- Default message：报警的默认内容。
- Recovery message：恢复消息，是否在报警恢复正常后发送消息。 Zabbix将“OK”状态的Trigger认为是一个恢复recovery event。 注意：如果使用了Escalation机制，Recovery event只会触发一次。对已Recovery的报警，可以像发出报警的邮件一样，设置报警标题和内容。
以下几点需要注意：
1，自定义的恢复信息，只针对Condition，是“Trigger value is PROBLEM”的生效。
2，恢复信息只会发送给那些之前收到过关于这个Action报警信息的人。
3，恢复信息和Action 依赖PROBLEM生成的Evnet维护同一份ACK状态。
4，在Recovery信息中，EVENT.*Macro中的数据，都是基于出问题的Event，而不是Recovery。
5，在Recovery信息中，EVENT.RECOVERY.* 表示的是出自Recovery event的数据。
- Recovery subject：Recovery信息的标题。
- Recovery message：Recovery信息中的内容。
- Enabled： 是否启用这个Action。
2，Operation
Operation指的是Action触发以后具体的操作，在Zabbix中，可以定义下面这些操作：
- 发送一条信息。
- 执行一个命令（包括IPMI）。
对于discovery事件，还有额外的一些操作：
- 添加一个Host。
- 移除一个Host。
- 启用一个Host。
- 禁用一个Host。
- 将Host添加到一个Host group。
- 将Host从一个Host grou中删除。
- 关联到一个Template。
- 取消和一个Template的关联。
对于auto-registration事件，也有额外的一些操作：
- 添加一个Host。
- 禁用一个Host。
- 添加Host到一个Host group。
- 关联到一个Template。
在配置Action的Operation标签页时，可以看到目前配置的Operation，单击“New”按钮。
随后会出现配置一个新的Operation的界面
以下对各部分进行详细说明。
- Default operation setp duration：最小是60秒，若设置为1小时（即这里的3600秒），则表明执行了一个操作后，要等待1个小时，才会执行下一个操作。
- Action operations：需要设置的有Steps、Details、Start in、Duration（sec）和Action。
-
- Steps：在escalation（报警的升级和扩散）的时候，会按照Step的顺序来执行，从1开始。
- Details：操作的类型和目标。 从Zabbix 2.2开始，还会显示在发送信息时的media type（通知类型），用户的名字也会显示。
- Start in：在Event发生后多久执行操作。
- Duration（sec）：显示的是Step的持续时间，如果Step使用了默认的“Default持续时间”，那么显示“Default”。
- Action：显示的是两个标签“Edit”和“Remove”，用来编辑和移除Operation的操作。
- Operation details：用来设置一个Operation的具体设置。
下面我们来看看Operation details的设置。
- Step：在Escalation的过程中的执行计划。
- From：表明从哪一步开始。
- To：表明到哪一步结束。
- Step duration：每一步持续的时间，如果填0，就是用上面的“Default operation setp duration”中的值。可以在同一个步骤中，进行多个操作。如果这些操作有多个duration，那么会选择最短的那个生效。
- Operation type：选择操作的类型，可以选择的有如下两种。
- Send message：给用户发送信息（邮件，SMS信息 等，，）
- Remote command：远程执行命令。
注意：对于discovery事件和auto-registration 事件，可以在这里选择更多的操作。
Operation具体执行的操作是Operation的核心。在Zabbix中，“Send message”和“Remote command”是最重要的两个Operation。
报警的核心是什么？其一，是将问题通知到负责人； 其二，是对报警有对应的措施。 前者对应的是“Send message”功能，后者对应的是“Remote command”功能。
比方说，当一台PHP服务器的PHP进程意外退出后，Zabbix一边发送邮件给负责人，一边向Zabbix Agent发出命令，让他重启PHP服务器上的PHP进程。这是非常棒的处理流程。
下面，一起看下如何订制Operation。
首先看“Send message”，这个应该是所有Action都会具备的Operation。就算能够自动恢复（比如PHP进程重启），也需要将出错的信息及时发送给负责人。 对于“Send message”的配置有如下几点。
- Send to User groups：可以添加一些User Group，将报警批量的发送给User Group中的所有User。
- Send to User：类似于“Send to User groups”，只是发送警报的对象换成用户。
- Send only to：选择是给“Send to User groups” 和 “Send to User”中发送消息时使用的Media type。 比如选择了“Email” ，那么就会向前面的User 发送电子邮件。
- Default message：使用默认的消息格式。 默认这个是被打上勾的，取消选择，可以看到默认定义的消息格式。
- Conditions：在后面进行介绍，因为它的设置是“Send message” 和“Remote command”所共有的。
注意，追鱼一个Host的报警，Zabbix只会把这个报警发送给这个Host至少有“读”权限的用户。Trigger中至少一个表达式关联的Host是正常工作的，即在Host中看到绿色的标识，
对于发送出去的消息，怎么查看历史消息呢？ 怎么获知什么时间发送了什么消息呢？
在Monitoring→Events中可以看到有触发的Action列表。红色表示Action是失败的；“In progress”表示Action已经被触发了； “Failed”表示没有Action触发成功。
我们单击Event的时间，可以看到Action的细节，包括发送了信息的具体内容。
同时，我们也可以通过“Administration”→“Audit”在过滤条件中选择Action 就可以看到过去一段时间内发生的所有Action。
“Remote command”的参数有以下几种。
- Target list：选择命令执行的Host，可以选择发生问题的Host，指定某个Host 或者 Host group。
- Type：选择执行的命令的类型，其中“IPMI”、“SSH”、“Telnet”很好理解，主要看剩下的两个。
- Custom script：执行在Commands 对话框中的Shell命令。
- Global script：执行在Administration→Scripts中定义的一些命令。
- Excute on：可以选择在Zabbix Agent还是Zabbix Server 上运行命令。
- Conditions：后面进行单独介绍。
Remote command 最大的好处是什么呢？ 是自动。 Zabbix会根据配置的条件，去执行对应的命令，下面看看Remote command的应用场景。
- 应用无法响应时，自动重启某些应用。
- 当服务器不响应时，使用IPMI的“reboot”命令重启服务器。
- 在磁盘要满了的情况下，自动删除一些文件（比如/tmp）。
- 根据CPU负载，自动进行虚拟机调配。
- 弹性计算，根据系统情况，新增或删除云节点。
Zabbix无法通过Zabbix Proxy向Zabbix Agent发送，一定要从Zabbix Server 发起。而且，发送的命令长度也有限制，即不能超过255个字符，这个对于一般命令绰绰有余了，只要不是cat某个文件之类的，都足够了。如果在多行写多个命令，Zabbix会按照顺序执行。而且在Remote command中，还支持Macro定义。
相比上面介绍的发送消息，Remote command稍显复杂。在Agent上执行的自定义脚本（即Custom scripts）一定要在Zabbix_agentd.conf中预先定义，而且在zabbix_agentd.conf中“EnableRemoteCommands”这一项要设置为1，否则无法远程执行命令。这是必然的，因为Active默认的Zabbix Agent其实根本没有在服务器上安装Zabbix Agent，怎么能发送命令给它执行呢？
对于远程执行命令，权限也是个问题。 默认情况下，Zabbix是没有权限来重启系统服务的，如果Zabbix用户想要有某个权限，需要修改下sudoer文件。
$ vim sudoer #允许“Zabbix”用户不需要密码就可以运行所有root权限的命令 zabbix ALL=NOPASSWD: ALL #允许“zabbix”用户可以在不需要密码的情况下运行/etc/init.d/httpd restart ，即重启apache zabbix ALL=NOPASSWD: /etc/init.d/httpd restart
如果Host上某一类的Interface有多个（比如有多个Zabbix Agent实例），那么Zabbix会选择默认的去运行。
对于剩下的“Coditions”，它有两个选项“Not ACK” 和 “ACK”， “ACK”是“Acknowledge”的缩写，在Zabbix中，以为某个Evnet是否被人“认领”了，可以理解为，有没有在处理这个事情。 这里的“Not ack”和 “Ack”表达的在这种情况下需要执行Operation。如果选择“Not ack”，那么只有当Evnet没有被“Ack”的情况下需要执行。
3，Condition
报警，肯定是基于某个条件的，比如某个服务器的CPU负载超过20%。 在Zabbix，这种“条件”就是Trigger，那不能对每一个Trigger都设置一个Action吧？ 最好的办法就是定义某一类的Trigger如果出问题了，就同意触发某个Action。Zabbix就是这么做的，它在Trigger和Action之间，抽象了一个Condition的概念。“Condition”的中文意思是“情况”，可以理解为某一种条件。即Action不是直接和Trigger挂钩，而是可以配置一组条件，如果都满足这些条件，就执行Action。 比如CPU负载超过20%这个Trigger，可能对于消耗CPU的服务器来说不需要报警，但是对于不消耗CPU的服务器来说就需要了。 那么可以组合这两个条件“CPU负载超过20%”和“服务器是CPU密集型”，对应到Zabbix，就是“CPU>20” 且 “Host属于CPU Host group”。
最常用的是基于Trigger的Evnet，在下表中，提到的Host等，指的都是和这个Event相关的Trigger中关联的Host。