学习 Zabbix 系统监控，本文值得收藏 | 周末送资料

Posted 2021-05-30 twt企业IT社区

【导读】本文介绍了Zabbix 基本概念及其特点，阐述 Zabbix 系统环境搭建与基础安装，如何实现对各类操作系统、硬件设备、应用软件监控告警。

【作者】焦育，任职于某车企

目录

1 介绍

2 指标

3 安装部署

4 Windows 系统状态监控

5 Windows 系统硬件信息获取

6 Linux 系统状态监控

7 Linux 系统硬件信息获取

8 VMware 虚拟平台监控

9 邮件告警

10 微信告警

1 介绍

1.1 摘要

本文深入浅出，切近实际运维应用，由 zabbix 3.4 版本入手，学习 zabbix 监控告警实现方式，由 zabbix 5.0 浅出实现快速部署、快速应用。本人从业多年，关注 zabbix 开源社区，以及 zabbix 官方组织的各种峰会，了解到的前沿技术，因随着运维监控软件的不断发展，未来软件将是开箱即用的模式，运维人员在使用监控软件，不必再去花精力编写运维监控程序，而是完善监控项，这样的方式对于初学者越来越不容易学习。因此，学习 zabbix 3.4 版本是非常必要的， zabbix 官方那时候还没有集成更多的模板以直接使用，那里有大量的监控项需要自己编写实现，不仅全面了解了 zabbix ，也是对 linux 命令、 shell 脚本、 Python 语言等的很好学习，也有助于二次开发，自定义监控项的配置。

1.2 背景

以下是部署实施基于 zabbix 监控系统的建设背景，以解决诸多运维实际问题：

目前公司系统运维主要采用人工检查的方式，问题发现的时效性较低，容易出现问题不被立刻发现，人工也容易疏忽漏查，导致问题处理不及时，影响信息化系统服务效果，就需要更好保障系统稳定运行。

公司信息化系统、操作系统、设备种类多，各类信息化系统如：OA 、 U9 ， PLM 、企业邮箱等，又有 Linux 、 Windows 、 VMware 、 EMC 等系统，设备有服务器、交换机、存储等，机房环境有动环系统进行监测。如此众多的信息化系统平台，当然需要统一运维界面，实时监测各系统运行状况，为运维工作提供便利。

为适应时代的发展，未来是个智能化的时代，运维工作要实现自动化，运维工作者要向开发去转变，开发即运维，或许有一天人工智能将代替运维人员，而今的运维人员希望是人工智能创造者的一份子，了解自动化运维，与时俱进是非常必要的。

综上，为了提高运维效率，节约人力资源，对设备、机房环境实时监控，能有效、实时发出告警信息，从而及时发现问题快速响应。急需一套能满足以上需求的监控系统，经考量 zabbix 监控系统应用广泛，可实现上述功能。

1.3 系统简介

Zabbix 是一个企业级解决方案，支持实时监控数千台服务器，虚拟机和网络设备，采集百万级监控指标。Zabbix 完全开源免费。

Zabbix 的主要特点有：

1. 指标收集：从任何设备、系统、应用程序上进行指标采集

2. 问题监测：定义智能阈值

3. 可视化：单一界面管理平台

4. 告警和修复：确保及时、有效的告警

5. 安全和认证：保护您所有层级的数据

6. 轻松搭建部署：大批模板，开箱即用，节省您宝贵的时间

7. 自动发现：自动监控大型动态环境

8. 分布式监控：无限制扩展

9. ZABBIX API ：将 Zabbix 集成到您 IT 环境的其他任何部分

1.4 名词术语

Zabbix 系统有一些自己定义的专业术语，为更好的熟悉系统名词，下面主要介绍本文以及 zabbix 常用的术语。

主机（ host）

一台你想监控的服务器、工作站、交换机等网络设备，用 IP 或者域名表示。

主机组（ host group）

多台具有某种相同角色、属性的集合。例如，所有 windows 服务器放在一个叫 “windows server” 的主机组中。

监控项（ item）

你想要监控、获取主机或主机组的哪些数据。例如：我想监控所有机器的 CPU 使用情况，则需要建一个监控项，用于获取所有服务器的 CPU 使用率。

触发器（ trigger）

由逻辑表达式组成的按照预先设置好的阀值来评估由监控项采集到的数据。触发器有两种状态，分别为 “ 问题 ” 和 “ 已解决 ” 。例如：在上述通过监控项获取了 CPU 的使用率，假如我想超过 CPU 使用超过 80% 的就预警，则可以创建一个触发器，当监控项获取的值超过 80% 时就按照预设的情况报警，状态为 “ 问题 ” ；低于 80% 时认为报警解除，状态恢复为 “ 已解决 ” 。

事件（ event）

单次发生的需要注意的事情，例如上述触发器状态由问题变成了正常或者由正常变成了问题，均可以称为一个事件。事件包括触发器事件、自动发现事件、自动注册事件和内部事件 4 个部分。

动作（ action）

一个对事件做出反应的预定义的操作；例如 CPU 使用超过 80% 时，触发器状态变成了问题，即产生了一个事件，我们可以针对此事件预设一个动作（比如执行命令 reboot ），则系统会自动针对此事件的预设动作执行命令 reboot 。

媒介（ media）

发送告警通知的手段或途径。例如：当 CPU 超过 80% 报警后，通过媒介（邮件、短信、自定义脚本、微信等）形式告知。

模板（ template）

一组可以被应用到一个或多个主机上的实体（监控项，触发器，图形，聚合图形，应用， web 场景等）的集合。简单的说，即多个监控项的集合。

应用集（ application）

一组监控项组成的逻辑分组。例如， CPU 的监控项，归集至 cpu ，在想查看有关 cpu 方面的信息时，可以直接在界面上提供的搜索框内查询所有有关 cpu 的信息。

zabbix server

zabbix 系统实现监控的核心程序，主要功能是与被监控主机、代理机等进行交互、触发器计算、发送告警通知、收集数据并存储等。

zabbix agent

一个部署在监控对象上的，能够主动监控本地资源和应用的程序；一般来讲，我们需要在所有被监控服务器上安装此程序。

zabbix proxy

一个帮助 zabbix server 收集数据，分担 zabbix server 的负载压力的程序；另外，还可以用在 server 与 agent 机器网络不通，使用 proxy 作为网络代理，实现两者的通信功能。

1.5 系统架构

系统结构说明：由 web 、 linux 、 php 、 mysql 等组件部署安装，实现 zabbix server 服务端；由被监控对象例如：Windows 系统， linux 系统、 Vmware 虚拟化平台、交换机，存储等组成了 agent 端。Zabbix server 可采用主动模式，获取 agent 上数据，也可采用被动模式，接收 agent 定时发送的数据。

