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’）
