一、zabbix 的 item 数据采集
1、数据采集是 zabbix 的基础,也是监控基础,目前可以支持主动、被动两种采集模式。主动模式定义为:客户端主动上报数据到服务器端,被动模式定义为:服务器到客户端采集数据。
2、大家常用的是主动采集模式,主动采集方式除了 zabbix 自带的常用采集项,可以通过自定义采集项来进行扩展。例如需要做 1 个针对系统全流程的语义监控功能,就可以写一个脚本,通过自定义采集项来获取脚本执行的结果。
3、有时候部署 agent 比较麻烦,可以直接使用 zabbix 的 trapper 方式:被监控主机主动发送数据给 zabbix server,通常可以应用于程序内部的异常消息采集。例如程序内部出现异常,抛出的异常消息可以通过trap方式发直接送给 zabbix-server,通过 trigger 产生事件,通 过action 发送报警。
总结:整体来看 zabbix 对数 据采集种类的支持还是比较丰富,但是配置起来相对复杂。
二、zabbix 的 trigger 监控规则
1、监控规则是监控系统的核心,通过配置阈值来触发异常,产生事件,zabbix 内置了很多规则。
2、通过 trigger 的 Dependencies 配置可以实现简单的事件关联依赖。例如:有两个 trigger 监控.
1 、是监控 站点是否可访问
2、是监控主机 nginx 80 端口是否可达。
对于 trigger1 可以增加对 trigger2 的依赖条件,这样当 nginx 80 端口不可达, 站点也是不可访问的,但是不会触发产生 站点不可访问的异常事件。
3、基于以上设置,虽然可以实现简单的事件关联依赖合并,监控系统内部屏蔽了异常事件的产生,如果报警涉及多组运维人员,大家都希望可以看到自己的监控是否有异常。所以最好的方式还是所有异常事件都正常产生,在报警通知的时候进行关联分析。
例如针对上述的例子,运维组 A 负责 triiger1 报警、运维组 B 负责 trigger2 报警,当 trigger2 异常时,通知运维组 A【 不可访问,因为 nginx 80 端口不可达】,通知运维组 B【nginx 80 端口不可达,导致 不可访问】。
总结:zabbix 有较全面的监控规则匹配表达式,当对于较复杂关联监控配置起来不够灵活。
三、zabbix 的 action 触发动作
针对 triiger 触发的异常事件,可以触发相应的动作。通常的动作就是根据配置的 media 进行报警发送。Zabbix 在报警配置这块,每种发报警发送方式都需要配置 1 个 media,并且对每个用户都需要配置相应的发送 media。
如果将zabbix的报警交给灵犀来管理,针对用户配置这块,只需zabbix上面配置1个user和1个media即可,会省事很多。
[url=]来自微信:Linkedsee灵犀[/url]