基于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 前置展示界面，將相關情況更直觀地以圖表形式展現。

綜上所述，醫院運維服務平臺構建是一個不斷吸取新技術、不斷創新的過程，在此過程中不斷提高故障反應速度和處理效率。