2 指标

2.1 软件版本

版本选择说明：目前 zabbix 3 版本成熟稳定，各大企业公司运维监控系统运行于该平台上，提供的监控项比 zabbix 第 1 和 2 版本丰富，完全能满足监控对象的需要；至今 zabbix 第 3 版已持续发布 4 年多时间，开源系统积累了大量的资料与研究人员，可供交流学习，能很好服务于 zabbix 定制化；zabbix 4.0 版本 2018 年 10 月正式发布， 4.2 版本于 2019 年 4 月正式发布，目前最新的是 zabbix 5.2 版本，版本持续更新满足未来升级发展的需要，新版本增加了 ELK 、时序数据库，以及前端 web 优化，但监控本质并未发生大的变化。

2.1 硬件指标

名称	CPU/内存	数据库	可监控主机数量
小型	4核心/16G	MySQL + 500GB普通硬盘	500台以内
中型	4核心/32G	MySQL + 500GB普通硬盘	500-1000台
大型	8核心/64G	MySQL + 1TB RAID存储盘	1000-3000台
超大型	16核心/128G	MySQL + 2TB RAID存储盘	3000台以上

Zabbix 可以运行于虚拟环境也可以部署在服务器上，因 zabbix 采集数据主要是文本，对网络带宽要求不高，千兆速率足矣，只要满足性能上的要求即可，主要为 CPU 、内存和硬盘三项。结合 zabbix 官网给出的指标、实际监控项数量、历史记录保存时间长度。根据上表的参考标准，测试环境建议小型化部署。

3 安装部署

Zabbix 安装方式主要是两种：1 、 yum 源安装 2 、 zabbix 源码安装，安装方法互联网上搜索非常多，这里就不再阐述。主要安装组件：PHP 、 Apache 或 nginx 、 Mysql 、 Zabbix 软件包。

4 windows 系统状态监控

本节介绍实现对 windows 系统状态监控。使用zabbix 3.4版本，一起了解学习zabbix监控数据采集过程，这样对我们自定义监控项非常有帮助，提供方法扩展思路 。诚然zabbix 5.0 版本等高版本，许多监控项已经被zabbix agent集成，但那并不利于初学者学习与实践。

通过在被监控主机上，部署安装 zabbix_agent ，实现事件查看器监控、 CPU 监控、内存监控、磁盘读写监控、磁盘容量监控、网卡流量监控、系统时间监控、系统进程和服务监控。

考虑到公司使用的服务器目前多数为 windows server ，对于个别服务器安装了PC 操作系统不深入研究，经测试 Windows 版本支持情况如下表：

版本	是否支持	备注
Windows server 2003	是	需要运行32位程序
Windows server 2008	是
Windows server 2012	是
Windows 7	是
Windows 10	否	测试zabbix-agent程序有报错

4.1 windows 部署 zabbix_agent

为了监控 window 系统，首先需要在该系统下部署 zabbix_agent 代理，用于收集该系统信息。

自研程序包列表：

角色	安装包	说明	适用版本
基于zabbix-agent-3.4.6	Zabbix目录	bin conf script	Windows server 2003、2008、2012

4.1.1 解压安装

Zabbix agent 的原始文件为 zabbix_agents_3.4.6.win.zip ，一般部署是：解压在 window 服务器 C 盘根目录下，再改写 conf 下的配置文件。为了部署方便快捷，现提供已经配置成熟的 zabbix 目录，直接复制 zabbix 目录到 window 服务器的 C 盘根目录下，最后进行程序安装和启动。因此，涉及 C:zabbixscriptconfzabbix_agentd.win.conf 文件的均可以忽略，供学习与交流。

cmd 或 powershell 下安装和启停命令如下：
cd C:zabbixbinwin64
.zabbix_agentd.exe -c C:zabbixconfzabbix_agentd.win.conf -i 安装
.zabbix_agentd.exe -c C:zabbixconfzabbix_agentd.win.conf -s 启动
.zabbix_agentd.exe -c C:zabbixconfzabbix_agentd.win.conf -x 停止

4.1.2 添加端口

Windows 防火墙需要添加端口的出站和入站规则，将 TCP 协议 10050 、 10051 端口开放。不然 zabbix 主动或被动模式就获取不到该设备的数据。10050 10051 是 zabbix 程序使用端口。

4.1.3 配置自启动

Zabbix agent 安装过程中，会自动将 zabbix agent 服务、开机自启动配置好，只需要检查下， agent 是否正常运行即可。

4.2 windows 事件查看器监控

对 windows 系统下 事件查看器中系统日志进行监控和信息获取，将事件查看器中的错误（ Error ）、关键（ Critical ）等系统、程序重要信息打印在 zabbix 界面中，也可以添加监控项，触发器来针对某个信息实现告警。例如：当事件查看器中，有磁盘坏块告警信息时， zabbix 界面会进行告警提示。或是配合研发部门程序日志，程序可将告警信息写入到事件查看器中，zabbix 对其进行监控告警。

4.2.1 zabbix 官网指导说明

https://www.zabbix.com/documentation/3.4/manual/config/items/itemtypes/zabbix_agent/win_keys

截图如下：

4.2.2 创建监控项

类型：必须是 zabbix 客户端（主动式）
键值：参考 zabbix 官方文档，例子

eventlog[System,,"Critical|Error"] 将事件查看器中 “ 系统 ” 栏中 “Critical|Error” 类型的信息过滤出来

eventlog[System,,"Error",".Disk."] 事件查看器中 “ 系统 ” 栏中 “Critical|Error” 类型的信息过滤，并使用正则表达式匹配详细信息中的来源：Disk 的关键字

eventlog[Security,,"Success Audit",,^4624$,,skip].nodata(60)}=0 and

eventlog[Security,,"Success Audit",,^4624$,,skip].regexp(administrator,1)}=0 

如果在 60 秒内有监控到数据，并且监控内容不包含字符串 "administrator" 则触发告警，如果 60 秒内没有新的数据了，则触发器恢复 OK 。简单点说就是，用户登录后触发器触发至少会持续 60 秒，如果用户不断的登录成功，间隔小于 60 秒，则触发器一直是 problem 状态。

应用集：Event 事件日志

4.2.3 创建触发器

名称：{HOST.NAME} 代表主机名

表达式：添加 “ 最新一条日志级别不等于 N” ， N 取值是 0 、 1 或其他， 0 表示正常， 1 和其他值表示不正常。所以 N 取值不等于 0 ，触发告警。

4.2.4 事件查看器注意事项

系统：System 安全：Security

