zabbix基本概念

Zabbix是一个企业级的、开源的、分布式监控解决方案。

• Zabbix可以监控网络和服务的监控状况.
• Zabbix利用灵活的告警机制，允许用户对事件发送基于Email的告警. 这样可以保证快速的对问题作出相应.
• Zabbix是零成本的. 因为Zabbix编写和发布基于GPL V2协议. 意味着源代码是免费发布的.

一、Linux下开源监控系统简单介绍

1）cacti：存储数据能力强，报警性能差
2）nagios：报警性能差，存储数据仅有简单的一段可以判断是否在合理范围内的数据长度，储存在内存中。比如，连续采样数据存储，有连续三次不在合理范围内的数据就报警
3）zabbix：结合上面两种工具的优点，又可以存储数据，又可以报警。

Agent端：主机通过安装agent方式采集数据

Server端：通过收集agent发送的数据，写入数据库（MySQL，ORACLE），在通过php+apache/nginx在web前端展示

Zabbix=cacti+Nagios 

优点：基于两款工具（cacti+Nagios）优点于一身并更强大，实现企业级分布式监控

缺点：需在被监控主机上安装agent，所有数据都存在数据库里，产生的数据量很大，瓶颈主要在数据库

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

三、程序构成

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_gataway是可选的，这个需要另外安装。

• Zabbix_server：zabbix服务端守护进程。Zabbix_agentd、zabbix_get、zabbix_sender、zabbix_proxy、zabbix_java_gataway的数据最终都是提交到server，并不是数据都是主动提交给zabbix_server，也有的是sever主动去取数据

• Zabbix_agentd：客户端守护进程，此进程收集客户端数据，例如cpu负载、内存、磁盘使用情况等。

• Zabbix_proxy：zabbix代理守护进程，功能类似server，唯一不同的是它只是一个中转站，它需要把收集到的数据提交/被提交到sever

• Zabbix_get：zabbix工具，单独使用的命令，通常在server或者proxy端执行获取远程客户端信息的命令。通常用来排错。例如在server端获取不到客户端的内存数据，可以使用zabbix_get获取客户端内存的方式来做故障排查。

• Zabbix_sender：zabbix工具，用于发送数据给server或者proxy，通常用于耗时比较长的检查。很多检查非常耗时，导致zabbix超时。于是我们在脚本执行完毕之后，使用sender主动提交数据。

• Zabbix_java_gataway：zabbix2.0之后引入的一个功能，顾名思义：java网关，类似agentd，但是只用于java方面。需要特别注意的是，它只能主动取获取数据，而不能被动获取数据。它的数据最终会给到server或者proxy

• Zabbix_database:MySQL或PostgreSQL

• Zabbix_web:Web GUI

Zabbix的监控流程可以简单描述为：
数据采集-->数据存储-->数据分析-->数据展示-->监控报警

其中：
数据采集：Zabbix通过SNMP、Agent、ICMP、SSH、IPMI等进行数据采集
数据存储：Zabbix存储在MySQL上，也可以存储在其他数据库
数据展示：web界面展示、(移动APP、java_php开发一个web界面也可以)
数据报警：邮件报警、微信报警、短信报警、报警升级机制

Zabbix的监控配置流程可以简单描述为：
告警是由一系列的流程组成，首先是触发器达到阀值，产生一个事件，接下来由Action对事件信息进行处理，其中包括两部分：
第一部分是发送消息，即将告警信息发送给用户。
第二部分是执行命令，即将事件用命令进行处理，达到对事件故障自动尝试恢复的效果。

Host groups（主机组）-->Hosts（主机）-->template(模板)-->Applications（监控项组）-->Items（监控项）-->graph(图形) -->screen (图形分组)-->Triggers（触发器）-->Event（事件）-->Actions（处理动作）-->Media types(告警升级|1.执行远程命令2.发送告警邮件)-->User groups（用户组）-->Users（用户）-->Medias(告警邮件)

