Zabbix功能概述及架构介绍（理论篇）

可用性及性能检测

支持SNMP(trapping及polling)、IPMI、JMX监控

自定义检测

自定义间隔收集收据

server/proxy/agents实现分布监控环境

允许灵活地自定义故障阀值，Zabbix中称为触发器(trigger), 存储在后端数据库中

可以自定义告警升级(escalation)、接收者及告警方式

告警信息可以配置并允许使用宏(macro)变量

通过远程命令实行自动化动作(action)

通过内置的绘图引擎实现监控数据实时绘图

允许自定义创建多监控项视图

网络拓扑(network maps)

自定义的面板(screen)和slide shows，并允许在dashboard页面显示

报告

高等级(商业)监控资源

数据存储在数据库中

历史数据可配置

内置数据清理机制

主机通过添加监控设备方式添加

一次配置，终生监控(除非调整或删除)

监控设备允许使用模板

模板中可以添加组监控

模板允许继承

自动发现网络设备

agent自动注册

自动发现文件系统、网卡设备、SNMP OID等

web前端采用php编写

访问无障碍

你想怎么做就能做么做

审计日志

Zabbix API提供程序级别的访问接口，第三方程序可以很快接入

安全的权限认证

用户可以限制允许维护的列表

在监控目标上部署

支持Linux及Windows

C开发，高性能，低内存消耗

易移植

通过Zabbix proxy可以非常容易的创建远程监控

1.3 Zabbix功能

监控拓扑图说明：

（1）可以通过微信、短信、邮件实现自动报警机制

（2）可以通过Web页面进行配置，监控状态查看

（3）可以通过SNMP协议实现对打印机、路由器、交换机的设备的监控

     通过在植入agent的方式对服务器主机进行监控

     通过ping或者是port检查的方式实现IP和PORT的监控

可实现大多数系统的监控，包括windows、Linux、unix、Solaris、Mac等等，如图：

对主机可监控项包括：

CPU：CPU负载，CPU使用率

Memory：内存使用率，可交换内存/虚拟内存使用率

Network：网络传输、网络故障、丢包

Disk：磁盘使用率，磁盘I/O

Service：进程监控、界面服务、TCP端口连接，响应时间、dns监控、NTP监控

Log：日志监控，文本日志，事件日志

File：文件监控

Other：性能计数器（仅限于Windows系统）

自定义报警机制：

如图所示，

如果故障在10分钟没有被解决，可以短信或邮件通知系统管理员

如果故障在15分钟没有被解决，可以短信或邮件通知运维人员

如果故障在30分钟没有被解决，可以短信或邮件通知经理

可以通过proxy代理服务器，代理Zabbix server搜集被监控的监控数据，并统一发送到Server端

2、zabbix程序架构

架构图如下：

Zabbix各组件的说明：

Zabbix Server为核心组件，用来获取agent存活状况及监控数据。所有的配置、统计、操作数据均通过Server进行存取到database

所有的Zabbix数据均存储在数据库中

为了更简单的无障碍的访问Zabbix, 所以提供了web接口。该接口作为Zabbix Server的一部分，通常和server运行在同一台主机上

注意：如果采用SQLite作为数据库，web接口和Zabbix Server必须运行在同一台主机上

Zabbix Proxy能够代替Zabbix Server进行性能及可用性数据采集。Proxy是Zabbix部署的可选组件。 如果想分担单一Zabbix Server负载，推荐使用proxy。

Zabbix agents 部署在目标监控机上并监控本地资源和应用，将收集数据汇报给Zabbix Server

通过zabbix监控数据流，并采取相应的措施。

首先要创建一个host，再创建一个item来搜集数据

通过item来创建触发器(trigger)

通过触发器(trigger)来创建一个动作（action）

例如：如果你想监控一个服务器的CPU负载状况，你首先为该服务器创建一个主机条目，其次是创建一个item来监控服务器的CPU状况，并创建相应的触发机制，当cpu负载达到某个阀值，触发操作，该操作包括执行设定的动作和发送邮件报警。

