有了好的监控项，也还得有好的触发器，才能有效触发zabbix报警动作，杂乱无章的触发器只会增添zabbix报警系统的负担，同时也给运维人员带来的大量的垃圾信息，所以一个好的监控系统中，触发器的设计也是需要动脑子的。当然今天在这里也只不过抛砖引玉，给大家简单示范一下。
正常来说，比如磁盘使用率达到60%，可能就需要引起运维人员的关注了，达到80%时就必要及时进行报警处理了，否则可能因数爆盘带来的失误就不可容忍了。
当然，类似于这类的触发器添加起来，可能也就相对简单了，无碍乎60%定义为告警等级，80%定义为严重等级，60%可以让zabbix发一封邮件给运维人员，80%时就让zabbix发一条短信给运维人员。
触发器详细定义过程
触发器的表达式可以直接手写，但这需要对zabbix的语言非常了解，不适合大众使用，可以点击add进行表达式的构造合成，详细过程如下
使用率达到80%的触发器只是等级不同，还有就是函数N的赋值不一样而已
表达式构造详细页面
这里只是简单的带大家一起创建了一些简单的触发器，实际运用中，多个触发器之间可能存在一定的依赖关系，比如说php-fpm是需要前端的nginx传送应用需求过来的，但nginx端口的运行是建立在主机没有宕机的情况之上的，所以这一系列的触发器之间就存在比较清晰的依赖关系了，nginx依赖于主机不宕机，php-fpm依赖于nginx服务正常运行。
这里需要说明一下的是443端口是nginx提供的https服务作为后台网站使用的
Add按钮添加表达式
添加依赖主机不宕机的触发器
依赖页面添加对应依赖监控项
添加成功后的结果
接下来再配置php-fpm依赖于nginx服务运行的触发器
php-fpm依赖于nginx服务运行的触发器配置成功如下图所示
再这里简单陈述一下逻辑关系最终生效的效果，就是当被监控服务宕机后zabbix服务器端获取不到back.port.443和php.port.9000端口状态的数据时，不会额外去触发back.port.down和php.port.down这两个触发器，而是直接触发一个host.offline一个触发器。对于被监控服务器来说，主机都已经宕机了，nginx服务和php服务很显然端口监听也是失败的，但此时，还让zabbix服务器端这两个服务不可用已经没有实质性的意义了。最终所实现的一个终极思想就是一次报警直接定位根本问题。
补充板块
zabbix异于模版的监控项及触发器的设计
对于异于模板的item个例，可以先禁用对应主机上的模版监控项，并克隆该监控项，进行修改后即可单独应用于此主机，触发器也是如此。
克隆异于模版的监控项，修改后单独应用于此主机，如下图所示
克隆异于模版的触发器，修改后单独应用于此主机，如下图所示
注意：模版上原有的监控项或者触发器名称前面都会带有模版的名称，而单独属于此主机的就只有监控项或者触发器自身的名称。
下面以克隆原有模版上的触发器为例，简单展示一下操作过程
这是原有模版的触发器内容，需要做如下操作
至此一个触发器的设计思想给大家分享完了，希望之前对触发的依赖关系不太明白的，读完本文能够有所帮忙，如果觉得本系列博文读后之后有所帮忙的朋友，帮忙点个关注加个赞！
错误之处，还望高人留言指正。
原文地址：http://blog.51cto.com/183530300/2087796