在实际生产使用的时候，Items、Trigger、Graph采用模板来进行监控，模板特点就是可以重复的事情一次完成，修改了模板等于修改了所有调用此模板的主机,这样可解放运维的双手.
Graph不是必需的，因为没有配置图形，数据获取并不影响，获取数据是Items的功能。但是对于使用ZabbixWeb界面用户来说，没有图形等于没有数据，因此重要的Items必须添加必要的图形以做可视化展示。如果想集中查看图形，可以通过screen功能。

四、zabbix主动模式和被动模式

一个监控系统运行的大概流程是这样的：
Zabbix agent需要安装到被监控的主机上，它负责定期收集各项数据，并发送到zabbix server端，zabbix server将数据存储到数据库中，zabbix web根据数据在前端进行展现和绘图。

这里agent收集数据分为主动和被动两种模式：
主动：agent请求server获取主动的监控项列表，并主动将监控项内需要检测的数据提交给server/proxy
被动：server向agent请求获取监控项的数据，agent返回数据

zabbix使用proxy代理插件的好处：

一方面可以监控不可达的远程区域；

另一方面当监控项目数以万计的时候使用代理可以有效分担zabbix server压力，也简化分布式监控的维护。

 

说明：

主动、被动模式都是相对于proxy来说的。

proxy主动发送数据就是主动模式；

proxy等待server的请求，再发送数据就是被动模式。

因为主动模式可以有效减轻zabbix server压力，需要监控的东西很多时一定要把监控模式更改为主动监控

 

被动模式流程，被动模式一定要记得设置Server ＝ ServerIP

被动模式工作流程:

Server 打开一个TCP连接

Server发送一个key 为agent.ping

Agent接受这个请求，然后响应< HEADER >< DATALEN >

Server对接受到的数据进行处理

TCP连接关闭

 

主动模式流程，主动模式一定要记得设置ServerActive=ServerIP

Agent向Server建立一个TCP连接

Agent请求需要检测的数据列表

Server响应Agent，发送一个Items列表

Agent允许响应

TCP连接完成本次会话关闭

Agent开始周期性地收集数据

 

监控功能

主机的性能监控、网络设备性能监控、数据库性能监控、多种警告方式、详细的报表图表绘制

监控主机zabbix有专用的agent，可以监控Linux、Windows、FreeBSD等

监控网络设备zabbix通过SNMP、ssh

可监控对象：

设备：服务器、路由器、交换机

软件：OS、网络、应用程序

主机性能指标监控

故障监控：down机、服务不可达、主机不可达

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接口

zabbix的监控架构

在实际监控架构中，zabbix根据网络环境、监控规模等分了三种架构：server-client、master-node-client、server-proxy-client三种。

• server-client架构

也是zabbix最简单的架构，监控机和被监控机直接不经过任何代理，直接由zabbix server和zabbix agentd之间进行数据交互。适用于网络比较简单，设备比较少的监控环境。

• server-proxy-client架构

其中proxy是server、client之间沟通的一个桥梁，proxy本身没有前端，而且其本身并不存放数据，只是将agentd发来的数据暂时存放，而后再提交给server。该架构经常是和master-node-client架构做比较的架构，一般适用于跨机房、跨网络的中型网络架构的监控

• master-node-clinet架构

该架构是zabbix最复杂的监控架构，适用于跨网络、跨机房、设备较多的大型环境。每个node同时也是一个server端，node下面可以接proxy，也可以直接接client。Node有自己的配置文件和数据库，其要做的是将配置信息和监控数据向master同步

zabbix监控范畴

硬件监控：Zabbix IPMI Interface

系统监控：Zabbix Agent Interface

java监控：ZabbixJMXInterface

网络设备监控：Zabbix SNMP Interface

应用服务监控：Zabbix Agent UserParameter

MySQL数据库监控：percona-monitoring-pldlgins

URL监控：Zabbix Web监控

五、基础环境LNMP部署
1）配置好IP、DNS 、网关，确保使用远程连接工具能够连接服务器

im /etc/sysconfig/iptables 
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT           
-A INPUT -m state --state NEW -m tcp -p tcp --dport 3306 -j ACCEPT      
特别提示：很多网友把这两条规则添加到防火墙配置的最后一行，导致防火墙启动失败，正确的应该是添加到默认的22端口这条规则的下面
添加好之后防火墙规则如下所示：

