zabbix基础知识

zabbix基础知识

一个标准的监控系统所具备的基本功能：

1.数据的采集

2.为了展示其长期走势，将数据存储下来

3.万一某次采样的结果不在被认为是合理的范围内，然后就会做出告警操作，尽早的让相关人员得知到此消息

4.展示

 

监控的对象除了主机之外，还包括主机之间的流量

对主机而言所需监控指标：

系统指标：CPU，memery,IO(Disk,Network)

1.CPU:sys(消耗在系统空间的比例)，usr（用户空间的比例），idle（空闲的比例）,,,等

2.memery：total（总大小），userd（已用空间大小），free（空闲大小），cached（放在缓存的大小），buffer，shm（共享内存的大小），，，等

3.IO

以上只是系统指标

系统一旦起来，会运行很多进程，对进程而言，他有多少个，他的变化量，处于运行状态的，处于睡眠状态的，处于僵死状态的等，，，这些又是指标

业务指标：比如：对于nginx服务，假如说nginx也算是一个进程，他时而处于运行状态，时而处于睡眠状态，对于nginx本身来说，他每秒接受的请求数量，每秒处理的请求数量等，这些可以理解为业务指标。

 

数据采集

1.ssh接口（监控中最为简单的方式）

我们要监控的某个特定主机的某一项指标，如果这项指标是核心而敏感的数据，普通用户是不具有权限的，要想获取到核心的数据，就要以管理员的身份来运行，可以用ssh账号远程连接认证来连接到监控的主机上，从而获取到核心的数据，来实现管理。

2.agent

在监控的目标主机上运行一个进程，这个进程可以与其控制端通过非系统的认证逻辑来进行认证，即便用户获得了认证的信息，也不能获得系统级权限。通过了认证后，控制端就会只会agent端做出一些操作，如果agent端以管理员身份来运行，就能在目标主机上获得设计者设计的权限。

3.英特尔智慧平台接口

一些专业的服务器也可以不依赖于操作系统提供的系统级接口来监控，就算没装操作系统，也可以获取该主机的CPU，memery,IO用量，这种方式依赖硬件级的接口，英特尔智慧平台接口

4.jmx接口

在jvm虚拟机上有一个jmx接口，通过这个接口来获取数据指标，来完成监控

 

对采集的数据进行存储

对于mysql

tps:每秒的事务数

qps:每秒的查询数

历史数据：每一次采样都保存下来的数据

趋势数据：按照固定的时间长度做聚合运算后仅保留有限数据项的数据

假如说,每5分钟收集一次数据，那么一小时就要采集12次，这12次采集的数据就是历史数据，将这12次采集的数据经过聚合运算得出聚合的结果，可能只有三四个数据项，最大，最小，平均值，这就是趋势数据。

所以为了展示数据的长期走势，多保留一些趋势数据，历史数据仅保留最近几个月的，但是这么一来，就会给数据库带来的更大的压力，因为既要存储趋势数据，又要存储历史数据，为了解决这个问题，早期使用关系型数据库作为存储系统，后来也有了一些其他的方案，例如：rrd(cacti),round-robin-database轮询数据库

数据存储就像围绕一个圆进行存储，当存满了之后，再有新的数据来存储，就会覆盖原来最早存储的数据。

告警

获取用户可以及时得到信息的接口，然后向用户传递信息

如果一个监控系统监控到异常状态的信息，向用户发短信，就需要有一个前提，监控系统能够发短信，但是监控系统并不做这个工作，他只调用发短信这个服务，就需要写一个程序，来调短信服务的api接口，这个程序写好之后能够被监控系统所触发即可。

展示

展示界面越绚丽，简单美观，让看的人少动脑，就越受欢迎。

 

常见的监控系统

Nagios:"难够死"，是一个非常好的告警系统，但是没有提供存储系统

Cacti：Cron+SNMP+Mysql,很好的展示系统，但是问题出现比较多

zabbix:整合了上面提到的四种功能的监控系统

1.支持多种接口完成数据采集：agent,SNMP,IPMI(英特尔智慧平台接口)，jmx

2.数据存储：mysql,pgsql

3告警：email，script脚本（短信，微信）

