Zabbix 核心概念

一、Zabbix 是什么（本质）

Zabbix = 基于事件驱动的集中式监控系统

核心目标只有三件事：

采集数据（Monitoring）
判断状态（Trigger / Event）
产生动作（Alert / Action）

一句话公式：

数据（Item） -> 判断（Trigger） -> 事件（Event） -> 动作（Action）

二、整体架构与工作模型

1️⃣ Zabbix 逻辑架构

[ Host ]
   ↓
[ Item ]  -> 数据
   ↓
[ Trigger ] -> 状态判断
   ↓
[ Event ] -> 状态变化
   ↓
[ Action ] -> 通知 / 脚本

这是 Zabbix 的核心抽象模型。

2️⃣ 组件架构

Agent / SNMP / HTTP
        ↓
   Zabbix Server
        ↓
   Database
        ↓
   Frontend

Zabbix Server：调度、计算、判断中心
Database：事实来源（Single Source of Truth）
Frontend：展示与配置入口

Zabbix 是 Server + DB 强耦合系统

三、核心对象模型（最重要）

1️⃣ Host（主机）

Host = 被监控对象的抽象

可以是：

物理机
虚拟机
容器
网络设备
一组服务（逻辑主机）

Host 只是一个“容器”，本身不采集数据

2️⃣ Item（监控项）

Item = 数据采集定义

决定：

采集什么
怎么采集
多久采集一次

示例：

system.cpu.load[percpu,avg1]
vfs.fs.size[/,pfree]

Item 三要素：

Key（采集什么）
Interval（多久采一次）
Type（怎么采）

3️⃣ Item Type（采集方式）

常见类型：

Zabbix agent / agent(active)
SNMP
HTTP agent
External check
Trapper
Dependent item

理论重点：

Item type 决定了数据流向（pull / push）

4️⃣ Trigger（触发器）

Trigger = 对 Item 数据的逻辑判断

本质：

一个布尔表达式（True / False）

示例：

avg(5m) > 80
last() < 20

Trigger 只关心：

当前状态是否异常
是否发生“状态变化”

5️⃣ Event（事件）

Event = Trigger 状态发生变化的瞬间

OK -> PROBLEM
PROBLEM -> OK

Zabbix 是事件驱动系统，不是轮询告警

6️⃣ Action（动作）

Action = 对 Event 的响应策略

可以做：

发送告警
执行脚本
自动修复
升级通知（Escalation）

四、数据采集原理（核心理论）

1️⃣ Pull vs Push 模型

被动（Pull）

Server -> Agent

Server 主动拉取数据
防火墙复杂时不友好

主动（Push）

Agent -> Server

Agent 主动推送
云环境 / 容器首选

2️⃣ Poller 线程模型（Server 内部）

Zabbix Server 是多进程模型：

进程	作用
poller	拉 agent 数据
http poller	HTTP 检查
discoverer	自动发现
pinger	ICMP
trapper	接收推送
alerter	发送告警
housekeeper	清理历史

理论要点：

性能瓶颈 = poller + DB

五、模板与继承模型

1️⃣ Template（模板）

Template = Item + Trigger + Graph 的集合

模板的意义：

复用
标准化
批量管理

2️⃣ 模板继承

Template OS Linux
        ↑
Template App MySQL
        ↑
Host

Host 可以继承多个模板
模板之间也可继承

3️⃣ LLD（低级别自动发现）

LLD = 动态创建 Item / Trigger

原理：

先发现对象
再生成监控项原型

常用于：

磁盘
网卡
容器
数据库表

六、数据生命周期（底层逻辑）

1️⃣ History vs Trends

类型	内容	用途
history	原始数据	精细分析
trends	聚合数据	长期展示

Zabbix 默认：

history：秒级
trends：小时级

2️⃣ 为什么要趋势表？

数据库写入量指数级增长

趋势表 = 降维存储

七、告警系统理论（重点）

1️⃣ 告警不是数据异常

Item 采集的是数据
Trigger 判断的是状态
Event 才是“告警事件”

2️⃣ 告警抖动的本质

数据波动 ≠ 状态变化

解决手段：

平滑（avg / min）
迟滞（hysteresis）
时间窗口

八、Proxy 的理论意义

Proxy 本质是：

边缘采集节点
数据缓冲器
Server 的扩展

Agent -> Proxy -> Server

理论价值：

降低 Server 压力
提高稳定性
支持分布式

九、Zabbix 的设计哲学

1️⃣ 强一致性优先

数据必须落库
状态必须可追溯

2️⃣ 告警是第一公民

事件驱动
多级 Escalation

3️⃣ 面向基础设施

设备 / OS / 网络优先
云原生不是最强项

十、和 Prometheus 的本质区别（理论级）

维度	Zabbix	Prometheus
核心	事件	指标
模型	Host -> Item	Label
存储	RDB	TSDB
告警	内置	Alertmanager
适用	传统 IT	云原生

十一、总结

Zabbix 是“以事件为中心”的传统监控系统，擅长基础设施、设备和告警管理；

Prometheus 是“以指标为中心”的云原生监控系统，擅长时序数据分析。