---------------------------------------------------------------------------------------------------
# Firewall configuration written by system-config-firewall 
# Manual customization of this file is not recommended. 
*filter 
:INPUT ACCEPT [0:0] 
:FORWARD ACCEPT [0:0] 
:OUTPUT ACCEPT [0:0] 
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT 
-A INPUT -p icmp -j ACCEPT 
-A INPUT -i lo -j ACCEPT 
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT 
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT 
-A INPUT -m state --state NEW -m tcp -p tcp --dport 3306 -j ACCEPT 
-A INPUT -j REJECT --reject-with icmp-host-prohibited 
-A FORWARD -j REJECT --reject-with icmp-host-prohibited COMMIT
---------------------------------------------------------------------------------------------------
[root@Zabbix-server ~]# /etc/init.d/iptables restart

3）关闭SELINUX 
[root@Zabbix-server ~]# vim /etc/selinux/config 
#SELINUX=enforcing             
#SELINUXTYPE=targeted      
SELINUX=disabled               
[root@Zabbix-server ~]# reboot      //重启后永久生效，或者使用setenforce 0临时生效

4）系统约定 
软件源代码包存放位置：/usr/local/src 
源码包编译安装位置：/usr/local/软件名字

此处参照：nginx1.10.3+php5.6+mysql5.7.0

测试完成后，确保nginx，php，mysql都能正常启动，能够访问php页面

对于运维人员来说，监控是非常重要的，因为如果想要保证线上业务整体能够稳定运行，那么我们则需要实时关注与其相关的各项指标是否正常，而一个业务系统的背后，往往存在着很多的服务器、网络设备等硬件资源，如果我们想要能够更加方便的、集中的监控他们，我们则需要依靠一些外部的工具，而zabbix就是一个被广泛使用的，可以实现集中监控管理的应用程序。

我们监控的初衷就是当某些指标不符合我们的需求时，我们能够在第一时间发现异常，所以，监控工具需要定期的对被监控主机进行检查、信息收集等操作，当被监控主机出现异常时，能够及时报警、通知管理员，并且需要记录这些异常，以便我们分析这些数据，查漏补缺，那么，一个监控工具就应该具备采集信息、存储信息、展示信息、报警通知等功能，而zabbix就可以做到这些，除了zabbix，你可能还听说过cacti、nagios、ganglia等类似的监控系统，但是此处，我们只聊zabbix。

好了，我们大概了解了一下zabbix，那么我们通过zabbix能够监控哪些硬件资源呢，理论上来说，只要是与我们的业务有关的硬件资源，都应该被监控，比如 主机、交换机、路由器、UPS等等，但是，监控它们的前提是能与它们进行通讯，那么问题来了，由于硬件的不同，导致我们无法使用统一的方法去监控他们，这个时候，就需要监控程序有一定的通用性，或者说，监控程序需要能够与多种硬件设备通讯，才能满足我们的监控需求，举个例子：如果被监控的对象是一台安装了linux操作系统的服务器，那么我们可以通过ssh或者telnet这种远程工具与被监控对象建立起通讯的通道，可是如果被监控的对象是一台安装了其他操作系统的服务器呢，更甚之，被监控的对象并不是服务器，而只是一台交换机或者路由器呢，所以，zabbix如果想要能够全面的监控这些对象，则需要能够通过各种方法与它们进行通讯。

那么zabbix能够支持哪些通讯方式呢，总结如下：

1. agent：通过专用的代理程序进行监控，与常见的master/agent模型类似,如果被监控对象支持对应的agent，推荐首选这种方式。
2. ssh/telnet：通过远程控制协议进行通讯，比如ssh或者telnet。
3. SNMP：通过SNMP协议与被监控对象进行通讯，SNMP协议的全称为Simple Network Management Protocol,被译为"简单网络管理协议"，通常来说，我们无法在路由器、交换机这种硬件上安装agent，但是这些硬件往往都支持SNMP协议，SNMP是一种比较久远的、通行的协议，大部分网络设备都支持这种协议，其实SNMP协议的工作方式也可以理解为master/agent的工作方式，只不过是在这些设备中内置了SNMP的agent而已，所以，大部分网络设备都支持这种协议。
4. IPMI：通过IPMI接口进行监控，我们可以通过标准的IPMI硬件接口，监控被监控对象的物理特征，比如电压，温度，风扇状态，电源状态等。
5. JMX：通过JMX进行监控，JMX（Java Management Extensions，即Java管理扩展），监控JVM虚拟机时，使用这种方法也是非常不错的选择。

