基于Docker 环境下Zabbix 架构运维告警平台的建设及应用

张朝晖，陈兆军，邱艳

浙江省台州医院 （浙江 台州 317000）

近年来，随着社会对医疗服务需求的不断增加，医院规模随之相应扩大，各种设备不断增多。信息化管理在医院管理中发挥着举足轻重的作用。传统信息化管理中设备故障预警机制不完善，各品牌运维软件间兼容性较差，并且有license 限制和服务年限要求，软件个性化定制比较困难，未能很好地与医院实际工作结合并及时在事前、事中进行有效监控，往往在故障发生后也未能及时发现、处理，造成运维人员的工作经常处于被动“救火”状态[1-2]。因此，医院急需建立网络自动运维平台信息化系统，以减轻人工运维压力，进一步优化自动运维管理流程，不断提高工作的效率和规范性。而基于Docker 环境下Zabbix 架构运维平台，不但在事前、事中能够及时监控医疗信息化平台中网络流量、带宽等网络运行性能指标，而且当发现网络故障后能在数秒内实现报警功能，且具备个性化定制功能，可根据医院实际需求自定义监控模板，满足个性化需求。基于此，本研究简要介绍医院现有运维平台的情况及在使用过程中存在的弊端，并阐述基于Docker 环境下Zabbix 架构运维告警平台的构建及使用情况，现报道如下。

1 医院现有运维平台分析

浙江省台州医院是台州地区一家三级甲等综合性医院，建院已有119 年历史，由3 家综合性分院、1 家专科医院组成，医院目前有物理服务器100 余台，虚拟机服务器450 余台，网络交换机120 余台，安全设备6 套，各类数据库50 余套，操作系统400 余套等，业务系统涵盖诊疗业务系统、检验检查系统、数据分析系统、财务支付系统、应用办公系统等8 大类250 余个子系统，涉及网络包含院区内网络、院区间网络、无线网络、医保网络、银行支付网络等，网络交互频繁且信息系统关联复杂，任何一处网络信息出现故障，都将影响医院正常的诊疗业务。医院在近2 年内连续发生信息事件6 起，造成医院业务停机超过30 min，故障达2 起，主要原因均是未进行事前预警提醒，导致故障发现不及时，延误了隐患的最佳处理时间。为了解决上述问题，我院自2022 年6 月开始建立基于Docker环境下Zabbix架构运维告警平台。

2 基于Docker 环境下Zabbix 架构运维告警平台建设

Docker 是一套开源的基于轻量级虚拟化技术的应用容器引擎，采用c/s 结构的形式，可实现高效部署和扩展，资源利用率高，能够使开发者将应用以及依赖包发布到1 个或多个可移植的镜像环境中，也可以发布到任何流行的Linux 或Windows 操作系统的机器上，利于进行快捷交付和部署。Docker 容器采用的是沙箱机制，经操作系统层的虚拟化技术实现隔离，相互之间不会有任何接口，便于实现安全管理。Zabbix 是一款免费开源监控软件，主要由Zabbix server、Zabbix agent、Zabbix proxy 等组件构成，适用于IT 基础架构、服务、应用和云资源的监控，具有较好的兼容性，能够支持实时监控数万台服务器、虚拟机和网络设备[3]，通过Zabbix agent 或SNMP 等协议采集运行指标，监控CPU、内存、网络性能、温度、风扇状态、电源状态等软硬件参数，同时支持配置短信、邮件等灵活的告警机制，使运维人员能够快速定位故障、解决问题，确保信息设备安全稳定运行。

2.1 Zabbix 安装

首先，在CentOS7.6 操作系统上按照Docker 官方文档要求进行Docker 安装，鉴于网络问题，拉取Docker 镜像较缓慢[4]，可配置加速器，亦可使用阿里、网易等镜像站；其次，在/etc/docker/下新建daemon.json 文件，需注意的是，因在医院使用过程中Docker 安装后默认网段是172.16.0.0/16 地址，为避免网段冲突，需要在/etc/docker/daemon.jso 配置文件中添加如下内容：

修改完后启动Docker，使用命令“service status docker”判断进程状态，可正常启动后即可安装配置Zabbix-server、Zabbix-database、Zabbix-WEB 等Docker镜像，具体安装步骤可参考Docker官方文档。

2.2 Zabbix 配置

