【Zabbix】04、zabbix 触发器、事件、动作

lanxi256

　　

　　
一、触发器

1、触发器（trigger）


      “监控项”仅负责收集数据，而通常收集数据的目的还包括在某指标对应的数据超出合理范围时给相关人员发送告警信息，“触发器”正是用于为监控项所收集的数据定义阈值
       每一个触发器仅能关联至一个监控项，但可以为一个监控项同时使用多个触发器；事实上，为一个监控项定义多个具有不同阈值的触发器，可以实现不同级别的报警功能
        一个触发器由一个表达式构成，它定义了监控项所采集的数据的一个阈值
        一旦某次采集的数据超出了此触发器定义的阈值，触发器状态将会转换为“Problem”；而当采取的数据再次回归至合理范围内时，其状态将重新返回到“OK”
　　

2、触发器表达式
    触发器表达式高度灵活，可以以之创建出非常复杂的测试条件
      zabbix server item每次获取到一个新值都会使用触发器表达式计算它的状态如果使用基于时间的表达式
基本的触发器表达式格式如下所示：
     {:.()}
　　            某主机上某个key使用某个函数（参数）所得的值 和 设定的值比较
　　

　　server：主机名称；

key：主机上关心的相应监控项的key；
function：评估采集到的数据是否在合理范围内时所使用的函数，其评估过程可以根据采取的数据、当前时间及其它因素进行；


目前，触发器所支持的函数有：
avg、          求平均值
count、       指定时间内或次数内数值统计
change        指定时间内或次数内倒数第2次于倒数第1次的差值，对于字符串，0没有变化，1表示有变化；
date、             当前日期
dayofweek、   本周第几天       dayofmonth 本月第几天
delta、             指定时间内或次数内最大值与最小值的差
diff、                指定时间内或次数内倒数第2次于倒数第1次的值，有没有不同；常用于监控文件
regexp              检查最后一次采样的数据是否能够被指定的模式所匹配：1表示匹配，0表示不匹配
iregexp             不区分大小的正则表达式
last                   最近采样的数据
max、min、nodata（没有数据）、
now                  返回时间戳
prev                  倒数第二个采样值
str                     从最后一次的采样中查找此处指定的字符串；0表示找到，1表示没找到
strlen                字符串长度比较
sum                  求和
　　

parameter：函数参数；大多数数值函数可以接受秒数为其参数，而如果在数值参数之前使用“#”做为前缀，则表示为最近几次的取值，如sum(300)表示300秒内所有取值之和，而sum(#10)则表示最近10次取值之和；
       此外，avg、count、last、min和max还支持使用第二个参数，用于完成时间限定；
例如，max(1h,7d)将返回一周之前的最大值；

　　

