共计 3224 个字符，预计需要花费 9 分钟才能阅读完成。
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 由以下几个组件部分构成：
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 的逻辑关系图：
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 根据网络环境、监控规模等 分了三种架构：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-client 架构，该架构是 zabbix 最复杂的监控架构，适用于跨网络、跨机房、设备较多的大型环境。每个 node 同时也是一个 server 端，node 下面可以接 proxy，也可以直接接 client。node 有自已的配置文件和数据库，其要做的是将配置信息和监控数据向 master 同步，master 的故障或损坏对 node 其下架构的完整性。