在已经安装好的Docker 环境系统上分别下载安装Zabbix 相关组件镜像，包括Zabbix-database、Zabbix-server、Zabbix-agent、Zabbix-proxy、Zabbix-WEB 及Zabbix-get、Zabbix-sender。Zabbix-database 为Zabbix 的数据库组件，Zabbix 收集到的数据均存储至数据库，配置相应的数据库、用户名、密码等。Zabbix-server 为监控端组件，属于服务器端组件，下载安装即可。Zabbix-agent 为被监控端组件，属于客户端组件，主要用于监控由agent 所支持的操作系统（简而言之，若需监控OS，则应在对应的OS 上安装agent 程序），若需监控其他设备，则需使用ICMP/IPMI/SNMP/JMX 协议来实现。Zabbix-proxy 为Zabbix 代理组件，是实现分布式监控的关键，proxy 端负责收集数据并保存在本地，server 端定时从proxy 将数据取回。Zabbix-WEB 为Zabbix 的WEB 端组件，能够提取Zabbix-database 中的数据并予以展示，同时，其还是Zabbix 的配置接口。Zabbix-get 为server 端向agent 端获取数据的组件。Zabbix-sender 为agent 端向server 端主动发送收集数据的组件。

2.3 Zabbix 监控模板管理

Zabbix 监控模板即一系列已定义的监控项+触发器（图1）的集合，例如Zabbix 定义了Linux OS 的监控模板，便可监控Linux 系统的CPU、内存&Swap、磁盘容量、网络接口状态及使用率等，Zabbix 官网也提供了多种常见模板供下载使用。由于Zabbix 官网模板内的监控项数量较多、难以梳理且各种模板水平参差不齐，建议用户根据监控的主机或产品自定义模板，可在新建模板中设置监控项、告警配置、触发器、应用集等。例如，对JAVA程序内存使用监控，可定义为80%或90%告警，灵活性较高。

图1 监控模板触发器定义

2.4 Zabbix 报警设置

Zabbix 内设置了很多监控项，可实现多种监控预警，当达到某个阈值时，就会触发报警，报警机制由触发器与动作共同构成[4-8]。触发器为1 个表达式或1 个条件（如用户数量超过30 等），若达到触发条件，则会产生1 个触发事件，随后执行1 个或多个动作，如发送1 条短信或1 封邮件，或重启某个应用服务。例如，若CPU 的使用率达到80%以上，则会触发报警动作，系统将自动发送1 封邮件至指定邮箱，相关人员可根据邮箱提示内容做出相应处理。在Zabbix 程序WEB 界面的报警媒介类型中配置邮件、短信类型，完善报警接收用户及用户群组设置即完成了报警设置。（1）邮件报警设置（图2）：在报警媒介类型配置中增加邮件，将“类型”设置为电子邮件（可自定义名称），在“SMTP服务器”框内填入医院内网邮箱服务器地址或域名即可，在“SMTP HELO”框内填入发送邮件域名，在“SMTP 电邮”框内填入发送邮件用户邮箱，最后，完成邮件登录“用户名称”及“密码”设置并点击添加。（2）短信报警设置（图3）：在报警媒介类型配置中增加短信，将“类型”设置为脚本（可自定义名称），脚本名称设置为Zabbix 服务器中定义的短信脚本文件名称，短信脚本需放置在Zabbix 服务器/usr/lib/zabbix/alertscripts/文件夹中，可通过/etc/zabbix/zabbix_server.conf 配置文件查找到AlertScriptsPath 路径，通过Python 脚本的方式对接医院内部WEBService 短信平台接口，具体根据单位实际情况采用SOAP、GET 或POST 方式对接，报警服务短信（示例见图4）在接口的作用下，实现报警功能。

图2 邮件报警设置

图3 短信报警设置

图4 报警短信

3 小结

截至2023 年2 月，基于Docker 环境下Zabbix架构运维告警平台已经在我院网络环境中使用8 个月，共监控主机124 套，已启用模板27 个，主要监控了Linux 主机、Windows 主机、网络交换机、JAVA 程序等，通过安装Zabbix-agent、配置SNMP、JMX 等标准通信协议，共收到38 条/次Zabbix 监控平台发送的告警消息，使相关故障得以及时有效处理。目前，我院医疗信息化平台整体运行稳定，运维管理和值班人员在故障发生前后能够及时、准确定位故障源，且将原平均排查时间由30 min 左右（人工逐步检查）缩短至5 s 内（Zabbix 监控平台发送的告警消息）。通过实际应用，我们发现，Zabbix 还可以进行深度开发，对接服务器、存储等设备IPMI 协议，从设备管理口抓取信息，以实现硬件层面告警消息提示，此外，还可以对接grafana 前置展示界面，将相关情况更直观地以图表形式展现。

综上所述，医院运维服务平台构建是一个不断吸取新技术、不断创新的过程，在此过程中不断提高故障反应速度和处理效率。