一个例子：
      {www.magedu.com:system.cpu.load[all,avg1].last(0)}>3
             表示主机www.magedu.com上所有CPU的过去1分钟内的平均负载的最后一次取值大于3时将触发状态变换
       对last函数来说，last(0)相当于last(#1)


更多触发器表达式的例子：
    http://www.ttlsa.com/zabbix/zabbix-trigger-expression/


3、触发器间的依赖关系
在一个网络中，主机的可用性之间可能存在依赖关系
       例如，当某网关主机不可用时，其背后的所有主机都将无法正常访问
       如果所有主机都配置了触发器并定义了相关的通知功能，相关人员将会接收到许多告警信息，这既不利于快速定位问题，也会浪费资源
       正确定义的触发器依赖关系可以避免类似情况的发生，它将使用通知机制仅发送最根本问题相关的告警
注意：目前zabbix不能够直接定义主机间的依赖关系，其依赖关系仅能通过触发器来定义


4、触发器等级
　　severity通常用来定义当前item的一个状态的严重性。我们可以根据不同的严重性来定义不同的事件，例如报警，zabbix自带如下严重性定义。

        严重性                  定义                       颜色
        无类别             未知的严重性               灰色

         信息                供参考                      亮绿灯
         警告               应该引起注意              黄色
        常见问题            常见问题                  橙色
           高                  重要的事情发生          红色
         灾难               灾难，会造成损失        亮红色
severities 用途

• 　　可视化显示，不同级别显示不同颜色，例如一般严重性为绿色
  
• 　　声音报警,不同的级别不同声音.
  
• 　　使用用户自定义媒体报警，例如严重问题发短信，其他问题发送邮件。
  
• 　　根据严重性来定义是否报警
  

可以自定义触发器严重性以及颜色，请参考：customise trigger severity names and colours.


　　5、创建触发器
　　创建触发器步骤:

• 　　点击Configuration（配置） → Hosts（主机）
  
• 　　点击hosts（主机）相关行的trigger
  
• 　　点击右上角的创建触发器（create trigger），你也可以修改列表中的触发器
  

在表单中输入相应的信息：
创建触发器可用的各属性说明
     Name：触发器名称，
                     名称可以包含宏变量： {HOST.HOST}, {HOST.NAME}, {HOST.CONN}, {HOST.DNS}, {HOST.IP}, {ITEM.VALUE}, {ITEM.LASTVALUE} and {$MACRO}.
$1, $2…$9 可以被用来关联表达式的常量
示例：
name：Processor load above $1 on {HOST.NAME}”
表达式：system.cpu.load[percpu,avg1].last(0)}>5
会显示为：Processor load above 5 on ttlsa云服务器
  
    Expression：逻辑表达式，用于评估触发器状态；
     Multiple PROBLEM events generation：依赖于当前触发器的“Problem”状态生成其它事件；
     Description：当前触发器的描述信息；
     URL：在screen的“Status of Trigger”中显示的内容的链接；
                   在Monitoring → Triggers中，可以看到URL并且可以点击，一般情况下他需要配合触发器ID来使用，在url中包含触发器ID（宏变量 {TRIGGER.ID}），这样可以直接点击到具体触发器中。
     Severity：当前触发器的严重级别；
     Enabled：是否启用当前触发器；


　　

　　二、事件（event）
　　我们前面花了大量时间去学习item、trigger都是为发送报警做准备的，什么是事件通知呢？简单的说故障发生了，zabbix会发邮件或者短信给你，告诉你服务器的一些状况。
　　1、event
        Zabbix的事件是基于时间戳进行标记的，它们是采取动作(action)如发送邮件通知的基础，其主要来源于三种途径
触发器(trigger)事件：Trigger events
         触发器状态每次发生改变，都会生成相应“事件”，且通常包含详细信息，如发生的时间及新的状态等；
发现(discovery)事件：Discovery events
          zabbix会周期性地扫描“网络发现规则”中指定的IP范围，一旦发现主机或服务，就会生成一个或几个发现事件；
         发现事件有8类：Service Up、Service Down、Host Up、Host Down、Service Discovered、Service Lost、Host  Discovered和Host Lost；
主动agent自动发现事件（也称作“自动注册事件”）：Auto registtation events
          当一个此前状态未知的主动agent发起检测请求时会生成此类事件；
　　内部事件：Internal events
        Item变成不再支持或trigger变成未知状态
　　LLD：
　　low level disvcovery，较低层的自动发现
　　

　　三、执行动作（Action）
        Action由conditions（条件）和operations（操作）组成。当满足指定的条件，然后执行操作。这就是一个action。
　　operations包含两个操作：

　　Send message  
　　发送信息，就是发送报警
　　remote command
　　远程命令，就是执行zabbix-server服务器端的命令，对于zabbix-agetn是远程命令
　　

　　下面我们来分别演示下这两种操作的用法：
　　

　　1、Send message  
　　发送信息报警是有先决条件的：
　　zabbix-server将报警信息发送给谁？
　　     肯定是要发送给zabbix-server上的某个用户
　　  如何才能通知到此用户呢？
　　zabbix-server上的每个用户都配置有接受通知的介质(Media type)
　　理解了这个两个问题，配置报警信息的发送就很简单了。

　　

　　在zabbix中，通知介质是指发送通知信息的通道，其通常有以下几种类型：

