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