一，触发器是什么
触发器(triggers)是什么？触发器使用逻辑表达式来评估通过item获取到得数据是处于哪种状态，item一收回数据，讲解任务交给触发器去评估状态，明白触发器是怎么一回事了把？
在触发器表达式中我们可以定义哪些值范围是合理，哪些是不合理的，如果出现不合理的值，触发器会把状态改为PROBLEM。接下来就到了报警以及发邮件,这步在讲完触发器之后开始讲。
触发器状态
| 值 | 描述 |
|---|---|
| OK | 触发器的正常状态. 老版本的zabbix中叫做FALSE |
| PROBLEM | 非正常状态,例如数据库挂了,系统负载高了,都会是这个状态. 老版本的zabbix中叫TRUE |
zabbix server item每次获取到一个新值都会使用触发器表达式计算它的状态如果使用基于时间的表达式 (例如：nodata(), date(), dayofmonth(), dayofweek(), time(), now()), zabbix timer每30秒会重新计算一次
二，创建触发器
2.1 创建触发器，点击Configuration（配置） → Hosts（主机） → 相关行的trigger → 点击右上角的创建触发器（create trigger）→ 指定最后一次入站流量大于500B则触发。
Multiple PROBLEM events generation：依赖于当前触发器的“Problem”状态生成其它事件；
Description：当前触发器的描述信息；
URL：在screen的“Status of Trigger”中显示的内容的链接；
Severity：当前触发器的严重级别；
Enabled：是否启用当前触发器；
触发器表达式高度灵活，可以以之创建出非常复杂的测试条件
基本的触发器表达式格式如下所示：
- {<server>:<key>.<function>(<parameter>)}<operator><constant>
server：主机名称；
key：主机上关系的相应监控项的key；
function：评估采集到的数据是否在合理范围内时所使用的函数，其评估过程可以根据采取的数据、当前时间及其它因素进行；
目前，触发器所支持的函数有avg、count、change、date、dayofweek、delta、diff、iregexp、last、max、min、nodata、now、sum等
parameter：函数参数；大多数数值函数可以接受秒数为其参数，而如果在数值参数之前使用“#”做为前缀，则表示为最近几次的取值，如sum(300)表示300秒内所有取值之和，而sum(#10)则表示最近10次取值之和；
此外，avg、count、last、min和max还支持使用第二个参数，用于完成时间限定；例如，max(1h,7d)将返回一周之前的最大值；
operator：表达式所支持的运算符及其功能如下表所示
查看最近一次数据的图像：Mnitoring → Lastest Data
2.2，执行动作(action)
在配置好监控项和触发器之后，一旦正常工作中的某触发器状态发生改变，一般意味着有异常情况发生，此时通常需要 采取一定的动作(action)，如告警或者执行远程命令等，并非所有的触发器状态发生改变的场景都需要对其进行干预，如转变为“OK”状态时，相应地，如果触发器的状态转变为“Problem”，就需要告知所有关心其相关监控指标的人员了，“通知(notification)”是zabbix中最常用的“动作”之一。
Jabber：jabber消息；Jabber是一个开放的、基于XML的协议，能够实现基于Internet或LAN的即时通讯服务；
自定义的通知脚本：以上方式不能满足需求时，zabbix可以调用位于其配置文件“AlertScriptsPath”变量所定义的脚本查找目录中的脚本来完成通知功能；
动作由“条件”和“操作”组成，它的逻辑为当“条件”满足时，就执行相应的“操作”
“发送通知”和“执行远程命令”是两个最基本的操作
Zabbix的事件是基于时间戳进行标记的，它们是采取动作(action)如发送邮件通知的基础，其主要来源于三种途径:触发器(trigger)事件：触发器状态每次发生改变，都会生成相应“事件”，且通常包含详细信息，如发生的时间及新的状态等；
发现(discovery)事件：zabbix会周期性地扫描“网络发现规则” 中指定的IP范围，一旦发现主机或服务，就会生成一个或几个发现事件；
发现事件有8类：Service Up、Service Down、Host Up、Host Down、Service Discovered、Service Lost、Host Discovered和Host Lost；
主动agent自动发现事件（也称作“自动注册事件”）：当一个此前状态未知的主动agent发起检测请求时会生成此类事件；因此，Zabbix的通知机制也称作基于事件的通知机制，也只有理解了事件本身，才能定制出符合需求的通知系统
Default subject：默认的消息主题，可以使用宏；
Default message：默认的消息，可以包含宏；
Recovery：监控项从“问题”状态恢复之后是否发送的消息；如果启用，恢复消息仅发送给监控项转换为“问题”状态时的通知对象；
Recovery subject：恢复消息主题，可以包含宏；
Recovery message：恢复消息，可以包含宏；
Enabled：是否启用当前action；
定义报警机制，首先设置Administration → Media types，设置使用邮件进行报警：
然后添加action：
2.3 定义Operation，zabbix支持的操作有两类：“发送通知”和“执行远程命令”，而对于“发现”类事件来说，其支持的操作还有添加主机、移除主机、启用主机、禁用主机、添加到组、从组中删除、链 接到模板及从模板上拆除关联等，对于“自动注册”类事件来说，支持的操作为添加主机、禁用主机、添加到组及链接至模板等。
To：直到哪一步为止，其减去From中的数字再加1即表示要操作的次序；0表示无限；
Step duration：前述自定义告警升级的时间间隔，0表示使用默认；
Operation type：操作类别；选定不同的操作类别，其后续的其它属性也有所不同；
Send message：发送消息；
Remote command：执行远程命令；
Conditions：执行操作的条件；
Not ack：仅在事件为“未知(unacknowledged)”时执行操作；
Ack：仅在事件可被识别(acknowledged)时执行操作；
类别为“Send message”时的相关属性：
Send to User groups：给选定组中的所有用户发送通知；
Send to users：给选定的用户发送通知；
Send only to：发送通知时所使用的媒介，all为所有媒介；
Default message：如果启用，则发送默认消息；
Subject：消息的自定义主题，可以包含宏；
Message：要发送的消息内容，可以使用宏；
类别为“remote command”时的相关属性：
Target list：远程命令执行的目标主机，可以是当前主机、其它主机或主机组；
Type：命令类型；
IPMI：IPMI命令；
Custom script：自定义脚本，可以选择其是在zabbix server上还是zabbix agent上执行；
SSH：通过ssh执行命令，需要提供目标主机上的用户帐号、相关的认证方式及认证所需要额外信息；
Telnet：通过telnet执行命令，需要指定用户名、口令及远程主机telnet服务监听的端口；
Global script：全局脚本，执行“Administration→Scripts”定义的脚本的其中之一；
Commands：要执行的命令；
在operations中定义告警前第一步到第二步所执行的补救措施，头两步先执行远程命令，不发邮件，这里使用重启httpd服务为例，其他的可自行定义：
由于告警时需要将邮件发送给不同的组或人，例如admin，cto等，所以需要先定义相关的组。先创建三个组，manager，CTO，zabbix user。
创建三个组：
创建admin和cto：
2.4 告警升级(escalation)
按需延迟发送通知；
问题长久得不到解决时发送给级别更高的用户；
立即执行远程命令或经过一个预定的时长后仍未解决问题时执 行远程命令；
故障恢复时发送相关信息；
实际操作中，action的escalation机制的实现依赖于“escalation step(升级步长)”，step是一个时间长度；为了简化操作过程，可以为step定义默认的时长，只有在必要时才为action自定义其step，可以在任何有效的step到达时启动action，第1个step表示立即启动；如果要延迟启动action，可以选择在后面的其它step上启动。
接着上面的action，定义第三步到以后执行的告警，若重启服务依然故障，则给管理员发送邮件：
若第10步以后，问题仍没有解决，则给CTO发送邮件：
执行操作的条件 Conditions :
触发器及action已经定义完成，后面继续介绍Zabbix的其他功能。
