zabbix监控的基础概念、工作原理及架构
转载于网络
一、什么是zabbix及优缺点
Zabbix能监视各种网络参数，保证服务器系统的安全运营，并提供灵活的通知机制以让系统管理员快速定位/解决存在的各种问题。是一个基于WEB界面的提供企业级的开源分布式系统监视以及网络监视功能的企业级的开源解决方案。
Agent端：主机通过安装agent方式采集数据
Server端：通过收集agent发送的数据，写入数据库（MySQL，ORACLE），在通过php+apache/nginx在web前端展示
Zabbix=cacti+Nagios
优点：基于两款工具（cacti+Nagios）优点于一身并更强大，实现企业级分布式监控
缺点：需在被监控主机上安装agent，所有数据都存在数据库里，产生的数据量很大，瓶颈主要在数据库
二、监控功能
主机的性能监控、网络设备性能监控、数据库性能监控、多种警告方式、详细的报表图表绘制
监控主机zabbix有专用的agent，可以监控Linux、Windows、FreeBSD等
监控网络设备zabbix通过SNMP、ssh
可监控对象：
设备：服务器、路由器、交换机
软件：OS、网络、应用程序
主机性能指标监控
故障监控：down机、服务不可达、主机不可达
三、工作原理
一个监控系统运行的大概流程是这样的：
Zabbix agent需要安装到被监控的主机上，它负责定期收集各项数据，并发送到zabbix server端，zabbix server将数据存储到数据库中，zabbix web根据数据在前端进行展现和绘图。
这里agent收集数据分为主动和被动两种模式：
主动：agent请求server获取主动的监控项列表，并主动将监控项内需要检测的数据提交给server/proxy
被动：server向agent请求获取监控项的数据，agent返回数据
四、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_agentd：客户端守护进程，此进程收集客户端数据，例如cpu负载、内存、磁盘使用情况等。
Zabbix_get：zabbix工具，单独使用的命令，通常在server或者proxy端执行获取远程客户端信息的命令。通常用来排错。例如在server端获取不到客户端的内存数据，可以使用zabbix_get获取客户端内存的方式来做故障排查。
Zabbix_sender：zabbix工具，用于发送数据给server或者proxy，通常用于耗时比较长的检查。很多检查非常耗时，导致zabbix超时。于是我们在脚本执行完毕之后，使用sender主动提交数据。
Zabbix_server：zabbix服务端守护进程。Zabbix_agentd、zabbix_get、zabbix_sender、zabbix_proxy、zabbix_java_gataway的数据最终都是提交到server，并不是数据都是主动提交给zabbix_server，也有的是sever主动去取数据
Zabbix_proxy：zabbix代理守护进程，功能类似server，唯一不同的是它只是一个中转站，它需要把收集到的数据提交/被提交到sever
Zabbix_java_gataway：zabbix2.0之后引入的一个功能，顾名思义：java网关，类似agentd，但是只用于java方面。需要特别注意的是，它只能主动取获取数据，而不能被动获取数据。它的数据最终会给到server或者proxy
五、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监控