文章目录
- 分布式监控系统——Zabbix（3）配置
- 一、监控项
- 1.定义一个不带参数的监控项
- 2.定义一个带参数的监控项
- 3.删除监控项
- 4.监控项存储的值
- 二、触发器
- 1.简介
- 2.触发器表达式
- 3.定义一个触发器
- 4.触发器的依赖关系
- 5.定义动作（action）
- 1.简介
- 2.定义一个媒介（media）
- 3.定义一个动作（action）
分布式监控系统——Zabbix（3）配置
一、监控项
1.定义一个不带参数的监控项
更新即可，事实上，需要关注的指标有很多种，一一添加进来即可。以上定义的监控项是很简单的，制定一个key即可，但是有些监控项是带有参数的，这样一来，监控项就更有灵活性。
2.定义一个带参数的监控项
- []就是需要参数的意思，里面的值即为参数。
- <>为不可省略的。
例：if表示是接口名；表示是哪种模式，包括但不限于：packets（包）、bytes（字节）、errors（错误）、dropped（丢包）、overuns等等（上述内容通过ifconfig查看）。
设置一个监控值：
通过命令行来查看：
查看网页的显示情况：
3.删除监控项
如果有一个监控项，用不上了，就可以删除掉。但是如果你直接删除的话，默认数据是会留下的，所以要先清楚数据，然后再删除，具体步骤如下：
4.监控项存储的值
对于监控项的值，老一点的版本只有以下三种方式：
- AS is：不对数据做任何处理（存储为原始值）。
- Delta：（simple change变化），本次采样减去前一次采样的值的结果。
- Delta：（speed per second速率），本次采样减去前一次采样的值，再除以经过的时长。
在3.4版本之后有了更多的表现形式：
二、触发器
1.简介
当采集的值定义完了以后，就可以来定义触发器了。触发器的定义是：界定某特定的item采集到的数据的非合理区间或非合理状态。通常为逻辑表达式。逻辑表达式（阈值）：通常用于定义数据的不合理区间，其结果如下：
- OK（不符合条件）：正常状态——》较老的zabbix版本叫FALSE。
- PROBLEM（符合条件）：非正常状态——》较老的zabbix版本叫TRUE。
评定采样数值是否为合理区间的比较稳妥的方法是一一根据最后N次的平均值来判定结果；这个最后N次通常有两种定义方式：
- 最近N分钟所得结果的平均值
- 最近N次所得结果的平均值
触发器存在可调用的函数：
函数 | 描述 |
nodata() | 是否采集到数据，采集不到则为异常 |
last() | 最近几次 |
date() | 时间，返回当前时间，格式YYYYMMDD |
time() | 返回当前时间，格式HHMMSS |
now() | 返回距离Epoch（1970年1月1日00:00:00UTC）时间的秒数 |
dayofmonth() | 返回当前是本月的第几天 |
注：能用数值保存的就不要使用字符串
2.触发器表达式
基本的触发器表达式格式如下所示
{<server>:<key>.<function>(<parameter>)}<operator><constant>- 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
定义监控项：配置——主机——node1——监控项——创建监控项
填写完毕后添加即可，此时可以查看值：
定义触发器：
手动关闭redis服务来检测一下：
[root@node1 ~]# systemctl stop redis
创建动作：
需要在虚拟机上进行两项操作：
- 修改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添加了第一步需要做的事情，需要重启服务，如果重启不成功怎么办呢？就需要来添加第二步：
测试（关闭redis）：
如上图，提示警告，再看redis服务又被远程命令拉了起来：
END
