用 Zabbix 监控一台 Linux 服务器的完整流程：从 Agent 到告警

新机器上架后，第一件事就是纳入监控：CPU、内存、磁盘、网络这些基础指标要有，磁盘写满、关键进程退出这类故障要能主动告警。本文以 Zabbix 6.0 LTS 为例，完整走一遍监控一台 Linux 服务器的流程：Server 快速部署、被监控端装 Agent 2、Web 界面里添加主机并关联模板、读懂关键监控项与触发器、自己加一个自定义监控项，最后把告警通知打通。

适用环境：Zabbix Server 部署在一台独立主机（示例 192.0.2.30），被监控服务器一台（示例 192.0.2.31，CentOS/RHEL 系与 Ubuntu 均可，下文以 RHEL 系命令为主并注明差异）。

前置条件

• 一台用于部署 Zabbix Server 的主机，Docker 与 Docker Compose 可用，至少 2 核 4 GB。
• 被监控服务器能访问 Server 的 10051 端口，Server 能访问被监控端的 10050 端口（防火墙或安全组提前放行）。
• 规划好主机命名：被监控端 Agent 配置的主机名必须与 Web 界面里建的主机名一字不差，这是最高频的翻车点。
• 准备一个告警接收渠道：邮箱 SMTP 参数，或企业微信/钉钉群机器人的 Webhook 地址，先选其一。

第一步：Server 端 Compose 快速部署

官方镜像把 Server、Web（Nginx + PHP）和数据库拆成三个容器，单机体验和小型生产都够用。数据库口令用环境变量注入：

# docker-compose.yaml
services:
  mysql:
    image: mysql:8.0
    container_name: zbx-mysql
    environment:
      - MYSQL_ROOT_PASSWORD=RootPass_ChangeMe
      - MYSQL_DATABASE=zabbix
      - MYSQL_USER=zabbix
      - MYSQL_PASSWORD=ZbxPass_ChangeMe
    command: --character-set-server=utf8mb4 --collation-server=utf8mb4_bin
    volumes:
      - zbx-mysql-data:/var/lib/mysql
    restart: unless-stopped
  server:
    image: zabbix/zabbix-server-mysql:6.0-latest
    container_name: zbx-server
    environment:
      - DB_SERVER_HOST=mysql
      - MYSQL_DATABASE=zabbix
      - MYSQL_USER=zabbix
      - MYSQL_PASSWORD=ZbxPass_ChangeMe
      - MYSQL_ROOT_PASSWORD=RootPass_ChangeMe
    ports:
      - "10051:10051"
    depends_on:
      - mysql
    restart: unless-stopped
  web:
    image: zabbix/zabbix-web-nginx-mysql:6.0-latest
    container_name: zbx-web
    environment:
      - DB_SERVER_HOST=mysql
      - MYSQL_DATABASE=zabbix
      - MYSQL_USER=zabbix
      - MYSQL_PASSWORD=ZbxPass_ChangeMe
      - PHP_TZ=Asia/Shanghai
    ports:
      - "8080:8080"
    depends_on:
      - mysql
      - server
    restart: unless-stopped
volumes:
  zbx-mysql-data:

docker compose up -d 后访问 http://192.0.2.30:8080，默认账号 Admin、密码 zabbix，第一件事就是改密码。

第二步：被监控端安装 Agent 2

Agent 2 是 Go 实现的新一代 agent，插件化扩展、自带 Docker/数据库等监控能力，替代老的 C 版 agent。安装并写配置：

# RHEL 系：加官方源后安装（Ubuntu 改用对应 deb 包源）
rpm -Uvh https://repo.zabbix.com/zabbix/6.0/rhel/9/x86_64/zabbix-release-latest.el9.noarch.rpm
dnf install -y zabbix-agent2

# /etc/zabbix/zabbix_agent2.conf 关键四行
Server=192.0.2.30            # 被动检查：允许哪个 Server 来连
ServerActive=192.0.2.30      # 主动检查：Agent 向哪个 Server 上报
Hostname=web-node-01         # 必须与 Web 界面建的主机名完全一致
ListenPort=10050

systemctl enable --now zabbix-agent2

被动与主动的区别要分清：被动模式是 Server 定期连 Agent 拉数据，依赖 10050 可达；主动模式是 Agent 自己把数据推给 Server 的 10051，适合 Agent 在 NAT 后面连不回去的场景。两种模式对应的监控项类型不同，混用时要与模板、主机接口对齐。

第三步：Web 界面添加主机并关联模板

进入「配置 → 主机 → 创建主机」：主机名称填 web-node-01（与 Agent 的 Hostname 一致），可见名称可填中文备注；主机组选 Linux servers；接口添加 Agent 类型，IP 填 192.0.2.31、端口 10050；模板页签关联官方模板「Linux by Zabbix agent」，启用后保存。回到「监测 → 主机」，等一两分钟看 ZBX 可用性图标变绿，点开「最新数据」能看到 CPU、内存等指标持续更新，即纳管成功。模板的价值在于监控项、触发器、图形都成套继承，新机器关联模板即获得一致的监控标准，调阈值优先改模板，一处生效全量。

