医疗服务器 Zabbix 监控升级与告警优化

1. 立项背景和目标
原医疗服务器监控工具存在告警不及时的问题，无法满足医疗业务对服务器稳定运行的高要求。若服务器故障不能及时发现，可能导致医疗系统如 HIS（医院信息系统）、影像存储系统等出现异常，影响患者就医流程和医疗数据安全。因此，立项将 Zabbix 升级作为主监控工具，目标是实现对 10 余台医疗服务器的全面、及时且准确的监控，确保医疗业务系统稳定运行，提升故障预警能力，减少因服务器问题引发的业务中断。
2. 软件功能、核心功能模块的介绍
Zabbix 具备强大的监控功能，能够对服务器的各项指标进行实时采集与监控。核心功能模块方面，Zabbix Server 作为核心管理模块，负责接收、处理 Zabbix Agent 采集的监控数据，并进行存储（依托 MySQL 数据库）与告警触发等操作；Zabbix Web 端则是用户交互模块，提供直观的界面，方便管理人员查看服务器监控状态、配置监控项与告警规则等；自定义监控 Key 模块（通过 Shell 脚本实现），可针对医疗业务特色，如 HIS 服务运行状态、影像文件存储使用率等进行定制化监控，满足医疗场景的特殊监控需求；Zabbix Agent 模块部署在各医疗服务器上，负责采集服务器的基础指标（如 CPU、内存、磁盘等）以及自定义监控项数据，并上报给 Zabbix Server。
3. 业务流程、功能路径描述
业务流程起始于 Zabbix Agent 在各医疗服务器上采集数据，包括服务器基础指标和通过自定义 Shell 脚本 Key 采集的 HIS 服务、影像存储等医疗相关指标。采集到的数据通过网络传输至 Zabbix Server，Zabbix Server 对数据进行分析，并与预设的阈值进行对比。当数据超出阈值时，触发告警流程，通过指定的方式（如邮件、短信等）向相关人员发送告警信息。同时，Zabbix Web 端实时展示监控数据与告警状态，管理人员可通过 Web 端查看服务器运行情况、历史告警记录，并对监控配置进行调整。此外，借助 Ansible 批量部署 Zabbix Agent，简化了多台服务器 Agent 部署的操作流程，提升了部署效率。

1. 整体架构和设计思路，不同模块使用的技术栈
项目采用Zabbix Server-Agent 分布式监控架构，结合自动化与定制化技术栈实现。核心模块及技术栈如下：
控制层：部署 Zabbix Server（负责数据接收、处理与告警触发）和 Zabbix Web 端（提供可视化管理界面），采用MySQL存储监控历史数据与配置信息，保障数据持久化与可查询性；
采集层：在 10 + 台医疗服务器部署Zabbix Agent，采集 CPU、内存、磁盘等基础指标；通过Shell 脚本自定义监控 Key，覆盖 HIS 服务运行状态、影像文件存储使用率等医疗专属业务指标；
自动化层：使用Ansible编写 Playbook，实现 Zabbix Agent 的批量部署与配置，减少重复手动操作。
2. “我” 的负责模块和结果（尽可能量化）
我主要负责Zabbix 服务端部署、自定义监控开发、Agent 自动化部署三大模块：
Zabbix Server 与 Web 端部署：完成服务端安装、MySQL 数据库对接及 Web 界面权限配置，确保监控数据链路通畅；
自定义监控 Key 开发：编写 5 + 个 Shell 脚本（如 HIS 服务进程检测、影像存储磁盘使用率统计），为每个监控项设置多级阈值（如磁盘使用率 85% 预警、90% 严重告警）；
Ansible 批量部署 Agent：编写自动化 Playbook，覆盖 10 + 台异构医疗服务器（含 CentOS、Ubuntu 等系统），相比手动配置减少 60% 的时间成本。
结果层面，项目上线后预警准确率达 95%，累计提前识别并修复 8 处潜在故障（如 3 次磁盘即将写满、2 次 Tomcat 内存泄漏、3 次 HIS 服务异常重启），保障了医疗业务系统的 7×24 小时稳定运行。
3. “我” 遇到的难点、坑，和解决方案
难点 ：异构服务器 Agent 部署兼容性差
坑：不同医疗服务器的操作系统版本（CentOS 7/8、Ubuntu 20.04）、端口占用情况不一致，导致 Agent 默认配置无法通用（如部分服务器 50000 端口被医疗影像服务占用）。
解决方案：用 Ansible 的facts模块提前采集服务器环境信息，在 Playbook 中加入端口预检与自动适配逻辑（检测 50000 端口占用，若被占用则动态调整为 50001 - 50010 区间的可用端口），同时针对不同系统编写差异化的 Agent 安装与启动任务。