级别：错误（ Error ）、关键（ Critical ）、信息（ Information ）等，参考 zabbix 官网指导说明

来源：一定要看详细信息中的 Provider Name ，次截图上，详细信息与常规来源不一致，一个是 Microsoft-Windows-TerminalServices-Printers ，一个是 TerminalServices-Printers 。容易导致正则匹配出错，建议使用含有匹配的方式。

4.2.5 监控结果

4.3 windows 系统 CPU 监控

4.3.1 监控 CPU 使用率

因为 zabbix 未提供能查看 cpu 使用率的监控项，只提供了 cpu 负载的监控项，就需新增建监控项，监控 CPU 用户使用率与其类似，不再说明。（zabbix 3.4版本）

4.3.2 创建监控项

名称：CPU 使用率

键值：为了规范命名 cpu_time

信息类型：浮点数

更新时间：1m

单位：%

应用集：CPU 状态

4.3.3 创建触发器

名称：CPU 使用率过高：{HOST.NAME}

表达式：{Windows Server Model:cpu_time.avg(5m)}>90 5 分钟均值大于 90% 告警

4.3.4 配置图形

注：根据需要调整绘图风格

4.3.5 配置 zabbix_agentd.win.conf

最后行添加

# CPU 使用率
PerfCounter=cpu_time,"Processor(_Total)% Processor Time",60
# CPU 用户使用率
PerfCounter=cpu_usertime,"Processor(_Total)% User Time",60

注：cpu_time 为 zabbix 界面上监控项配置的键值，虽然可以自定义，但要规范命名。
60 为数据更新时间，单位秒，要小于等于 zabbix 界面上监控项配置 “ 更新时间 ” ，这样才有更新的意义。

配置完成后，重启 zabbix_agentd 生效

cd C:zabbixbinwin64
.zabbix_agentd.exe -c C:zabbixconfzabbix_agentd.win.conf -x
.zabbix_agentd.exe -c C:zabbixconfzabbix_agentd.win.conf -s

4.3.6 监控结果

4.4 windows 系统内存监控

应用集：Memory 内存状态

Memory 内存状态主要监控项有：Memory 内存使用率、 Memory 内存使用量、 Memory 内存总量（带上 Memory 方便了排序归类）。Swap 交换分区使用率、 Swap 交换分区使用量、 Swap 交换分区总量。

zabbix 自带内存监控项，可以直接创建使用。

监控项配置：

说明：windows 系统下没有支持 system.swap.size[pused] ， swap 使用率监控项，一般 swap 分区被使用了，就可以说明物理内存不足，可以使用 pfree 替代。

4.4.1 创建监控项

 以监控内存使用率为例：

名称：内存使用率

键值：vm.memory.size[pused]

其他键值：vm.memory.size[used] vm.memory.size[total]

信息类型：浮点数

更新时间：1m

单位：%

应用集：Memory 内存状态

4.4.2 创建触发器

名称：内存使用率过高：{HOST.NAME}

表达式：{Windows Server Model:vm.memory.size[pused].avg(5m)}>90 5 分钟均值大于 90% 告警

4.4.3 配置图形

4.4.5 监控结果

4.5 windows 磁盘读写监控

Windows 下磁盘监控，可以细分到监控各个磁盘数据如 C 、 D 、 E 等，目前未想到到自发现规则配置，就对所有磁盘进行监控取总体值，以总体值为例进行监控配置。

细分：

LogicalDisk(E:)Disk Write Bytes/sec

LogicalDisk(C:)Disk Write Bytes/sec

LogicalDisk(D:)Disk Write Bytes/sec

LogicalDisk(_Total)Disk Write Bytes/sec

总体：

PhysicalDisk(_Total)Disk Read Bytes/sec

4.5.1 创建监控项

磁盘读写监控项较多，配置监控项如下图：

键值：

disk_read_speed 、 disk_write_speed 、 disk_free_percent 、 disk_rw_percent 、 disk_rw_percent 等。

C:zabbixscriptconfzabbix_agentd.win.conf 文件配置为：

# Disk 磁盘读速率 Bytes/s
PerfCounter=disk_read_speed,"PhysicalDisk(_Total)Disk Read Bytes/sec",60

# Disk 磁盘写速率 Bytes/s
PerfCounter=disk_write_speed,"PhysicalDisk(_Total)Disk Write Bytes/sec",60

# Disk 磁盘空闲状态百分比
PerfCounter=disk_free_percent,"PhysicalDisk(_Total)% Idle Time",60

# Disk 磁盘读和写总共用时百分比
PerfCounter=disk_rw_percent,"PhysicalDisk(_Total)% Disk Time",60

# Disk 磁盘读用时百分比
PerfCounter=disk_read_percent,"PhysicalDisk(_Total)% Disk Read Time",60

# Disk 磁盘写用时百分比
PerfCounter=disk_write_percent,"PhysicalDisk(_Total)% Disk Write Time",60

# Disk 磁盘平均读写队列长度
PerfCounter=disk_queue_length,"PhysicalDisk(_Total)Avg. Disk Queue Length",60

# Disk 磁盘平均读队列长度
PerfCounter=disk_read_queue_length,"PhysicalDisk(_Total)Avg. Disk Read Queue Length",60

# Disk 磁盘平均读队列长度
PerfCounter=disk_write_queue_length,"PhysicalDisk(_Total)Avg. Disk Write Queue Length",60

4.5.2 配置图形

Disk 磁盘读写用时百分比：选择

Windows 系统监控 模板 : Disk 磁盘读用时百分比

Windows 系统监控 模板 : Disk 磁盘写用时百分比

Windows 系统监控 模板 : Disk 磁盘读和写总共用时百分比

调整线条以及颜色

4.5.3 监控结果

4.6 windows 磁盘容量监控

Zabbix 自带监控模板，在自动发现规则 Mounted filesystem discovery 已经配置。可用来来监控 CDEF 等分区容量。可以改成中文易读。如下图：

4.7 windows 网卡流量监控

Zabbix 自带监控模板，在自动发现规则 Network interface discovery 已经配置。

需要过滤掉不需要监控的端口，只显示真实的网卡流量，在 zabbix 界面，管理 - 一般 - 正则表达式中找到 Network interfaces for discovery 项，添加过滤规则。例如：

4.8 windows 系统时间监控

需要创建两个监控项，一个是绝对时间用于触发器告警，另一个是易读时间显示。通过获取到被监控系统时间与 zabbix server 做时差比较，超过 10 分钟告警。

4.8.1 创建监控项

键值：system.localtime[local] 易读时间

键值：system.localtime[] 绝对时间

4.8.2 创建触发器

