來源：twt企業IT社群

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 硬體指標

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 版本支援情況如下表：

4.1 windows 部署 zabbix_agent

為了監控 window 系統，首先需要在該系統下部署 zabbix_agent 代理，用於收集該系統資訊。

自研程式包列表：

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 平臺，配置如下：

主機名稱：IP 地址

埠 預設使用：80

主機組 命名為：Vmware 平臺 Center 資料中心組

宏配置：

{$PASSWORD} 密碼

{$URL}  地址 /sdk

{$USERNAME} 賬號

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

8.1.2 資料驗證

在配置 -- 主機中檢視是否已有虛擬機器自生成，在最新資料 -- 檢視是否有最新資料，這樣就實現了 Vmware 平臺上的資料監控，但平臺分組不易讀，還要制定分組命名規範。

8.2 制定分組命名規範

為了使 zabbix 平臺 Vmware 分組分類整潔明瞭，方便管理審閱，規範 zabbix 下虛擬化平臺分組名稱。

1. 首先宏觀分 3 大類， Vmware 平臺、 ESXI 主機和 WM 虛擬機器

Zabbix 建立主機組的命名規範：用於新增 Vmware Vcenter 的組

注：

如果確實存在 Vmware ESXI 未加入到 Vmware Vcenter 中，視 ESXI 為一個平臺。如果 Vmware ESXI 已經加入到 Vmware Vcenter 中，就不要單獨監控了，只監控 Vmware Vcenter 即可。

Zabbix 建立主機組的命名規範：用於自動發現 ESXI 主機時，新增所有 ESXI 主機

2. 細分在某一 Vmware Vcenter 下進行分組， WM 虛擬機器組有：資料中心（ Vmware Vcenter ）、群集與主機。

3. 細分在某一 Vmware Vcenter 下進行分組， ESXI 主機組有：資料中心（ Vmware Vcenter ）與群集。

為了使 Vmware Vcenter 資料中心，虛擬機器方便管理審閱，規範 Vmware 下虛擬化平臺分組名稱。

命名規範：

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 郵箱代理。

總結：經過對上述兩種方式實踐，第一種方式郵件容易被識別為垃圾郵件遭過濾，公司目前有企業郵箱，可以開通名為 zabbix@XXXX.com 賬號做為外部郵箱傳送告警資訊，考慮到移動平臺應用支撐，運維人員使用有移動終端的郵箱，綜上建議部署第二種外部郵箱的方式。

詳細配置參考連結：

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 途徑

管理》報警媒介型別》 Email ，配置截圖如下：

說明：SMTP 伺服器就是 zabbix-server 伺服器，地址是 192.168.1.2 ， DY-zabbix 是 zabbix-server 伺服器的主機名， linux 下執行 hostname 命令檢視， 1.2.1 節已配置好了。為啥要這樣配置，因為 zabbix 要利用 linux 下的 sendmail 工具傳送郵件。

2 、設定收件人

介面右上角，點進去，報警媒介，新增收件人地址。

3 、設定告警動作

配置》動作》建立動作》動作、操作、恢復操作、確認操作，根據情況來設定。

詳細配置，見 9.3 節。

9.1.3 驗證測試

9.2 第二種方式

9.2.1 zabbix linux 下配置

本例中使用傳送告警郵件的賬號為 1833XXXX@139.com ，移動 139 郵箱，郵箱開啟簡訊功能，手機就可以收到告警簡訊，

1 、關閉 sendmail 和 postfix 服務，重啟域名服務。

2 、配置 vim /etc/mail.rc 最後一行新增配置說明：使用 139 外部郵箱伺服器

set from 郵件從該郵件發出

set smtp 配置郵件服務的 smtp 域名地址

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 系統監控系列；本文2021年1月首發於twt社群，最新技術引數請參考相關官網