zabbix监控-基本原理介绍

 

1、Linux下开源监控系统简单介绍
1）cacti：存储数据能力强，报警性能差
2）nagios：报警性能差，存储数据仅有简单的一段能够判断是否在合理范围内的数据长度，储存在内存中。好比，连续采样数据存储，有连续三次不在合理范围内的数据就报警
3）zabbix：结合上面两种工具的优势，又能够存储数据，又能够报警。

2、什么是Zabbix及其优缺点（对比Cacti和Nagios）

Zabbix是一个基于Web界面提供分布式系统监视及网络监视功能的企业级开源解决方案。它能监视各类网络参数，保证服务器系统的安全运营，并提供灵活的通知机制以让系统管理员快速定位/解决存在的各类问题；借助Zabbix可很轻松地减轻运维人员们繁重的服务器管理任务，实现业务系统持续运行。
agent端：主机经过安装agent方式采集数据。
server端：经过收集agent发送的数据，写入数据库（MySQL，ORACLE等），再经过php+apache在web前端展现.
zabbix = cacti + nagios

• 优势：基于两款工具优势于一身并更强大，实现企业级分布式监控。
• 缺点：2.2版本带宽占用大可是升级到2.4版本后更节省了带宽资源，其它再无发现。

3、Zabbix特性

1）数据采样：经过snmp、ssh、telnet、agent、ipmi、jmx等通道采集被监控主机的数据。能够自定义检测机制和自定义时间间隔
2）实时绘图：展现，读取数据绘图，支持graph，map，screen，幻灯片（slide show）
3）告警：（升级告警，规定时间内内解决不了的事情往上传）
4）数据存储：数据库有mysql，pgsql，时间序列数据库等等

4、Zabbix监控功能

主机的性能监控、网络设备性能监控、数据库性能监控、多种告警方式、详细的报表图表绘制
监控主机zabbix有专用的agent，能够监控Linux，Windows，FreeBSD等 。
监控网络设备zabbix经过SNMP，ssh(很少用)
可监控对象

• 设备：服务器，路由器，交换机
• 软件：OS，网络，应用程序
• 主机性能指标监控
• 故障监控： down机，服务不可用，主机不可达

5、Zabbix工做原理

zabbix监控系统运行大概流程：
zabbix agent须要安装到被监控的主机上，它负责按期收集各项数据，并发送到zabbix server端；
zabbix server将数据存储到数据库中，zabbix web根据数据在前端进行展示和绘图。这里agent收集数据分为主动和被动两种模式：

• 主动：agent请求server获取主动的监控项列表，并主动将监控项内须要检测的数据提交给server/proxy
• 被动：server向agent请求获取监控项的数据，agent返回数据。

6、zabbix的组件及进程

zabbix由如下几个组件部分构成：

• Zabbix Server：负责接收agent发送的报告信息的核心组件，全部配置，统计数据及操做数据均由其组织进行；
• Database Storage：专用于存储全部配置信息，以及由zabbix收集的数据；
• Web interface：zabbix的GUI接口，一般与Server运行在同一台主机上；
• Proxy：可选组件，经常使用于分布监控环境中，代理Server收集部分被监控端的监控数据并统一发往Server端；
• Agent：部署在被监控主机上，负责收集本地数据并发往Server端或Proxy端；

默认状况下zabbix包含5个程序：zabbix_agentd、zabbix_get、zabbix_proxy、zabbix_sender、zabbix_server，另一个zabbix_java_gateway是可选，这个须要另外安装。下面来分别介绍下他们各自的做用。

1）zabbix_agentd：
客户端守护进程，此进程收集客户端数据，例如cpu负载、内存、硬盘使用状况等。
2）zabbix_get
zabbix工具，单独使用的命令，一般在server或者proxy端执行获取远程客户端信息的命令。一般用户排错。例如在server端获取不到客户端的内存数据，咱们可使用zabbix_get获取客户端的内容的方式来作故障排查。
3）zabbix_sender
zabbix工具，用于发送数据给server或者proxy，一般用于耗时比较长的检查。不少检查很是耗时间，致使zabbix超时。因而咱们在脚本执行完毕以后，使用sender主动提交数据。
4）zabbix_server
zabbix服务端守护进程。zabbix_agentd、zabbix_get、zabbix_sender、zabbix_proxy、zabbix_java_gateway的数据最终都是提交到server
备注：固然不是数据都是主动提交给zabbix_server,也有的是server主动去取数据。
5）zabbix_proxy
zabbix代理守护进程。功能相似server，惟一不一样的是它只是一个中转站，它须要把收集到的数据提交/被提交到server里。为何要用代理？代理是作什么的？卖个关子，请继续关注运维生存时间zabbix教程系列。
6）zabbix_java_gateway
zabbix2.0以后引入的一个功能。顾名思义：Java网关，相似agentd，可是只用于Java方面。须要特别注意的是，它只能主动去获取数据，而不能被动获取数据。它的数据最终会给到server或者proxy。

7、zabbix监控环境中基本概念

主机（host）：要监控的网络设备，可由IP或DNS名称指定；
主机组（host group）：主机的逻辑容器，能够包含主机和模板，但同一个组织内的主机和模板不能互相连接；主机组一般在给用户或用户组指派监控权限时使用；
监控项（item）：一个特定监控指标的相关的数据；这些数据来自于被监控对象；item是zabbix进行数据收集的核心，相对某个监控对象，每一个item都由"key"标识；
触发器（trigger）：一个表达式，用于评估某监控对象的特定item内接收到的数据是否在合理范围内，也就是阈值；接收的数据量大于阈值时，触发器状态将从"OK"转变为"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接口；

8、zabbix的监控架构

在实际监控架构中，zabbix根据网络环境、监控规模等 分了三种架构： server-client 、master-node-client、server-proxy-client三种 。
1）server-client架构
也是zabbix的最简单的架构，监控机和被监控机之间不通过任何代理 ，直接由zabbix server和zabbix agentd之间进行数据交互。适用于网络比较简单，设备比较少的监控环境 。
2）server-proxy-client架构
其中proxy是server、client之间沟通的一个桥梁，proxy自己没有前端，并且其自己并不存放数据，只是将agentd发来的数据暂时存放，然后再提交给server 。该架构常常是和master-node-client架构作比较的架构 ，通常适用于跨机房、跨网络的中型网络架构的监控。
三、master-node-client架构
该架构是zabbix最复杂的监控架构，适用于跨网络、跨机房、设备较多的大型环境 。每一个node同时也是一个server端，node下面能够接proxy，也能够直接接client 。node有自已的配置文件和数据库，其要作的是将配置信息和监控数据向master同步，master的故障或损坏对node其下架构的完整性。