好了，我们刚才提到了zabbix agent，一般情况下，我们将zabbix agent部署到被监控主机上，由agent采集数据，报告给负责监控的中心主机，中心主机也就是master/agent模型中的master，负责监控的中心主机被称为zabbix server，zabbix server将从agent端接收到的信息存储于zabbix的数据库中，我们把zabbix的数据库端称为zabbix database， 如果管理员需要查看各种监控信息，则需要zabbix的GUI，zabbix的GUI是一种Web GUI，我们称之为zabbix web，zabbix web是使用php编写的，所以，如果想要使用zabbix web展示相关监控信息，需要依赖LAMP环境，不管是zabbix server ，或是zabbix web，他们都需要连接到zabbix database获取相关数据，这样说可能不容易理解，对比下图理解上述概念，就容易许多

当监控规模变得庞大时，我们可能有成千上万台设备需要监控，这时我们是否需要部署多套zabbix系统进行监控呢？如果部署多套zabbix监控系统，那么监控压力将会被分摊，但是，这些监控的对象将会被尽量平均的分配到不同的监控系统中，这个时候，我们就无法通过统一的监控入口，去监控这些对象了，虽然分摊了监控压力，但是也增加了监控工作的复杂度，那么，我们到底该不该建立多套zabbix监控系统从而分摊巨大的监控压力呢？其实，zabbix天生就有处理这种问题的能力，因为zabbix支持分布式监控，我们可以把成千上万台的被监控对象分成不同的区域，每个区域中设置一台代理主机，区域内的每个被监控对象的信息被agent采集，提交给代理主机，在这个区域内，代理主机的作用就好比zabbix server，我们称这些代理主机为zabbix proxy，zabbix proxy再将收集到的信息统一提交给真正的zabbix server处理，这样，zabbix proxy分摊了zabbix server的压力，同时，我们还能够通过统一的监控入口，监控所有的对象，当监控规模庞大到需要使用zabbix proxy时，zabbix的架构如下图，我们可以对比下图，理解上述描述。

此处，我们再把刚才说到的各种组件总结一遍：

1. zabbix agent：部署在被监控主机上，负责被监控主机的数据，并将数据发送给zabbix server。
2. zabbix server:负责接收agent发送的报告信息，并且负责组织配置信息、统计信息、操作数据等。
3. zabbix database：用于存储所有zabbix的配置信息、监控数据的数据库。
4. zabbix web：zabbix的web界面，管理员通过web界面管理zabbix配置以及查看zabbix相关监控信息，可以单独部署在独立的服务器上。
5. zabbix proxy：可选组件，用于分布式监控环境中，zabbix proxy代表server端，完成局部区域内的信息收集，最终统一发往server端。

了解完了zabbix的几个核心组件，我们再来聊聊zabbix的工作模式。

我们知道，agent端会将采集完的数据主动发送给server端，这种模式我们称之为主动模式，即对于agent端来说是主动的。
其实，agent端也可以不主动发送数据，而是等待server过来拉取数据，这种模式我们称之为被动模式。
聪明如你一定已经明白，不管是主动模式还是被动模式，都是对于agent端来说的，而且，主动模式与被动模式可以同时存在，并不冲突。
管理员可以在agent端使用一个名为zabbix_sender的工具，测试是否能够向server端发送数据。
管理员可以在server端使用一个名为zabbix_get的工具，测试是否能够从agent端拉取数据。

好了，我们已经了解了zabbix的一些基本概念，其实zabbix还有很多常用术语，但是现在我们并没有遇到实际的使用场景，空口白话的描述显得特别无力，而且难以理解，我们就先不管它们了，等到用到它们的时候，我们再做解释。

转自：http://www.zsythink.net/archives/447/