Zabbix-基础架构

Zabbix 简介

zabbix 是一个基于 WEB 界面的提供分布式系统监视以及网络监视功能的企业级的开源 解决方案。 zabbix 能监视各种网络参数，保证服务器系统的安全运营；并提供灵活的通 知机制以让系统管理员快速定位./解决存在的各种问题。

核心组件

Zabbix Server

• 功能：中央处理单元，负责接收监控数据、触发告警、执行自动化任务及存储数据到数据库。
• 关键进程：
  • Poller：主动从 Agent 拉取数据（被动模式）。
  • Trapper：接收 Agent 主动推送的数据（主动模式）。
  • Alert/Notifier：处理告警规则并发送通知（邮件/短信等）。

Zabbix Agent

• 部署：安装在被监控主机上（支持 Linux/Windows 等），收集本地资源数据（CPU、内存、磁盘等）。
• 工作模式：
  • 被动模式：Server 主动请求数据（默认）。
  • 主动模式：Agent 定期推送数据，主动监控能极大节约监控server 的资源。。

Zabbix Proxy

• 作用：分布式环境中减轻 Server 负载，实现跨地域/网络隔离监控。
• 特性：
  • 本地缓存数据，网络中断后可恢复同步。
  • 单 Proxy 建议承载 ≤5000 监控项。

Zabbix Database

• 存储内容：配置信息、监控数据、历史记录等。
• 支持数据库：MySQL（最常用）、PostgreSQL、Oracle。
• 优化建议：历史数据按周分区，趋势数据按月聚合。

Zabbix Web Interface

• 功能：基于 PHP 的 Web 前端，提供配置管理、数据可视化、告警查看等。
• 依赖环境：Apache/Nginx + PHP 7.2+。

Zabbix进程

默认情况下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_java_gateway： zabbix2.0 之后引入的一个功能。顾名思义：Java 网关，类似 agentd，但是只用于 Java方面。需要特别注意的是，它只能主动去获取数据，而不能被动获取数据。 它的数 据最终会给到server或者proxy。

数据采集流程

1. Agent 数据采集

   • Agent 收集主机性能指标（如通过 /proc 文件系统）。
   • 支持自定义监控项（UserParameters）扩展采集范围。

2. 数据传输

   • 被动模式：Server 轮询 Agent（默认 10050/TCP 端口）。
   • 主动模式：Agent 主动发送数据到 Server/Proxy（端口 10051）。

3. Server 数据处理

   • 数据校验 → 触发器规则匹配 → 触发告警 → 存储到数据库。

4. 数据存储与展示

   • 数据库持久化存储 → Web 界面生成图表/报表。

架构模式

根据规模与网络复杂度，Zabbix 支持三种架构：

架构类型	适用场景	核心特点
Server-Client	小型环境（≤100 节点）	直连模式，无代理层；适合局域网环境。
Server-Proxy-Client	中型环境（100–5000 节点）	Proxy 分担 Server 负载，支持跨机房/防火墙；数据缓存保障可靠性。
Master-Node-Client	超大规模（≥5000 节点）	多级 Node 同步数据，Master 故障不影响 Node；数据库分片提升性能。

Zabbix 常用术语

• 主机（host） ：要监控的网络设备，可由 IP 或 DNS 名称指定；
• 主机组（host group）：主机的逻辑容器，可以包含主机和模板，但同一个组织内的主机和模 板不能互相链接；主机组通常在给用户或用户组指派监控权限时使用；
• 监控项（item） ：一个特定监控指标的相关的数据；这些数据来自于被监控对象；item是 zabbix进行数据收集的核心，相对某个监控对象，每个 item 都由"key"标识；
• 触发器（trigger） ： 一个表达式，用于评估某监控对象的特定 item 内接收到的数据是否在 合理范围内，也就是阈值；接收的数据量大于阈值时，触发器状态将从"OK"转变 为"Problem"，当数据再次恢复到合理范围，又转变为"OK"；
• 事件（event） ：触发一个值得关注的事情，比如触发器状态转变，新的 agent 或重新上线的agent 的自动注册等；
• 异常 (problem)：一个处在“异常”状态的触发器
• 动作（action） ：指对于特定事件事先定义的处理方法，如发送通知，何时执行操作；
• 升级 (escalation)：一个在动作内执行操作的自定义场景; 发送通知/执行远程命令的序列
• 报警媒介类型（media） ：发送通知的手段或者通道，如 Email、Jabber 或者 SMS 等；
• 通知 (notification)：利用已选择的媒体途径把跟事件相关的信息发送给用户
• 远程命令 (remote command)：一个预定义好的，满足一些条件的情况下，可以在被监控主机上自动执行的命令
• 模板 （template） ： 用于快速定义被监控主机的预设条目集合， 通常包含了 item、 trigger、graph、 screen、 application 以及 low-level discovery rule；模板可以直接链接 至某个主机；
• 应用 (application)：一组监控项组成的逻辑分组
• web 场景 (web scenario)：利用一个或多个HTTP请求来检查网站的可用性
• 前端（frontend） ： Zabbix提供的web界面
• Zabbix API：Zabbix API允许你使用JSON RPC协议 (是一个无状态且轻量级的远程过程调用（RPC）传送协议，其传递内容透过 JSON 为主) 来创建、更新和获取Zabbix对象（如主机、监控项、图形和其他）信息或者执行任何其他的自定义的任务
• Zabbix server：Zabbix软件实现监控的核心程序，主要功能是与Zabbix proxies和Agents进行交互、触发器计算、发送告警通知；并将数据集中保存等
• Zabbix agent：
  • 一个部署在监控对象上的，能够主动监控本地资源和应用的程序
  • Zabbix agent 部署在监控的目标上，主动监测本地的资源和应用(硬件驱动，内存，处理器统计等)。
  • Zabbix agent收集本地的操作信息并将数据报告给Zabbix server用于进一步处理。一旦出现异常 (比如硬盘空间已满或者有崩溃的服务进程), Zabbix server会主动警告管理员指定机器上的异常。. Zabbix agents 的极端高效缘于它可以利用本地系统调用来完成统计数据的收集。
• 被动检查（passive check） ：模式中 agent 应答数据请求，Zabbix server（或者proxy）询问agent数据,如CPU 的负载情况，然后 Zabbix agent 回送结果。
• 主动检查（Active checks） ：处理过程将相对复杂。 Agent 必须首先从 Zabbix sever 索取监控项列表以进行独立处理，然后周期性地发送新的值给server。
• Zabbix proxy：abbix Proxy 是一个可以从一个或多个受监控设备收集监控数据，并将信息发送到Zabbix sever的进程，基本上是代表 sever工作的。 所有收集的数据都在本地进行缓存，然后传送到 proxy 所属的 Zabbix sever。