（1）可以告警升级，刚开始出故障时，发短信给运维工程师，隔两小时后没有解决问题，就发给他的领导，再隔两小时没解决，发给领导的领导，，，

（2）可以发远程命令，刚开始出故障时，尤其是服务级故障，先不要立即发告警，在第一个周期内，试图尝试去解决问题，远程指挥目标主机重启一下服务，如果问题解决，就不用发警报了，如果没有解决，那就开始发警报

4.展示：简单图，图形，screen,slide,show,map,,,

 

第三方的展示接口：grafana

结合grafana展示接口形成监控系统

1.statsd+influxdb（时序数据库）+grafana

2.promethues(自身就相当于时序数据库，可收集数据，存储下来，并展示，但展示界面不好看，所以可结合grafana)+grafana

3.graphitce+grafana

 

zabbix程序架构

 

Zabbix组件概述

Zabbix Server：负责接收agent发送的报告信息的核心组 件，所有配置、统计数据及操作数据均由其组织进行；

Database Storage：专用于存储所有配置信息，以及由zabbix收集的数据,以及存储在Zabbix所配置的配置信息，比如：哪个指标需要监控，多长时间监控一次等；

Web interface：zabbix的GUI接口，通常与Server运行在 同一台主机上；

Proxy：可选组件，常用于分布监控环境中，代理Server收 集部分被监控端的监控数据并统一发往Server端；

Agent：部署在被监控主机上，负责收集本地数据并发往 Server端或Porxy端；

 

Zabbix监控Java应用

 

监控系统运行状态

Zabbix Server监控的主机上指标不只一个，以一个指标为例，假如每隔120秒采样一次，采集一次存一次，而且每当一个时间段满足时会做一次聚合运算，得出聚合运算结果，最大值，最小值，平均值等，每次采集存储下来之前会先评估一下数据是否满足触发器，既是否在合理区间范围内，如果在就OK，否则PROMBLE，一旦状态发生转换，假如上次是OK，现在转换成了PROMBLE，就会触发一个时间EVENT,就会采取行动，行动分多个层级，首先执行远程命令，如果不行，就发报警等。

采集----》判定阈值范围-----》如果没问题就存下来，如果有问题则有事件产生，就会产生某个行为，告警操作

 

Zabbix常用的术语

主机(host)：要监控的网络设备，可由IP或DNS名称指定；

主机组(host group)：主机的逻辑容器，可以包含主机和模 板，但同一个组内的主机和模板不能互相链接；主机组通常 在给用户或用户组指派监控权限时使用；

监控项(item)：一个特定监控指标的相关的数据，这些数据 来自于被监控对象；item是zabbix进行数据收集的核心，没 有item，将没有数据；相对某监控对象来说，每个item都由"key"进行标识；

触发器(trigger)：一个表达式，用于评估某监控对象的某特 定item内所接收到的数据是否在合理范围内，即阈值；接收 到的数据量大于阈值时，触发器状态将从"OK"转变为 "Problem"，当数据量再次回归到合理范围时，其状态将从 "Problem"转换回"OK"；

事件(event)：即发生的一个值得关注的事情，例如触发器的 状态转变，新的agent或重新上线的agent的自动注册等；

动作(action)：指对于特定事件事先定义的处理方法，通过包 含操作(如发送通知)和条件(何时执行操作)；

报警升级(escalation)：发送警报或执行远程命令的自义定方 案，如每隔5分钟发送一次警报，共发送5次等；

媒介(media)：发送通知的手段或通道，如Email、Jabber或SMS等；

通知(notification)：通过选定的媒介向用户发送的有关某事 件的信息；

远程命令(remote command)：预定义的命令，可在被监控 主机处于某特定条件下时自动执行；

模板(template)：用于快速定义被监控主机的预设条目集 合，通常包含了item、trigger、graph、screen、

application以及low-level discovery rule；模板可以直接链接至单个主机；

应用 (application)：一组item的集合；

web场景(web scennario)：用于检测web站点可用性的一个 或多个HTTP请求；

前端(frontend)：Zabbix的web接口；

 

Zabbix的逻辑架构

Zabbix Server Processes