　　E-mail：电子邮件，即通知邮件的方式传送通知信息；
　　           只能发送给本服务器上的其它用户，不能发送到外部的邮件地址，那这有毛用，我们都是使用脚本来实现发送E-mail
　　SMS：手机短信，即通过连接至zabbix服务器GSM Modem发送通知；需要短信网关设备
　　Jabber：jabber消息；Jabber是一个开放的、基于XML的协议，能够实现基于Internet或LAN的即时通讯服务；
　　自定义的通知脚本：我们只能使用这个了
         以上方式不能满足需求时，zabbix可以调用位于其配置文件/etc/zabbix/zabbix_server.conf “AlertScriptsPath”变量所定义的脚本查找目录中的脚本来完成通知功能；
        脚本中可使用$1,$2,$3来调用action中的邮件的收件人,Default subject(主题), default message（内容）
　　

1）定义一个通知介质  ### 媒介类型 (Media type)

   Aministration --> Media types

　　可以看到有3个默认的通知示警媒介类型，这是系统默认给的配置示例，我们不动，
　　选择create media type：
　　
　　SMTP server：SMTP 邮件服务器，localhost表示使用本服务器做邮件服务器就只有本系统内的用户才能收的到邮件
SMTP helo：SMTP helo值，通常情况下是顶级域名。SMTP服务器间需要交换数据时，先会探测对发是否在线，一般和SMTP 邮件服务器一样就可以
SMTP email：发件人         
　　

　　2）用户绑定通知介质
　　Aministration --> Media types --> add
　　
　　tyepe：选择媒介类型，自己之前创建的
　　send to：发送给，就是收件人
　　when active：报警时间限定，例如1-5,09:00-18:00，只有工作日的9点到18点才会通知，实际工作中，我们应该是相反。
　　Use if severity：严重性类型，只接收指定的类型,例如info不想接收，那我不勾选即可。
　　Status：媒介状态Enabled - 启用中.Disabled - 已禁用.
　　

　　3）定义动作

　　点击configuration（配置）-> Actions（报警）-> 选择事件来源  --> create action
　　注意：下面的截图和我后面的配置不一样，不愿截图了，使用别人的截图来说明

action主要属性的说明：
       Name：当前action的独有名称；
       Default subject：默认的消息主题，可以使用宏；
       Default message：默认的消息，可以包含宏；
       Recovery：监控项从“问题”状态恢复之后是否发送的消息；如果启用，恢复消息仅发送给监控项转换为“问题”状态时的通知对象；
       Recovery subject：恢复消息主题，可以包含宏；
       Recovery message：恢复消息，可以包含宏；
       Enabled：是否启用当前action；


配置完action的基本内容之后，接下来配置条件

• 　　
  
  

Type Of calculation：
     各种条件之间的关系，包含AND、OR 以及AND/OR，如上图是AND关系，同时要满足以上机器不在维护状态以及触发器值为PROBLEM才会触发报警的动作。
　　

　　接下来是“操作”标签，如下：

   此处没有报警的动作，当你满足了报警条件也没有任何意义，因为你不执行任何报警的操作，那还要action做什么，对吧？话说回来，每个action都必须配置operations。

　　

图片上的step说的可能不是很明白，
　　step可以用来设置报警升级：
表示阶段，1表示第一次报警，如果2表示第二次报警。


action operations可以添加多个，如下：

　　

如上图，我们可以看出第1-10次报警都会发邮件给Admin这个用户，每次邮件间隔为300秒，
第4-10次开始（故障发生15分钟后）便会发送邮件给administrators这个组。
这边可以实现故障开始时发送邮件给值班运维，多少分钟还没处理好发送邮件给主管或者经理，甚至是老板，呵呵。


  如果我们监控的某服务，此时服务挂了而引起的事件，我们也可以这样设置：
step 1：使用脚本，重启这个服务
step 2：服务还没起来，再发送信息报警

• 　　
  
  

　　最后保存之后可以看到我们配置好的action了，只要满足action条件便会出发报警操作。

　　

　　
　　
上面3个步骤都配置好了，我们触发一个报警的动作：    # 触发前面设置的too many interrupts触发器
　　

　　可以在Monitoring ——> Triggers 看到触发器的状态
　　Monitoring --> Events 看到事件触发的动作成功了
　　

