3.12.5 自学Zabbix3.12.5-动作Action-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”。

1. 四种Condition介绍

1.1. 最常用的是基于Trigger的Condition:

在下表中提到的Host等，指的都是和这个Event相关的Trigger中关联的Host。

如果设置的Condition中的任何一个对象（Host等）被删除了，那么这个相关的Condition会被删除，这个Action也会被禁用，放置出现错误执行Action，并且只能由用户自己重新启用。

Trigger的值是会变的，如果设置了“Trigger = Problem”，表示的是当Trigger从OK 变成PROBLEM的时候会被触发。反之亦然。

注意：

使用 Trigger name like Traffic change > 400Mbps 类型的Contidions的时候 Traffic change > 400Mbps 不要跟容易引起歧义的关键字（当然你的Trigger名称可以包含该关键字），比如like的关键字是 Traffic change > 400Mbps Trigger 否则可能不会触发Action。

当创建一个Action的时候，默认会有两个Condition：

一个是“Trigger=PROBLEM”，
另一个是“Maintenance status=not in maintenance”

为什么Zabbix要有这两个Condition呢？

一般来说，我们的Action都是在某样东西出问题才需要行动的，而且，这个东西还不能是在维护中，否则明明有人维护这台服务器，Zabbix还在使劲的报警，就不好了。

1.2. 基于Discovery 的Event可以使用的Condition

1.3. 基于Active agent auto-registration的Condition

1.4. 基于Zabbix内部事件的Condition

Event type中的事件类型有以下几种。

Item是“not supported”状态。
Item是“Normal”状态。
Low-level discovery 规则是“not supported”状态。
Low-level discovery 规则是“normal”状态。
Trigger是“unknown”状态。
Trigger是“normal”状态。

2. Condition的组合

Zabbix支持的Condition之间的逻辑运算符有以下几种：

AND：所有Condition同时满足。
OR：所有的Condition满足一个就行。
AND/OR：根据选择的条件，自动调整。选择相同类型的Condition时，他就变成and；选择而不同的Condition，它就变成OR。

比如有下面这些Condition：

Host group = Oracle servers
Host group = MySQL servers
Trigger name like ‘Database is down’
Trigger name like ‘Database is unavailable’

那么最后组合的Condition就是（Host group = Oracle servers OR Host group = MySQL servers）AND （Trigger name like ‘Database is down’OR Trigger name like ‘Database is unavailable’）

posted on 2018-01-08 08:16 CARLOS_KONG 阅读(454) 评论(0) 编辑收藏举报

刷新页面返回顶部

CARLOS_KONG

自学Zabbix3.12.5-动作Action-Condition配置