名称：与 zabbix 主机时差超过 10 分钟：{HOST.NAME}

表达式：{Windows Server Model:system.localtime[].fuzzytime(600)}=0

4.9 windows 系统进程监控

Windows 的进程或程序监控，是通过监控进程数量，以此为状态标志位来判断进程是否已停止运行。

当最新进程数为 0 时，判断进程已停止运行；当 5 分钟内，平均值大于等于 1 时，恢复触发器，判断进程已恢复运行；当最新进程数不为 0 时，判断进程正在运行。

下面以监控 Xshell.exe 程序，运行进程为例，来创建实施监控。

4.9.1 创建监控项

键值：proc.num[Xshell.exe]

Zabbix 官网样例 proc.num[,,,,]

信息类型：数字（无正负） 方便看图形，标志位

更新间隔：1m 1 分钟同一规定

注：windows 下 只支持进程名和用户名称

4.9.2 创建触发器

名称：Xshell 程序已停止运行：{HOST.NAME}

问题表现形式：{Windows Server Model:proc.num[Xshell.exe].last()}=0

恢复表达式：{Windows Server Model:proc.num[Xshell.exe].avg(5m)}>1 or {Windows Server Model:proc.num[Xshell.exe].avg(5m)}=1

5 windows 系统硬件信息获取

本文通过在 OS 操作系统层面上，主要获取 windows 服务器下 CPU 信息、内存信息、硬盘信息、操作系统、服务器信息。信息获取的实现方式是通过在 windows 系统下部署自定义 bat 脚本，执行脚本获取数据，再将获取的信息发送给 zabbix 服务端， zabbix 界面创建相应的监控项，触发器等，最终将信息展示出来。监控项内容如下：

CPU 信息：型号、个数、内核数、逻辑核、 CPU 健康状态，及状态告警。

内存信息：容量、个数、厂商、型号、序列号；主板支持内存最大容量和个数。

硬盘信息：厂商、个数、容量、序列号、接口类型、硬盘健康状态，及状态告警。

操作系统信息：主机名、操作系统版本、运行时长、统线程数、系统时间。

服务器信息：品牌、型号、序列号。

说明：一些特殊数据需要实现监控，例如 CPU 温度、硬盘状态、 Raid 卡状态、风扇转速等， windows 没有提供检测硬件温度组件，需要借助第三方工具如 IPMI tools ， fan-speed 等，也可以使用 IPMI 协议等其他方法来丰富 windows 系统硬件监控项，对于虚拟机并不适用，此时，推荐使用服务器的管理口，如 HPE 服务器的 iLO 、 DEll 服务器的 iDRAC ，联想服务器 XCC 等开启 snmp 功能，再进行 zabbix 配置，实现对服务器硬件全面监控。如果服务器未配置管理口，当然不能适用。

5.1 CPU 信息获取

应用集：CPU 硬件

cpu 信息主要有：CPU 型号、 CPU 颗数、 CPU 核数、 CPU 逻辑核与线程（超线程，一般是核心数的 2 倍）

监控项配置：

5.1.1 CPU 型号

需要编写程序对 CPU 型号进行提取，相关配置如下：

1 、在 C:zabbixconfzabbix_agentd.win.conf 文件中：自定义程序开关设置为开启， UnsafeUserParameters=1 并添加监控项：

# CPU 型号
UserParameter=cpu_hardware_model,C:zabbixscriptcpu_hardware_model.bat

Zabbix 界面添加监控项：

监控 key 值：

cpu_hardware_model

2、程序目录为 

C:zabbixscriptcpu_hardware_model.bat

3 、监控项配置：

5.1.2 CPU 颗数

需要编写程序对 CPU 型号进行提取，相关配置如下：

1 、在 C:zabbixconfzabbix_agentd.win.conf 文件中：自定义程序开关设置为开启， UnsafeUserParameters=1 并添加监控项：

# CPU 型号
UserParameter=cpu_hardware_number,C:zabbixscriptcpu_hardware_number.bat

2 、程序目录为：

C:zabbixscriptcpu_hardware_number.bat

3 、监控项配置：

5.1.3 CPU 核数

需要编写程序对 CPU 核数进行提取，相关配置如下：

1 、在 C:zabbixconfzabbix_agentd.win.conf 文件中：自定义程序开关设置为开启， UnsafeUserParameters=1 并添加监控项：

# CPU 核数 一颗 CPU 的核心数
UserParameter=cpu_hardware_core,C:zabbixscriptcpu_hardware_core.bat

2 、程序目录为：

C:zabbixscriptcpu_hardware_core.bat

3 、监控项配置：

5.1.4 CPU 逻辑核与线程

使用 zabbix 自带 key ，监控 key 值：system.cpu.num[]

说明：type 可用值， online ( 默认值 ), max 范例 : system.cpu.num

经实践检查此处的 key 值为逻辑核心， CPU 逻辑核心、线程（超线程，一般是核心数的 2 倍） windows 系统下管理处理器，看到的数量。

监控项配置：

5.1.5 监控结果

5.2 内存信息获取

memery 内存信息：包括序号、制造商、容量、序列号、型号、速率

memery 内存主板支持：最大容量 , 最大槽位数

5.2.1 创建监控项

创建：memery 内存信息、 memery 内存主板支持

键值：memory_biso_support_info 、 memory_hardware_info

应用集：Memory 内存硬件

5.2.2 监控结果

1 、监测中 > 最新数据 >Memory 内存硬件 >memery 内存信息

可以看到，序列依次为：内存序号、容量、制造商、型号、序列号、速率。

2、监测中 > 最新数据 >Memory 内存硬件 >memery 内存主板支持

第一列为主板支持最大容量，第二列为主板支持最大槽位数。

5.3 操作系统信息

OS 操作系统信息：主机名、操作系统版本、运行时长、统线程数、系统时间。

其中操作系统版本是自定义程序获取，主机名、运行时长、统线程数、系统时间是 zabbix 自带监控模板，自带模板直接套用。

5.3.1 创建监控项

创建：系统时间、操作系统版本、绝对秒、系统线程数、系统运行时长、主机名

键值：system.localtime[local] 、 os_version 、 system.localtime[] 、 perf_counter[2250] 、 system.uptime 、 system.hostname[]

应用集：OS 操作系统

5.3.2 监控结果

监测中 > 最新数据 >OS 操作系统

5.4 服务器信息

监控服务器信息：品牌、型号、序列号。

5.4.1 创建监控项

创建：OS 服务器序列号、 OS 服务器型号、 OS 服务器品牌

键值：os_device_serialnumber 、 os_device_mode 、 os_device_manufacturer

