分布式监控系统——Zabbix（3）配置

分布式监控系统——Zabbix（3）配置

一、监控项

1.定义一个不带参数的监控项

更新即可，事实上，需要关注的指标有很多种，一一添加进来即可。以上定义的监控项是很简单的，制定一个key即可，但是有些监控项是带有参数的，这样一来，监控项就更有灵活性。

2.定义一个带参数的监控项

• []就是需要参数的意思，里面的值即为参数。
• <>为不可省略的。

例：if表示是接口名；表示是哪种模式，包括但不限于：packets（包）、bytes（字节）、errors（错误）、dropped（丢包）、overuns等等（上述内容通过ifconfig查看）。

设置一个监控值：

通过命令行来查看：

查看网页的显示情况：

3.删除监控项

如果有一个监控项，用不上了，就可以删除掉。但是如果你直接删除的话，默认数据是会留下的，所以要先清楚数据，然后再删除，具体步骤如下：

4.监控项存储的值

对于监控项的值，老一点的版本只有以下三种方式：

1. AS is：不对数据做任何处理（存储为原始值）。
2. Delta：（simple change变化），本次采样减去前一次采样的值的结果。
3. Delta：（speed per second速率），本次采样减去前一次采样的值，再除以经过的时长。

在3.4版本之后有了更多的表现形式：

二、触发器

1.简介

当采集的值定义完了以后，就可以来定义触发器了。触发器的定义是：界定某特定的item采集到的数据的非合理区间或非合理状态。通常为逻辑表达式。逻辑表达式（阈值）：通常用于定义数据的不合理区间，其结果如下：

• OK（不符合条件）：正常状态——》较老的zabbix版本叫FALSE。
• PROBLEM（符合条件）：非正常状态——》较老的zabbix版本叫TRUE。

评定采样数值是否为合理区间的比较稳妥的方法是一一根据最后N次的平均值来判定结果；这个最后N次通常有两种定义方式：

• 最近N分钟所得结果的平均值
• 最近N次所得结果的平均值

触发器存在可调用的函数：

注：能用数值保存的就不要使用字符串

2.触发器表达式

基本的触发器表达式格式如下所示

{:.()}
1

• server：主机名称

• key：主机上关系的响应监控项的key

• function：评估采集到的数据是否在合理范围内时所使用的函数，其评估过程可以根据采集的数据，当前时间及其他因素进行

• 目前触发器所支持的函数有avg、change、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)将返回一周之前的最大值

• 表达式所支持的运算符及其如下图所示：

  

3.定义一个触发器

查看一下aaa监控项的值，并以其为标准确定我们的非正常的值：

添加成功后再去最新数据里面查看图形，可以看到里面就有了一根线，就是定义的值：

超过线的即为异常状态，看起来非常直观。现在即使超过了这根线，也仅仅会产生一个触发器时间而不会做其他任何事。因此，需要去定义一个动作(action)

4.触发器的依赖关系

触发器彼此之间可能会存在依赖关系的，一旦某一个触发器被触发了，那么依赖之歌触发器的其余触发器都不需要再报警。

多台主机是通过交换机的网络连接来实现被监控的。如果交换机出了故障，我们的主机自然也无法继续被监控，如果此时，所有主机统统报警，要解决这样的问题，就是定义触发器之间的依赖关系，当交换机挂掉，只有自己报警就可以了，其他的主机就不要再报警了。这样也更易于我们判断真正故障所在。

注意：目前zabbix不能够直接定义主机间的依赖关系，其依赖关系仅能通过触发器来定义。

定义一个依赖关系：打开任意一个触发器，上面就有依赖关系，我们进行定义即可：

触发器可以有多级依赖关系，比如：

5.定义动作（action）

1.简介

• 需要去基于一个对应的事件为条件来指明该做什么事，一般就是执行远程命令或者发警报。
• 有一个告警升级的机制，所以，当发现问题的时候，一般是先执行一个远程操作命令，如果能够解决问题，就会发一个恢复操作的讯息给接收人，如果问题依然存在，则会执行发警报的操作，一般默认的警报接收人是当前系统中有的zabbix用户，所以当有人需要收到警报操作的话，我们则需要把它加入我们的定义之中。
• 每一个用户也应该有一个接收告警信息的方式，即媒介，就像我们接收短信需要有手机号一样。
• 每一个监控主机，能够传播告警信息的媒介有很多种，就算我们的每一种大的媒介，能够定义出来的实施媒介也有很多种，而对于一个媒介来说，每一个用户都有一个统一的或者不同的接收告警信息的端点，我们称之为目标地或者目的地。

综上为了能够发告警信息

• 第一，我们要事先定义一个媒介
• 第二，还要定义这个媒介上用户接收信息的端点（当然，在用户上，也称之为用户的媒介）。

系统内建的媒介类型：

这只是基本的媒介类型，里面还有更多的细分，已Email为例：

而同一个类型也可以定义多个，以Email为例，可以定义一个腾讯的服务器，一个网易的服务器等等。

2.定义一个媒介（media）

以Email为例：

定义后更新就可以了，媒介定义好了还需要让用户接收到邮件：

• 进入管理——》用户——》Admin——》报警媒介
• 添加一条进来：

PS：一个用户可以添加多个接收的媒介类型。

3.定义一个动作（action）

动作是在某些特定条件下触发的，比如：某个触发器被触发了，就会触发动作。现在基于redis来定义一个动作。

#在agent端安装并启动redis
[root@node1 ~]# yum -y install redis
[root@node1 ~]# systemctl start redis
[root@node1 ~]# ss -nutlp|grep redis
1
2
3
4

定义监控项：配置——主机——node1——监控项——创建监控项

填写完毕后添加即可，此时可以查看值：

定义触发器：

手动关闭redis服务来检测一下：

[root@node1 ~]# systemctl stop redis
1

创建动作：

需要在虚拟机上进行两项操作：

• 修改sudo配置文件使zabbix用户能够临时拥有管理员权限
• 修改zabbix配置文件使其允许接收远程命令

[root@node1 ~]# visudo
     91 ## Allow root to run any commands anywhere
     92 root    ALL=(ALL)       ALL
     93 zabbix  ALL=(ALL)       NOPASSWD:ALL	#添加此行
[root@node1 ~]# vim /etc/zabbix/zabbix_agentd.conf 
EnableRemoteCommands=1							#73行取消注释改为1。允许接收远程命令
LogRemoteCommands=1								#82行取消注释改为1。把接收的远程命令记入日志
[root@node1 ~]# systemctl restart zabbix-agent.service
1
2
3
4
5
6
7
8

添加了第一步需要做的事情，需要重启服务，如果重启不成功怎么办呢？就需要来添加第二步：

测试（关闭redis）：

如上图，提示警告，再看redis服务又被远程命令拉了起来：

END