来自网站：http://www.361way.com/zabbix-summarize/3335.html
一、zabbix的特点
zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。zabbix能监视各种网络参数，保证服务器系统的安全运营；并提供灵活的通知机制以让系统管理员快速定位/解决存在的各种问题。这是百度百科上对zabbix上的一段定义，市面上的监控软件很多，为什么选择zabbix呢？先来看下其具有的特点：
1，自动发现服务器和网络设备。
2，底层自动发现
3，分布式的监控体系和集中式的web管理
4，支持主动监控和被动监控模式
5，支持多种操作系统 Linux, Solaris, HP-UX, AIX, FreeBSD, OpenBSD, OS X
6，高效的agent 支持 Linux, Solaris, HP-UX, AIX, FreeBSD, OpenBSD,OS X, Tru64/OSF1, Windows NT4.0, Windows 2000, Windows 2003, Windows XP, Windows Vista 环境
7，无agent监控等多种监控方法。
8，安全的用户认证模式
9，灵活的用户权限设置。
10，基于web的管理方法。
11，支持自由的自定义事件和邮件发送。
12，高水平的业务视图监控资源。
13，支持日志审计。
二、zabbix的组件及进程
组件
zabbix由以下几个组件部分构成：
1、Zabbix Server：负责接收agent发送的报告信息的核心组件，所有配置，统计数据及操作数据均由其组织进行；
2、Database Storage：专用于存储所有配置信息，以及由zabbix收集的数据；
3、Web interface：zabbix的GUI接口，通常与Server运行在同一台主机上；
4、Proxy：可选组件，常用于分布监控环境中，代理Server收集部分被监控端的监控数据并统一发往Server端；
5、Agent：部署在被监控主机上，负责收集本地数据并发往Server端或Proxy端；
注：zabbix node也是 zabbix server的一种 。
进程
默认情况下zabbix包含5个程序：zabbix_agentd、zabbix_get、zabbix_proxy、zabbix_sender、zabbix_server，另外一个zabbix_java_gateway是可选，这个需要另外安装。下面来分别介绍下他们各自的作用。
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_gateway的数据最终都是提交到server
备注：当然不是数据都是主动提交给zabbix_server,也有的是server主动去取数据。
zabbix_proxy
zabbix代理守护进程。功能类似server，唯一不同的是它只是一个中转站，它需要把收集到的数据提交/被提交到server里。为什么要用代理？代理是做什么的？卖个关子，请继续关注运维生存时间zabbix教程系列。
zabbix_java_gateway
zabbix2.0之后引入的一个功能。顾名思义：Java网关，类似agentd，但是只用于Java方面。需要特别注意的是，它只能主动去获取数据，而不能被动获取数据。它的数据最终会给到server或者proxy。
下图是zabbix的逻辑关系图：
三、zabbix监控环境中相关术语
1、主机（host）：要监控的网络设备，可由IP或DNS名称指定；
2、主机组（host group）：主机的逻辑容器，可以包含主机和模板，但同一个组织内的主机和模板不能互相链接；主机组通常在给用户或用户组指派监控权限时使用；
3、监控项（item）：一个特定监控指标的相关的数据；这些数据来自于被监控对象；item是zabbix进行数据收集的核心，相对某个监控对象，每个item都由"key"标识；
4、触发器（trigger）：一个表达式，用于评估某监控对象的特定item内接收到的数据是否在合理范围内，也就是阈值；接收的数据量大于阈值时，触发器状态将从"OK"转变为"Problem"，当数据再次恢复到合理范围，又转变为"OK"；
5、事件（event）：触发一个值得关注的事情，比如触发器状态转变，新的agent或重新上线的agent的自动注册等；
6、动作（action）：指对于特定事件事先定义的处理方法，如发送通知，何时执行操作；
7、报警升级（escalation）：发送警报或者执行远程命令的自定义方案，如每隔5分钟发送一次警报，共发送5次等；
8、媒介（media）：发送通知的手段或者通道，如Email、Jabber或者SMS等；
9、通知（notification）：通过选定的媒介向用户发送的有关某事件的信息；
10、远程命令（remote command）：预定义的命令，可在被监控主机处于某特定条件下时自动执行；
11、模板（template）：用于快速定义被监控主机的预设条目集合，通常包含了item、trigger、graph、screen、application以及low-level discovery rule；模板可以直接链接至某个主机；
12、应用（application）：一组item的集合；
13、web场景（web scennario）：用于检测web站点可用性的一个活多个HTTP请求；
14、前端（frontend）：Zabbix的web接口；
下图是一个zabbix的流程图，其串联了各术语之间的关系
四、zabbix的监控架构
在实际监控架构中，zabbix根据网络环境、监控规模等 分了三种架构： server-client 、master-node-client、server-proxy-client三种 。
server-client架构
上图是server-client架构，也是zabbix的最简单的架构，监控机和被监控机之间不经过任何代理 ，直接由zabbix server和zabbix agentd之间进行数据交互。适用于网络比较简单，设备比较少的监控环境 。
server-proxy-client架构
上图是server-proxy-client架构，其中proxy是server、client之间沟通的一个桥梁，proxy本身没有前端，而且其本身并不存放数据，只是将agentd发来的数据暂时存放，而后再提交给server
。该架构经常是和master-node-client架构做比较的架构 ，一般适用于跨机房、跨网络的中型网络架构的监控。
master-node-client架构
上图是master-node-client架构，该架构是zabbix最复杂的监控架构，适用于跨网络、跨机房、设备较多的大型环境
。每个node同时也是一个server端，node下面可以接proxy，也可以直接接client
。node有自已的配置文件和数据库，其要做的是将配置信息和监控数据向master同步，master的故障或损坏对node其下架构的完整性。
原文地址：https://www.cnblogs.com/flytor/p/11645068.html