应用集：OS 服务器信息

5.4.2 监控结果

监测中 > 最新数据 >OS 服务器信息

6 Linux 系统状态监控

Linux 系统监控，监控项原则上能利用 zabbix 提供模板就尽量使用， zabbix 提供不了的就编写 shell 脚本，这样就省去大部分代码编写时间，减少工作量。状态信息原则上已使用率为主要观察点，不需要再监控剩余率， Linux 系统监控模板，与 window 系统监控应用集、监控项命名保持统一，监控模板如下所示：

应用集：CPU 状态、 CPU 硬件、 Disk 硬盘、 Disk 磁盘状态、 Memory 内存状态、 Memory 内存硬件、 OS 操作系统、 OS 服务器信息、 agent 模板链接。

6.1 Linux 部署 zabbix_agent

说明：为了支持批量安装，一键化安装 linux 5 、 6 、 7 不同版本安装，需要有脚本程序支撑，自己编写的一建安装脚本，易于批量部署，至于 zabbix agent 安装配置也很简单，网上搜索很多，这里就给读者讲一些我的实践过程。

zabbix_agent_linux_install 脚本目录，上传至被监控 linux 主机，执行 sh install.sh IP

IP 为 zabbix 服务 IP ，当前环境为 192.168.9.123 ，该脚本一键化安装，无需配置 /etc/zabbix/ 下配置，自动识别 linux 版本，脚本内安装选项可以调整。

安装完毕后， zabbix 界面添加主机，并关联模板。当然可以配置 IP 范围使用自动发现主机。

6.2 Linux 系统 CPU 监控

应用集：CPU 状态
CPU 状态：CPU 使用率、 CPU 负载 1 分钟、 5 分钟、 15 分钟。
linux 系统 CPU 状态监控，官方已提供监控项，可以直接使用，无需自行编写脚本。具体参考官方链接：https://www.zabbix.com/documentation/3.4/zh/manual/appendix/items/supported_by_platform?s[]=system&s[]=hw&s[]=cpu&s[]=info ，支持 linux 与 windows 系统。

监控项配置：

注意：实际环境采用 user 系统使用率代替 cpu 整体使用率，因 linux 系统占用的 cpu 资源比较少 1% 。此处 cpu load 负载监控的值为 top 命令下看到的数值。

6.3 Linux 系统内存监控

应用集：Memory 内存状态

Memory 内存状态主要监控项有：Memory 内存使用率、 Memory 内存使用量、 Memory 内存总量（带上 Memory 方便了排序归类）。Swap 交换分区使用率、 Swap 交换分区使用量、 Swap 交换分区总量。

注意：此处的内存使用率为真实使用，会计算上缓存里占用的内存空间。不使用 zabbix 系统提供的 vm.memory.size[pused] （会将缓存计算进去），而使用通过 shell 脚本计算的真实内存。

监控项配置：

说明：配置与 windows 下内存监控方法一样不在详述。

1 、提供计算真实内存脚本 /etc/zabbix/script/memory_fact_used.sh ：

2 、在 /etc/zabbix/zabbix_agentd.d/ 目录下创建规范文件名 .conf 结尾，添加如下内容:

UserParameter=mem.fact.used, /etc/zabbix/script/memory_fact_used.sh

3 、监控项配置：

6.4 Linux 磁盘使用监控

应用集：Disk 磁盘使用

Linux 磁盘使用监控主要信息是：磁盘目录的使用情况，包括容量与索引。

监控方式：采用 zabbix 自动发现，将信息批量获取。

监控项配置：

监控项原型配置：

6.5 Linux 磁盘读写监控

应用集：Disk 磁盘读写

Disk 磁盘读写主要监控的信息有：读写速率、 IO 使用率、 IO 响应时间等

1、采用 zabbix 自发现，编写代码生成含有 sda 磁盘信息的 json 文件

Shell 代码：discovery_disk.sh

或 Python 代码：discovery_disk.py

2、编写代码获取 IO 信息：iocheck.sh ，脚本使用了 iostat 命令进行数据获取，关于 iostat 获取的数据信息解释，可翻阅资查看。主要对读写速率、 IO 使用率、 IO 响应时间关键指标进行监控。

3 、创建自发现规则

4 、创建监控项原型，如下图所示，在 zabbix 界面的最新数据可查看监控信息。

6.5 Linux 网卡状态监控

使用 zabbix 已有自发现规则进行监控，方法比较简单，配置截图如下：

1 、自发现规则配置

2 、过滤器配置 此项是为了过滤不需要监控的网卡，采用正则匹配

3 、监控项原型配置

7 Linux 系统硬件信息获取

这里 linux 硬件信息获取，类比 windows 硬件信息获取，都是在 OS 操作系统层面，如果想监控更多硬件，推荐使用服务器的管理口。

实践过程中，原则是尽可能使用 zabbix 系统已有监控项，直接使用效率高。

7.1 CPU 信息获取

应用集：CPU 硬件

cpu 信息主要有：CPU 型号、 CPU 颗数、 CPU 核数、 CPU 逻辑核与线程（超线程，一般是核心数的 2 倍）

监控项配置：

7.1.1 CPU 型号

使用 zabbix 自带 key ：

监控 key 值：
system.hw.cpu[,]

说明：cpu 为数量或是默认 all ， info ：full ( 默认 ), curfreq, maxfreq, model 或者 vendor 。

监控项配置：

7.1.2 CPU 颗数

此处的 CPU 颗数指的是物理个数，如果是虚拟机则不具备参考依据。

使用编写的命令获取 CPU 物理个数：

监控 key 值：
UserParameter=server.cpu.num,cat /proc/cpuinfo |grep -E 'physical[ t]+id' |sort |uniq |wc -l

监控项配置：

7.1.3 CPU 核数

使用编写的命令获取 CPU 核数，此处的核数为单个 CPU 的核心数，总核数为：CPU 颗数 * 单个 CPU 的核数。

在 /etc/zabbix/zabbix_agentd.d/ 目录下创建规范文件名 .conf 结尾，添加如下内容：

UserParameter=server.cpu.corenum,echo "$(cat /proc/cpuinfo |grep -E 'cpu[ t]+cores' |sort |uniq |awk '{print $NF}')"

监控项配置：

7.1.4 CPU 逻辑核与线程

使用 zabbix 自带 key ：

监控 key 值：

system.cpu.num[]

说明：type 可用值， online ( 默认值 ), max 范例 : system.cpu.num

经实践检查此处的 key 值为逻辑核心， CPU 逻辑核心、线程（超线程，一般是核心数的 2 倍） Linux 系统下 top 命令输入 1 ，看到的 cpu 数量。

