Zabbix 是什麼#
Zabbix 是一套企業級的全功能監控系統，自 2001 年問世至今已超過二十年。與 Prometheus 生態系「每個元件各司其職、自行組裝」的哲學不同，Zabbix 走的是 All-in-one 路線——資料收集、儲存、告警、視覺化全部內建在同一個平台中。
這意味著安裝完 Zabbix 之後，你立刻擁有一個完整的監控系統，不需要另外搭配 Grafana 看圖、搭配 Alertmanager 發告警。對於許多傳統企業 IT 團隊來說，這種「開箱即用」的特質正是 Zabbix 最大的吸引力。
核心概念#
Host#
Host 是 Zabbix 中最基本的被監控對象。
- 一個 Host 代表一台伺服器、一個網路設備、一個虛擬機，或任何你想監控的實體
- 每個 Host 上定義了多個 Item（監控項目），例如 CPU 使用率、記憶體用量、磁碟空間
- Host 可以透過 Zabbix Agent（安裝在目標機器上）、SNMP、IPMI、JMX 等多種方式收集資料
Zabbix 的 Host 概念比 Prometheus 的 Target 更豐富。Prometheus 的 Target 本質上只是一個可以被 Scrape 的端點；Zabbix 的 Host 則包含了完整的監控設定、告警規則、歷史資料的關聯。
Template#
Template 是 Zabbix 實現「設定一次、處處套用」的核心機制。
- 一個 Template 包含了一組預定義的 Item、Trigger（告警條件）、Graph（圖表）和 Dashboard
- 將 Template 關聯到 Host 上，該 Host 就自動繼承 Template 中所有的監控設定
- Zabbix 社群提供大量現成的 Template，涵蓋常見的作業系統、資料庫、網路設備、雲端服務
- Template 支援巢狀繼承：一個 Template 可以連結其他 Template，形成層次化的設定結構
Template 機制是 Zabbix 管理大量 Host 時的效率關鍵。當你需要監控 500 台 Linux 伺服器時，只需要維護一個 Template，而不是逐台設定。
Group#
Group 提供了對 Host 的邏輯分組能力。
- 一個 Host 可以屬於多個 Group（例如同時屬於「Production」和「Database Servers」）
- Group 是權限控制的基本單位：你可以授權某個團隊只能查看特定 Group 的資料
- Group 也用於批次操作和報表產出的篩選依據
Web Scenario#
Web Scenario 是 Zabbix 內建的合成監控（Synthetic Monitoring）功能。
- 模擬真實使用者的操作流程：訪問登入頁面 → 輸入帳密 → 檢查回應 → 登出
- 每個步驟可以檢查 HTTP 回應碼、回應時間、頁面內容
- 當任何步驟失敗或回應時間超標，觸發告警
Web Scenario 的價值在於「從使用者角度」驗證服務是否正常。即使所有的系統指標（CPU、記憶體、磁碟）都正常，使用者可能因為應用程式邏輯錯誤而無法登入。合成監控能捕捉到這類純指標監控遺漏的問題。
Zabbix vs Prometheus：兩種不同的世界觀#
這兩者之間不是「誰比較好」的問題，而是設計哲學和適用場景的根本差異。
| 面向 | Zabbix | Prometheus |
|---|---|---|
| 架構哲學 | All-in-one 單一平台 | 生態系組合（Prometheus + Grafana + Alertmanager + …） |
| 資料模型 | Host-centric（以機器為中心） | Metric-centric（以指標為中心，多維 Label） |
| 收集方式 | Agent-based 為主，也支援 SNMP、JMX 等 | Pull-based（HTTP Scrape）為主 |
| 服務發現 | 支援但非強項 | 原生深度整合 Kubernetes、Consul 等 |
| UI 與告警 | 內建完整功能 | 需搭配 Grafana 和 Alertmanager |
| 設定方式 | Web UI 為主 | 設定檔為主（Infrastructure as Code 友善） |
| 擴展性 | 垂直擴展為主（Proxy 做水平分散） | 水平擴展（搭配 Thanos/Mimir） |
資料模型的差異#
這是最根本的差異。Zabbix 的思維是「這台機器的 CPU 使用率是多少」——以 Host 為中心，每個指標歸屬於特定的機器。Prometheus 的思維是「cpu_usage 這個指標在 instance=A、job=web 的維度下是多少」——以指標為中心，透過 Label 切片分析。
在傳統的 IT 基礎設施中，Zabbix 的 Host-centric 模型非常直覺。但在微服務架構中，一個服務可能有幾十個動態的 Pod，Host 的概念變得模糊，Prometheus 的 Label 模型更能適應這種動態性。
適合 Zabbix 的場景#
- 傳統 IT 基礎設施監控：實體伺服器、網路交換器、儲存設備、VMware 虛擬化環境——這些是 Zabbix 的主場
- 需要開箱即用的企業環境：團隊沒有時間或能力組裝 Prometheus 生態系的各個元件，Zabbix 裝完就能用
- 混合雲環境：同時有地端機房和雲端資源，Zabbix 的 Agent 和 Proxy 架構可以跨越網路邊界收集資料
- 合規與稽核需求：Zabbix 內建完整的使用者權限管理和操作日誌，對於需要嚴格存取控制的組織很有價值
不適合 Zabbix 的場景#
- 雲原生微服務架構：Kubernetes 上動態擴縮的 Pod、Service Mesh 的指標、容器生命週期極短——Prometheus 的服務發現和 Label 模型在這個領域遠比 Zabbix 契合
- 需要 PromQL 級別的查詢靈活性：PromQL 的多維聚合和函數運算能力，是 Zabbix 查詢語言難以企及的
- 追求 GitOps / Infrastructure as Code：Zabbix 的設定主要透過 Web UI 操作，雖然有 API 但不如 Prometheus 的 YAML 設定檔那樣天然適合版本控制
不要因為 Zabbix「看起來舊」就否定它的價值。在傳統基礎設施監控的領域，Zabbix 經過二十年的錘鍊，穩定性和功能完整度是 Prometheus 生態系仍在追趕的。工具沒有新舊之分，只有適不適合。
從 Zabbix 遷移到 Prometheus 的思考#
許多組織在從傳統架構轉向雲原生時，會面臨「要不要從 Zabbix 遷移到 Prometheus」的問題。以下是幾個思考方向：
不一定要全部遷移#
最務實的策略往往是共存：
- 傳統基礎設施（實體伺服器、網路設備）繼續用 Zabbix 監控
- 新的雲原生服務（Kubernetes、微服務）用 Prometheus 監控
- 兩者的資料都匯入 Grafana 做統一的視覺化
遷移前要回答的問題#
- 監控對象的本質變了嗎？ 如果你的工作負載從固定的實體機器變成動態的容器，Prometheus 的模型更適合
- 團隊準備好了嗎？ Prometheus 生態系的學習曲線和營運複雜度比 Zabbix 高，團隊需要具備相應能力
- 現有的 Template 和告警規則怎麼辦？ 多年累積的 Zabbix Template 是有價值的資產，遷移意味著需要在 Prometheus 端重建這些規則
漸進式遷移路徑#
- 先在新服務上導入 Prometheus，不動既有的 Zabbix 設定
- 用 Grafana 同時連接兩個資料源，建立統一的 Dashboard
- 隨著團隊對 Prometheus 的熟悉度提升，逐步將適合的監控項目從 Zabbix 遷移過去
- 對於 Zabbix 更擅長的領域（SNMP 設備、傳統伺服器），可能永遠不需要遷移
遷移的目標不是「消滅 Zabbix」，而是「讓每個工具監控它最擅長的對象」。在許多混合環境中，Zabbix 和 Prometheus 長期共存是完全合理的架構決策。