　　查看邮件：
[root@Zabbix ~]# mail
Heirloom Mail version 12.4 7/29/08.  Type ? for help.
    6 zabbix@localhost.AF.  Sun Apr  9 15:48  23/991   "PROBLEM: too many interrupts"
    7 zabbix@localhost.AF.  Sun Apr  9 15:49  23/978   "OK: too many interrupts"　　我们就成功的使用自带的E-mail通知介质实现了报警，不过这个说了没毛用吧，一般都不用的，这里只是演示下配置过程。

　　

　　2、remote comman             

　　

                               （1）  给zabbix定义sudo规则：
zabbix ALL=(ALL)       NOPASSWD: ALL
#Defaults    requiretty            #注释掉执行sudo命令要求通过安全tty才能执行，                               （2）不支持(active)主动模式的agent，就是说自动注册的客户端不支持
                               （3）不支持代理模式
                               （4）命令长度不得超过255字符
                               （5）可以使用宏
                               （6）zabbix-server仅执行命令，而不关心命令是否执行成功
前提：
zabbix-agent要配置为支持执行远程命令：
在客户端修改配置文件/etc/zabbix/zabbix_agentd.conf
EnableRemoteCommands=1
LogRemoteCommands=1命令如果用到以其它用户身份执行时，命令本身要以sudo执行：sudo /etc/rc.d/init.d/httpd restart
                          
      在配置好监控项和触发器之后，一旦正常工作中的某触发器状态发生改变，一般意味着有异常情况发生，此时通常需要采取一定的动作(action)，如告警或者执行远程命令等
      并非所有的触发器状态发生改变的场景都需要对其进行干预，如转变为“OK”状态时，相应地，如果触发器的状态转变为“Problem”，就需要告知所有关心其相关监控指标的人员了。




      因此，Zabbix的通知机制也称作基于事件的通知机制，也只有理解了事件本身，才能定制出符合需求的通知系统
[root@Node2 ~]# cd /usr/lib/zabbix/alertscripts/
[root@Node2 alertscripts]# ls
alerttest.sh
[root@Node2 alertscripts]# cat alerttest.sh
#!/bin/bash
#
echo "$3"|mail -s "$2" "$1"



　　









     







Action的操作(operation)：
       zabbix支持的操作有两类：“发送通知”和“执行远程命令”
      而对于“发现”类事件来说，其支持的操作还有添加主机、移除主机、启用主机、禁用主机、添加到组、从组中删除、链接到模板及从模板上拆除关联等
      对于“自动注册”类事件来说，支持的操作为添加主机、禁用主机、添加到组及链接至模板等
　　

Operation相关的属性说明：
Step：告警升级(escalation)调度方式；
      From：操作开始的位置；即第几次升级间隔时间到达后检测仍然有“问题”时开始执行操作；
      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：要执行的命令；


告警升级(escalation)
       escalation用于实现用于定制发送通知或执行远程命令的方式，
常用于实现如下场景：
出现问题时立即发送通知；
问题得不到解决时多次发送通知给用户；
按需延迟发送通知；
问题长久得不到解决时发送给级别更高的用户；
立即执行远程命令或经过一个预定的时长后仍未解决问题时执行远程命令；
故障恢复时发送相关信息；

实际操作中，action的escalation机制的实现依赖于“escalation step(升级步长)”，step是一个时间长度；
为了简化操作过程，可以为step定义默认的时长，只有在必要时才为action自定义其step
可以在任何有效的step到达时启动action，第1个step表示立即启动；
如果要延迟启动action，可以选择在后面的其它step上启动
下面示例表示延迟一个step之后才启用action












为更好的理解，这里总结一下
　　1、Zabbix完整的监控配置流程大体上由如下步骤组成：
         host group --> hosts --> Applications  --> items（存储于mysql）--> triggers（ok-->problem）--> events --> actions --> User groups --> Medias --> Users
　　

　　graph（zabbix-web） --> screen
　　

　　主机组的划分：

　　服务器的用途、系统版本、应用程序、地理位置、业务单元
　　

　　2、如何添加主机到zabbix server
　　discovery：
　　自动发现，定义discovery规则
　　  zabbix-server会自动扫描某个范围（网段）内活动的主机，会自动纳入监控

　　auto_registrion：

　　客户端自动注册，
　　low level disvcovery:
　　较底层的自动发现，用于区别底层设备（如：linux和windows）