第四步：关键监控项与触发器解读

关联模板后先看这几组：CPU 利用率（system.cpu.util）与负载（system.cpu.load[all,avg1]）要分开看——利用率高不等于过载，结合负载和核数判断；内存看可用内存百分比（vm.memory.size[pavailable]）而非已用值，Linux 的缓存占用会让「已用」长期虚高；磁盘看剩余空间百分比和 inode 使用率（vfs.fs.size、vfs.fs.inode），触发器默认在剩余 20% 警告、10% 严重一类分级；网络看网卡进出流量与错误包（net.if.in/out、net.if.errors）。触发器本质是表达式加持续条件，例如「最近 5 分钟可用内存平均低于 20%」，理解「值 + 时间窗 + 恢复表达式」三件套，误报调优就有了抓手。

第五步：自定义一个监控项

以监控某个关键进程是否存在为例。Agent 配置里加 UserParameter 可以实现，但模板自带的 proc.num 键值不用改配置，优先用它：在主机（或模板）的监控项里新建，名称「order-service 进程数」，类型选 Zabbix 代理，键值填：

proc.num[java,,order-service]

再给它配触发器：表达式 {web-node-01:proc.num[java,,order-service].last()}=0，严重程度设为严重，并写好恢复表达式为 last()>0。磁盘类的自定义项同理用 vfs.fs.size[/data,pfree] 盯某个模板没覆盖的挂载点。改完先在「最新数据」里确认能取到值，再看触发器是否按预期触发，不要跳过来值验证直接上告警。

第六步：动作与媒介配置（告警打通）

告警链路三段：媒介类型定义「怎么发」，用户媒介定义「发给谁」，动作定义「什么事件触发发」。最小打通路径：管理 → 报警媒介类型里启用 Email 并填好 SMTP 服务器，或新增一个 Webhook 类型填群机器人地址并写发送脚本；用户 → 自己的账号里添加媒介（邮箱地址或 Webhook 标识）；配置 → 动作 → Trigger actions，确认默认的「Report problems to Zabbix administrators」动作启用、操作里包含发送消息到用户组。测试时手动停掉被监控端的一个测试进程或把触发器阈值临时调到必触发，确认收到通知、恢复后收到恢复通知，一对都到才算打通。

验证

在被监控端执行 dd 写一个大文件把 /data 分区填充率推高到触发阈值以上（先确认业务无影响），观察：最新数据里该项值变化 → 问题列表出现对应触发器事件 → 手机或邮箱收到告警；删除大文件后收到恢复通知。再 systemctl stop zabbix-agent2 一分钟，主机可用性图标变红并产生 Agent 不可达问题，启动后自动恢复。两条路径都走通，监控闭环完成。

常见问题

主机图标一直灰或变红，Agent 不可达。按顺序查：被监控端 agent 进程是否在跑、10050 是否监听；网络层从 Server 主机 telnet 192.0.2.31 10050 是否通；agent 日志（/var/log/zabbix/zabbix_agent2.log）里有没有被拒绝记录；最后核对 Hostname 与 Web 主机名是否完全一致——主动模式下名字对不上，数据会进不来且不报错得明显，是最隐蔽的一种。

数据断点，图上一段段空白。先看是全部监控项断还是个别项：全部断多为网络抖动、Server 负载过高或 agent 重启；个别项断多为该键值采集超时（采集脚本执行慢）或被动检查被排队延迟。Server 端看 zabbix_server 进程的 busy 比例和队列（管理 → 队列），poller 长期打满就该加进程数或拆分 Proxy。

触发器频繁误报。单点阈值最容易被瞬时尖峰触发，改法是给表达式加时间窗：用 avg(5m) 代替 last()，或叠加「持续 N 分钟」的条件；有明显日周期规律的指标（如夜间批处理 CPU 高）用时间条件限定生效时段；实在拿不准的历史基线型指标，先降严重程度观察一周再决定，别直接禁用触发器。

磁盘监控项没有某个挂载点。模板靠 LLD（低级自动发现）按规则扫挂载点，新挂载的分区要等发现周期（默认 1 小时）才会生成监控项，可在主机上手动执行发现规则立即刷新；仍没有的多是发现规则的过滤正则把该类型文件系统排除了。

小结

监控一台机器的闭环并不复杂：Agent 装好、名字对齐、模板关联、告警打通、再亲手触发一次验证。真正的工作量在之后——阈值随业务调优、自定义项随故障复盘补充。先把这台跑稳，再谈批量纳管与模板分层。

Mr丶点心

打赏 海报 链接