可以将这些操作设置成一个模板，要监控某台主机的时候，直接套用模板即可。

Zabbix各组件结构图：

Zabbix相关术语：

相关名词解释：

主机(host)

一个你想监控的网络设备(需要知道IP/DNS)

主机组(host group)

一个逻辑的主机组，它包含主机和模板。主机和模板在同一个主机内的话模板不能被link到其他上。主机组通常用于给不同的用户组创建访问权限

监控项(item)

你想从主机中收集到的数据

触发器(trigger)

一个逻辑表达式，用来表达从监控项获取的数据达到了预设的故障阀值

当接收到的监控值达到了预设的阀值，则触发器状态由’OK’变更为’Problem’，当收到的监控值低于阀值，则状态保持/变更为’OK’

事件(event)

一个事情发生如触发器状态变更或一个自动发现(discovery)/agent自动注册等

动作(action)

当一个事件发生时预设的处理过程

一个动作(action)包括操作(operations，如发送告警)和条件(当指定的操作完成)

告警升级(escalation)

在动作中一个自定的操作执行过程，一个发送告警/执行远程命令的队列

媒介(media)

发送告警的渠道

告警(notification)

通过媒介(media)渠道发送事件的消息

远程命令(remote command)

当监控主机达到某些条件(condition)后预设的自动执行的命令

模板(template)

一组包含监控项、触发器、绘图、面板(screen)、应用、低级别自动发现规则等并且能被其他主机应用的实体

模板能够提升主机部署监控任务的速度，同时也非常容易对监控任务做批量(mass)更新。模板被主机链接(link).

应用(application)

监控项逻辑组

web方案(scenario)

对一个web站点可用性进行检查的一个或多个http请求

前端(frontend)

Zabbix提供的web接口

Zabbix API

Zabbix API允许通过JSON RPC协议去创建、更新、获得Zabbix对象(如主机、监控项、绘图等等)以及完成自定义任务

Zabbix server

Zabbix软件中心进程，用于连通Zabbix proxy及agent完成监控、评估触发器、发送告警以及中心数据存储

Zabbix agent

部署在监控主机上的进程，用于监控本地资源和应用

Zabbix proxy

替代Zabbix server完成数据收集的进程，通常用于降低中心Zabbix Server的负载

节点(node)

一套完整的Zabbix server配置，通常位于分布式系统中，用于负责本区域的监控

Zabbix工作流程图：

Server

Zabbix server是Zabbix软件的核心进程。

Server通过polling和trapping采集数据来判断是否达到阀值，从而使用触发器发送报警给用户。Server也可以通过简单服务检查(simple service check)来完成远程网络服务检测。

Server既是保存所有配置、统计和操作数据的数据库，也是故障报警服务。

Zabbix server根据不同功能可划分为三个部分：Zabbix server、Web GUI及Database。

由于Zabbix的所有的配置信息保存在数据库中，server和web GUI可以直接进行操作。比如，通过Web界面(或者API)创建一个新的监控项时，它将创建的数据插入数据库。一分钟左右Zabbix server会查询监控项数据表，并将查询的监控项列表保存在自己的缓存(cache)中。这也是为什么通过Zabbix前端进行的变更将在两分钟左右生效的原因。

Zabbix server以守护(daemon)进程方式运行。

Zabbix server默认要求运行在非root账户下。

如果Zabbix server和agent运行在同一台主机上，建议分别运行在不同的用户下，因为一旦运行的同一个用户下，agent将可以访问server的配置文件，并且能够轻松取得Zabbix Admin级别用户，例如，数据库密码。

Zabbix server在以下平台进行过测试:

Linux

Solaris

AIX

HP-UX

Mac OS X

FreeBSD

OpenBSD

NetBSD

SCO Open Server

Tru64/OSF1

Agent：

Zabbix agent部署在被监控主机上用来监控本地资源和应用（如硬盘、内存、处理器等）。