监控项配置：

7.1.5 监控结果

7.2 Memory 内存信息获取

应用集：Memory 内存硬件

Memory 内存硬件信息主要有：主板支持情况、每个内存条硬件信息。

监控项配置：

7.2.1 Memory 内存主板支持

编写的命令获取内存主板支持情况：

在 /etc/zabbix/zabbix_agentd.d/ 目录下创建规范文件名 .conf 结尾，添加如下内容：

UserParameter=server.memory.info,dmidecode -t 16 | grep -E 'Maximum|Devices'|sed -e 's/^[ t]//g;s/[ t]$//g;s/[t]//g;s/Maximum Capacity/ 支持容量 /g;s/Number Of Devices/ 支持槽位 /g'

监控项配置：

最新数据：

7.2.2 Memory 内存信息

编写的命令获取每个内存条硬件信息：

在 /etc/zabbix/zabbix_agentd.d/ 目录下创建规范文件名 .conf 结尾，添加如下内容：

UserParameter=server.memory.info.num,dmidecode -t 17|grep -E "Size: [0-9]" -A12 |grep -E 'Locator:|Size:|Manufacturer:|Part Number|Speed:|Type:' |sed -e 's/^[ t]//g;s/[ t]$//g;s/[t]//g;s/Size/ 容量 /g;s/Locator/ 槽位 /g;s/Type/ 类型 /g;s/Speed/ 速率 /g;s/Manufacturer/ 制造商 /g;s/Part Number/ 序列号 /g'|grep -v 'Bank'|awk '{if (NR%6==0){print $0} else {printf"%st",$0}}'

监控项配置：

最新数据：

7.3 Disk 硬盘信息获取

因有的服务器安装了 RAID 卡或是连接了 EMC 等 SAN 存储设备，而且企业里大量使用了虚拟机 , 增加了硬盘信息获取的难度。对于 linux 与 windows 系统服务器获取硬盘信息，将在后续文章中详细介绍，下面介绍的方法，最适用于服务器安装 linux 系统的场景，可简单了解。

应用集：Disk 硬盘

Disk 硬盘主要获取两类信息 : 硬盘的硬件信息、硬盘的状态（包括只读）：

1 、直通硬盘

直通硬盘使用 hdparm -i /dev/sda 命令获取硬盘信息

直通硬盘使用 smartctl -H /dev/sda 命令获取硬盘健康状态

编写脚本，读写 /dev/sdX 硬盘，获取硬盘读写检查

2 、 RAID 硬盘

需要安装 MegaCli 等软件，使用软件命令来实现

监控结果：

7.4 OS 操作系统信息获取

应用集：OS 操作系统

OS 操作系统信息主要有：主机名、操作系统版本、登录用户数量、系统时间、系统运行时长。除过操作系统版本需要编写脚本外，其他都是 zabbix 系统已有监控项，可以直接使用。

监控项配置：

监控结果：

7.5 OS 服务器信息获取

应用集：OS 服务器信息

OS 服务器信息主要有：服务器品牌、型号、序列号。

注意：如果是虚拟机则反应的是虚拟化平台的厂家。如：VMware, Inc.

监控项配置：

脚本命令：

在 /etc/zabbix/zabbix_agentd.d/ 目录下创建规范文件名 .conf 结尾，添加如下内容：

UserParameter=server.company,dmidecode -s system-manufacturer |grep -v ^#
UserParameter=server.product.name,dmidecode -s system-product-name |grep -v ^#
UserParameter=server.serial.number,dmidecode -s system-serial-number |grep -v ^#|tr -d " "

监控结果：

8 Vmware 虚拟平台监控

阅读 zabbix 官方文档，官方提供了 Vmware 虚拟机监控模板，并对模板进行了解释说明，但未对相应名词做解释，如果不了解 Vmware 组件，可能对出现的名词不容易理解。

官方监控虚拟机相关文档 URL ：

https://www.zabbix.com/documentation/3.4/zh/manual/vm_monitoring

https://www.zabbix.com/documentation/3.4/zh/manual/config/items/itemtypes/simple_checks/vmware_keys

重要信息说明：

VMware vCenter ：VMware 平台用于管理的服务端，管理群集、主机、虚拟机、存储等。

VMware hypervisors ：主机，安装了 ESXI 软件的服务器。

Template VM VMware“ 模板应用于 VMware vCenter 和 VMware hypervisors 监控。

Template VM VMware Hypervisor 和 Template VM VMware Guest 模板由自动发现使用，通常设置为自动链接到主机。

low-level discovery 规则自动发现 VMware hypervisors 和虚拟机， LDD 就是自动发现。

采用官方提供的监控模板流程是这样实现的，首先建立监控主机，可以监控的对象是 VMware vCenter 虚拟化平台或者是 ESXI 主机，链接 Template VM VMware 模板，等待 zabbix server 服务自动发现，而后对群集、主机、虚拟机等进行监控。

有一节单讲组配置，制定 VMware 下群集、主机、虚拟机、存储等命名规范。

8.1 自发现模板配置

主要通过创建主机 VMware vCenter 和 ESXI ，连接 Template VM VMware 模板，进行自发现获取群集、主机、虚拟机、存储等信息。

8.1.1 创建主机

此处创建主机为 Vmware Vcenter 平台，配置如下：

端口 默认使用：80

主机组 命名为：Vmware 平台 Center 数据中心组

宏配置：

{$PASSWORD} 密码

{$USERNAME} 账号

模板：Template VM VMware （ zabbix 自带模板）

8.1.2 数据验证

在配置 -- 主机中查看是否已有虚拟机自生成，在最新数据 -- 查看是否有最新数据，这样就实现了 Vmware 平台上的数据监控，但平台分组不易读，还要制定分组命名规范。

8.2 制定分组命名规范

为了使 zabbix 平台 Vmware 分组分类整洁明了，方便管理审阅，规范 zabbix 下虚拟化平台分组名称。

1. 首先宏观分 3 大类， Vmware 平台、 ESXI 主机和 WM 虚拟机

Zabbix 创建主机组的命名规范：用于添加 Vmware Vcenter 的组

项目	类别	规范
Vmware Vcenter	平台组	Vmware平台 Center 数据中心组
Vmware ESXI	平台组	Vmware平台 Center 数据中心组

注：

如果确实存在 Vmware ESXI 未加入到 Vmware Vcenter 中，视 ESXI 为一个平台。如果 Vmware ESXI 已经加入到 Vmware Vcenter 中，就不要单独监控了，只监控 Vmware Vcenter 即可。

Zabbix 创建主机组的命名规范：用于自动发现 ESXI 主机时，添加所有 ESXI 主机

