Zabbix 监控之 - 报警篇 Actions

通常，一个报警的产生，是这样的一个过程。

如果某种条件符合，那么报警。

抽象成计算机语言，就是：

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的配置。

1. 从菜单栏的“Configuration” → “Actions” 进入界面。

2. 在“Event source”下拉框中，可以选择只显示依赖于某种源头的Action。

3. 单击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中，可以定义下面这些操作：

1. 发送一条信息。

2. 执行一个命令（包括IPMI）。

对于discovery事件，还有额外的一些操作：

1. 添加一个Host。

2. 移除一个Host。

3. 启用一个Host。

4. 禁用一个Host。

5. 将Host添加到一个Host group。

6. 将Host从一个Host grou中删除。

7. 关联到一个Template。

8. 取消和一个Template的关联。

对于auto-registration事件，也有额外的一些操作：

1. 添加一个Host。

2. 禁用一个Host。

3. 添加Host到一个Host group。

4. 关联到一个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的应用场景。

1. 应用无法响应时，自动重启某些应用。

2. 当服务器不响应时，使用IPMI的“reboot”命令重启服务器。

3. 在磁盘要满了的情况下，自动删除一些文件（比如/tmp）。

4. 根据CPU负载，自动进行虚拟机调配。

5. 弹性计算，根据系统情况，新增或删除云节点。

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。

本文出自 “Professor哥” 博客，转载请与作者联系！