Zabbix agent收集本地主机运行信息并将数据发送给Zabbix server进行处理. 一旦出现异常(如硬盘满或服务进程中断)， Zabbix server会自动响应并进行报警操作。

Zabbix agent利用本地系统调用完成统计信息收集，因此它非常的高效。

被动(passive)和主动(active)检查

Zabbix agent提供被动和主动检查方式。

在 被动检查 模式中agent应答数据请求，Zabbix server或者proxy询问agent数据，如CPU load，然后Zabbix agent回送结果给server.

主动检查 处理过程将相对复杂，agent必须先进行一次请求Zabbix server索取监控项列表，然后发送对应的值给server.

选择是被动还是主动检查，需要在 监控项类型 中选择’Zabbix agent’或者’Zabbix agent (active)’。

Zabbix agent运行在被监控主机上，可以通过守护进行的方式运行。

Zabbix agent一般要求运行在非root账户下。

如果你在’root’账户下启动Zabbix agent，它将自动选择在操作系统中建立的’zabbix’用户，除非你修改agent配置文件中’AllowRoot’参数。

Zabbix agent支持以下平台:

Linux

IBM AIX

FreeBSD

NetBSD

OpenBSD

HP-UX

Mac OS X

Solaris

Windows: 2000, Server 2003, XP, Vista, Server 2008, 7

代理proxy

Zabbix代理(proxy)通常用于替代server收集监控信息并将数据发送给Zabbix server。所收集数据会先存储在代理主机的缓存中然后传送给Zabbix server。

代理是可选的，不过使用它可以有效的降低分布式环境中单一的Zabbix server负载。通过代理去收集监控数据，server可以有效降低CPU和磁盘I/O消耗。

Zabbix代理可以出色的完成远程区域、分支机构、无本地管理员的网络的集中监控。

Zabbix代理使用独立的数据库。

注意：Zabbix proxy数据库可以使用SQLite, mysql, PostgreSQL. 如果Oracle或IBM DB2在低等级自动发现规则时存在限制和风险。

Zabbix proxy作为守护进程运行。

Zabbix proxy一般要求运行在非root账户下。

如果在’root’账户运行，它将自动选择之前已经在操作系统建立的’zabbix’用户，但是无法在编译时或在配置文件中进行配置。

Java gateway

zabbix2.0之后引入的一个功能。Java网关，类似agentd，但是只用于监控运行在Java虚拟机上的Java应用。它只能主动去获取数据，而不能被动获取数据。它的数据最终会给到server或者proxy。

Zabbix 2.0通过Zabbix Java gateway的守护进程对JMX应用进行监控。Zabbix Java gateway是采用Java编写的一个守护进程，Zabbix Java gateway利用 JMX API 去请求远程的有关应用。

Java gateway接受来自Zabbix server或者proxy的连接。在Zabbix server或proxy的配置文件中指定JAVA gateway的IP和端口，因此在每一个Zabbix server或proxy中只能配置一个Java gateway。

当在Java gateway上的一个监控项值更新了，Zabbix server或代理将连接Java gateway请求该值。同样的，Java gateway不会缓存任何值。

Zabbix server或代理可以通过 StartJavaPollers 控制连接Java gateway的进程。Java gateway在内部通过 START_POLLERS 控制选项使用多线程启动。 在Zabbix Server端，如果一个连接请求超过了 Timeout 设定的秒数，连接将会终止，但Java gateway也许此时依然忙于从JMX计数器中检索该值。

建议 StartJavaPollers 小于或等于 START_POLLERS ，否则可能导致当连接Java gateway时而Java gateway没有多余的线程进行处理。

当Java gateway已经运行，需要在 server配置文件 中指定JavaGateway的IP和端口，如果JMX应用采用Zabbix代理进行监控的话，你需要在 代理配置文件 中指定对应的连接参数。

Sender

Zabbix sender命令行工具常用于发送性能数据给Zabbix server。

该工具常用于在长时间运行的用户自定义脚本中以便不断发送可用性及性能数据。

Get

Zabbix get用于连接Zabbix agent并从agent上检索需要的信息。