项目	类别	规范
Vmware ESXI	主机组	Vmware 平台ESXI主机组

Zabbix 创建主机组的命名规范： 用于自动发现 WM 虚拟机时，添加所有 WM 虚拟机

项目	类别	规范
VmwareVM	虚拟机组	Vmware 平台VM虚拟机组

2. 细分在某一 Vmware Vcenter 下进行分组， WM 虚拟机组有：数据中心（ Vmware Vcenter ）、群集与主机。

项目	类别	规范
Vmware Vcenter	虚拟机组	Vmware 虚拟机组 数据中心 Datecenter：
Vmware Cluster	虚拟机组	Vmware 虚拟机组 群集 Cluster：
Vmware ESXI	虚拟机组	Vmware 虚拟机组 主机 ESXI：

3. 细分在某一 Vmware Vcenter 下进行分组， ESXI 主机组有：数据中心（ Vmware Vcenter ）与群集。

项目	类别	规范
Vmware Vcenter	虚拟机组	Vmware 主机组 数据中心 Datecenter：
Vmware Cluster	虚拟机组	Vmware 主机组 群集 Cluster：

为了使 Vmware Vcenter 数据中心，虚拟机方便管理审阅，规范 Vmware 下虚拟化平台分组名称。

命名规范：

项目	规范	范例
数据中心 DadaCenter	描述功能用途	数据中心
群集 CLUSTER	描述功能用途	XXX平台
主机 ESXI		192.168.1.1
虚拟机VM	系统-版本-功能描述-IP	linux-redhat-6.7-zabbix测试-192.168.1.2

8.3 规范模板中组的命名

Template VM VMware 模板修改，需要修改 Vmware 自动发现主机与自动发现虚拟机的主机模板。

8.3.1 Vmware 自动发现主机

根据 8.2 节， zabbix 命名规范，修改组模板的两项：

1 、 Wmare 主机组 群集 Cluster ：{#CLUSTER.NAME}

2 、 Wmare 主机组 数据中心 DateCenter ：{#DATACENTER.NAME}

说明：1 是群集组分组， 2 是数据中心分组，此组下均为 ESXI 主机信息

要先创建 zabbix 主机组：Vmware 平台 Center 数据中心组，才能在此处的 “ 群组 ” 中添加。

说明：包括所有 ESXI 主机，跨数据中心。

8.3.2 Vmware 自动发现虚拟机

根据 8.2 节， zabbix 命名规范，修改组模板的三项：

1 、 Vmware 虚拟机组 群集 Cluster ：{#CLUSTER.NAME}

2 、 Vmware 虚拟机组 数据中心 Datecenter ：{#DATACENTER.NAME}

3 、 Vmware 虚拟机组 主机 ESXI ：{#HV.NAME}

要先创建 zabbix 主机组：Vmware 平台 VM 虚拟机组，才能在此处的 “ 群组 ” 中添加。

说明：包括所有虚拟机，跨数据中心。

8.3.3 对模板进行汉化

Template VM VMware 、 Template VM VMware Hypervisor 、 Template VM VMware Guest

8.4 创建触发器

Zabbix 自带 Vmware 监控模板无触发器配置，需要自研配置触发器，且能配置触发器项较少，尽量依靠部署 agent 进行全面监控告警。简而言之，此触发器告警是宏观上的，为虚拟平台整体状态告警，不能详尽描述虚拟机某一指标。

但有几个关键性指标，在 OS 下体现不出来，需要在 VMware 平台上做监控：如 CPU ready time 、内存 ballon 、 swap 等，依次要判断 VM 运行情况。

8.4.1 ESXI 主机触发器

1 、VMware ESXI 主机运行状况

配置如下图：

2 、VMware 虚拟传感器运行状况

配置如下图：

3 、主机不通，获取不到数据

在主机是关机或网络不通状态下，那肯定获取不到某一监控项。可使用 5 分钟内获取不到数据判断为主机不通。

在主机是在开机状态下，已经死机， CPU 、内存某些监控项，数据是否恒为定值不确定，是停留某个值还是归为 0 ，要以此为参考依据建立触发器，目前死机状态值未获取到，此项触发器无法建立。只能提供思路。

名称：主机不通，获取不到数据：{HOST.NAME}

表达式：{Template VM VMware Hypervisor:vmware.hv.cpu.usage[{$URL},{HOST.HOST}].nodata(5m)}=1

4 、主机产生 balloon 内存

Balloon 产生会在某种程度上说明：内存资源不足。此情况发生在，需要 vm kernel 调度其他 VM 虚拟机上空闲的内存资源，给内存不足的 VM 虚拟机。

此具体问题需要分析，目前此量值无法在实践中确定，首先进行提升信息，再根据 VM 或是 ESXI 主机内存资源情况进行合理判断。

8.4.2 VM 虚拟机触发器

可配置触发器较少，对于虚拟机监控告警，只是辅助告警，尽量依靠部署 agent ，因此，重点关注 2 虚拟机电源关闭 触发器。

创建 磁盘使用率 触发器， C 、 D 、 E 等磁盘剩余空间不足 10% 告警。

说明：此处监控针对 windows 系统，创建该触发器必然与 agent 监控告警重复，建议关闭此处触发器。（也可以创建使用空间超过 90% ，依赖关系 99% 提升告警级别）

创建触发器：

名称：磁盘剩余空间不足 10% ：on {#FSNAME}

表达式：{Template VM VMware Guest:vmware.vm.vfs.fs.size[{$URL},{HOST.HOST},{#FSNAME},pfree].last()}<10

允许手动关闭

效果截图：

创建 虚拟机电源状态翻转的触发器，当关闭虚拟机时，提示信息 “ 虚拟机电源关闭 ” ，当虚拟机重新打开电源时，恢复表达式。因虚拟机电源开关可控，有可能存在误关机操作。虚拟机开启不做告警。

创建触发器：

名称：虚拟机电源关闭：{HOST.NAME}

问题表现形式：{Template VM VMware Guest:vmware.vm.powerstate[{$URL},{HOST.HOST}].abschange()}=1

恢复表达式：{Template VM VMware Guest:vmware.vm.powerstate[{$URL},{HOST.HOST}].last()}<>0

注意：表达式多种多样，但有的并不一定能实现。

1. 经研究，虚拟机触发器可告警项较少，构建出发器也是可行，但总会与 agent 监控重复，效果并不理想，以上只做参考。比如 C 、 D 盘使用率监控， CPU ，内存使用率，而且有时候虚拟机不安装 VMware tools 工具下监控不到 C 盘（如果是 linux 系统则是目录），因此，针对虚拟机电源有必要监控告警，其他项不再深入研究。

2. CPU ready time CPU 就绪时间

关键重要指标，如果此值大于 2000ms 或是 2s ，说明 CPU 性能不足，需要关注。可以通过 ssh 到 ESXI 主机上使用 esxtop 命令查看。此处实践配置成 10 个周期内的均值 3000ms 告警。

虚拟机设置 CPU 核心数，如果 ESXI 主机 CPU 核心数较少， VM 设置的过多，会造成 VM 虚拟机直接抢占 CPU 资源造成， CPU ready time 值偏高，所以说虚拟机 CPU 核心数设置的并不是越多越好，只要满足计算量即可。

3. 内存触发器

重要关键指标：共享内存大小、气球内存大小、交换内存大小、压缩内存大小。

内存资源严重性逐步提高。共享、气球内存是 VM 合理利用内存的方式，避免：交换内存、压缩内存的产生。

共享内存大小：

气球内存大小：

交换内存大小：

压缩内存大小：

8.4.3 Cluster 群集触发器

监控群集整体状态

表达式：{Template VM VMware:vmware.cluster.status[{$URL},{#CLUSTER.NAME}].last()}>1

名称：群集状态异常：{HOST.NAME}

9 邮件告警

主要介绍通过邮件实现告警，当然告警的方式还有短信（需要短信猫）、企业微信、钉钉等。

E-mail 邮件告警配置有两种方式：

1 、 zabbix-server 服务器开启 sendmail 或者 postfix 服务， linux 系统默认安装好了邮件发送工具 mail ，利用该服务直接将告警信息通过 E-mail 发送到运维工程师的电子邮箱。

2 、 zabbix-server 使用外部邮箱账户发送告警信息到运维工程师的电子邮箱，类似 outlook 、 foxmail 邮箱代理。

总结：经过对上述两种方式实践，第一种方式邮件容易被识别为垃圾邮件遭过滤，公司目前有企业邮箱，可以开通名为 [e-mail] 账号做为外部邮箱发送告警信息，考虑到移动平台应用支撑，运维人员使用有移动终端的邮箱，综上建议部署第二种外部邮箱的方式。

详细配置参考链接：

https://www.osyunwei.com/archives/8113.html

http://www.ttlsa.com/zabbix/zabbix-media-email/

https://www.cnblogs.com/nice1163/articles/11123423.html

9.1 第一种方式

9.1.1 zabbix linux 下配置

1 、开启服务 sendmail 与 postfix 只开一个、 DNS 服务，并加入开机启动。

2 、修改主机名

 
   
   
 

  
    
    
  
 
   
   
 
3 、mail 发邮件测试

报错，根据提示解决报错问题，

未报错，邮箱不能收到邮件可能被邮箱服务器屏蔽掉了， 139 邮箱收不到信息，

未报错，邮箱能收到邮件说明发送正常。

9.1.2 zabbix 界面配置

1 、设定发送 mail 途径

2 、设定收件人

3 、设定告警动作

配置》动作》创建动作》动作、操作、恢复操作、确认操作，根据情况来设定。

详细配置，见 9.3 节。

9.1.3 验证测试

9.2 第二种方式

9.2.1 zabbix linux 下配置

本例中使用发送告警邮件的账号为 [e-mail] ，移动 139 邮箱，邮箱开启短信功能，手机就可以收到告警短信，

1 、关闭 sendmail 和 postfix 服务，重启域名服务。

 
   
   
 

  
    
    
  
 
   
   
 
2 、配置 vim /etc/mail.rc 最后一行添加
 
   
   
 

  
    
    
  
 
   
   
 
配置说明：使用 139 外部邮箱服务器

set from 邮件从该邮件发出

set smtp-auth 使用这个邮箱账户发送告警信息，需要填写用户名密码。

3 、mail 发邮件测试

将 139 邮箱开启短信服务，可以将邮件以短信的发送发送至手机。

4 、配置脚本，该脚本新增了格式化输出的功能，提高了邮件的可读性。

9.2.2 zabbix 界面配置

1 、设定发送 mail 途径

管理》报警媒介类型》创建媒介类型，配置截图如下：

2 、设定收件人

3 、设定告警动作

配置》动作》创建动作》动作、操作、恢复操作、确认操作，根据情况来设定。

详细配置，见 9.3 节。

9.2.3 验证测试

9.3 告警动作详细配置

动作功能：将告警信息以什么样的方式，什么样的内容形式发送给运维人员知晓。

界面配置示意图：动作名称是：外部邮件方式。需要创建

9.3.1 操作

默认接收人：

【故障】服务器 :{HOSTNAME1} 发生 : {TRIGGER.NAME} 故障

默认信息如：

告警主机 :{HOSTNAME1}

告警时间 :{EVENT.DATE} {EVENT.TIME}

告警等级 :{TRIGGER.SEVERITY}

告警信息 : {TRIGGER.NAME}

告警项目 :{TRIGGER.KEY1}

问题详情 :{ITEM.NAME}

事件 ID:{EVENT.ID}

操作细节

1-1 触发一次告警

步骤持续时间默认 0 为 1 小时

仅送到 选择创建的脚本名称 send_mail_script

9.3.2 恢复操作

【恢复】 服务器 :{HOSTNAME1}: {TRIGGER.NAME} 已恢复！

告警主机 :{HOSTNAME1}

告警时间 :{EVENT.DATE} {EVENT.TIME}

告警等级 :{TRIGGER.SEVERITY}

告警信息 : {TRIGGER.NAME}

告警项目 :{TRIGGER.KEY1}

问题详情 :{ITEM.NAME}

事件 ID:{EVENT.ID}

9.3.3 告警级别

严重性规则设定，可将 “ 灾难 ” 、 “ 严重 ” 信息设置为邮件发送

设置位置：

界面右上角，点进去，报警媒介，编辑。

10 微信告警

微信告警是指企业微信告警，首先要注册一个企业微信，之后完成微信告警配置（可搜索参考网上文章）。

10.1 脚本

这里提供一个优化测试好的脚本模板，以供交流

10.2 消息配置

【故障】数据中心监控平台

告警主机：{HOST.NAME}

告警信息：{TRIGGER.NAME}

告警等级：{TRIGGER.SEVERITY}

告警日期：{EVENT.DATE}

告警时间：{EVENT.TIME}

事件 ID ：{EVENT.ID}

原题：基于 zabbix 系统监控系列

欢迎点击文末阅读原文到社区讨论交流，发表您的观点

觉得本文有用，请转发或点击“在看”，让更多同行看到

 资料/文章推荐：

• 
  

下载 twt 社区客户端 APP

或到应用商店搜索“twt”