Zabbix Introduce

2025-05-11 zabbix 筆記 zabbix

Zabbix 核心元件解析

Zabbix 是一套功能強大的開源監控解決方案,其架構由多個核心元件緊密協作而成,以下將逐一介紹:

1. Zabbix 伺服器 (Zabbix Server) Zabbix 伺服器是整個監控系統的大腦與心臟。它肩負著接收所有監控數據的重任,無論這些數據是來自 Zabbix Agent 主動回報,還是 Zabbix Proxy 彙整轉發。伺服器會對收到的數據進行處理、分析,並根據預設的規則判斷是否觸發告警。同時,它也負責將歷史監控數據以及系統設定資訊持久化儲存到後端資料庫中,以供後續查詢與分析。

2. Zabbix 代理程式 (Zabbix Agent) Zabbix 代理程式是部署在每一台受監控主機或裝置上的輕量級軟體。它的主要職責是主動採集該主機的各種效能指標 (例如 CPU 使用率、記憶體用量、網路流量、磁碟空間) 和應用程式狀態等數據。採集完成後,代理程式會將數據傳送給 Zabbix 伺服器或指定的 Zabbix Proxy 進行後續處理。

目前 Zabbix Agent 主要有兩個版本:

  • Zabbix Agent (C 語言版):這是以 C 語言開發的傳統版本,具有極高的穩定性與跨平台特性,幾乎支援所有主流的作業系統。
  • Zabbix Agent 2 (Go 語言版):這是以 Go 語言重新打造的新一代代理程式。相較於 C 語言版本,Agent 2 的優勢包括:能更有效地管理 TCP 連線數量,進而降低系統資源消耗;支援更高的併發處理能力,提升數據採集效率;並且更容易進行功能擴充與插件開發。Agent 2 的目標是逐步取代傳統的 Zabbix Agent,目前已穩定支援 Linux 和 Windows 平台。

3. Zabbix 代理伺服器 (Zabbix Proxy) Zabbix Proxy 可視為 Zabbix 伺服器的「分身」或「區域數據收集中心」。在大型或分散式的監控環境中 (例如擁有多個分公司或 IDC 的企業),可以部署 Zabbix Proxy。它會代替 Zabbix 伺服器接收其管轄範圍內各個 Agent 回報的監控數據,進行初步的預處理和彙整,然後再將這些數據批次傳送給中央的 Zabbix 伺服器。 這種架構能顯著減輕 Zabbix 伺服器的處理壓力與網路負載,同時也能在中央伺服器與遠端監控點之間的網路不穩定時,提供數據緩衝,確保監控數據不遺失。Zabbix Proxy 本身也需要一個資料庫來暫存收集到的數據。

4. Zabbix 前端 (Web 介面) Zabbix 提供了一個功能完整且操作直觀的網頁介面 (Frontend)。管理者可以透過瀏覽器登入此介面,進行所有 Zabbix 相關的設定與管理任務,例如:

  • 新增、設定及管理受監控的主機與主機群組。
  • 定義及調整監控項目 (Items) 與觸發器 (Triggers)。
  • 查閱即時與歷史的監控數據圖表。
  • 設定告警通知的條件與方式 (Actions 與 Media Types)。
  • 管理使用者權限與系統參數等。

5. 資料庫 (Database) 資料庫是 Zabbix 運作不可或缺的基石,負責儲存兩大類重要資訊:

  • 設定資訊:包括所有主機配置、監控項目定義、觸發器規則、告警設定、使用者帳號、模板等等。
  • 監控數據:所有從 Agent 或 Proxy 收集到的歷史效能指標與狀態數據。 Zabbix 支援多種主流的資料庫系統,讓使用者可以根據自身環境與偏好進行選擇,常見的包括:MySQL (及其高效能分支如 Percona Server、MariaDB)、Oracle、PostgreSQL。對於 PostgreSQL,還可以搭配 TimescaleDB 擴充套件來進一步優化時間序列數據的儲存與查詢效能。SQLite 也被支援,但通常僅建議用於非常小型或測試性質的部署。

Zabbix 常用術語釋義

為了更好地理解與使用 Zabbix,以下是一些核心名詞的解釋:

  1. 主機 (Host) 您想要監控的任何網路裝置,例如實體伺服器、虛擬機、網路交換器、路由器、印表機,甚至是特定的應用程式服務。在 Zabbix 中,主機會透過其 IP 位址或網域名稱來識別。

  2. 主機群組 (Host Group) 主機的邏輯性集合,主要用於組織與管理。一個主機群組可以包含多個主機,也可以連結模板。主機群組的常見用途是在分配使用者權限時,方便地將特定主機的監控權限授予特定的使用者群組。

  3. 監控項目 (Item) 您希望從主機上收集的特定數據點或度量指標。例如:CPU 的負載、可用記憶體大小、特定網路埠的流量、硬碟剩餘空間、某個服務是否正在執行等。

  4. 觸發器 (Trigger) 一個邏輯表達式,用於定義監控項目數據的「問題」閾值。當 Zabbix 收集到的數據滿足觸發器中定義的條件時 (例如 CPU 使用率超過 90% 持續 5 分鐘),觸發器的狀態就會從「正常 (OK)」轉變為「問題 (Problem)」。當數據恢復到正常範圍,觸發器狀態也會隨之恢復。

  5. 事件 (Event) 系統中任何值得注意的單次發生情況。最常見的事件就是觸發器狀態的改變 (例如從 OK 變 Problem)。其他事件還包括:監控代理程式的自動註冊、主機被自動發現、使用者登入等。

  6. 問題 (Problem) 指一個當前正處於「問題 (Problem)」狀態的觸發器。這表示某個被監控的指標已經達到了預警或嚴重狀態,需要關注或處理。

  7. 動作 (Action) 針對特定事件 (尤其是觸發器狀態改變為「問題」時) 所預先定義的一系列自動化反應。一個動作通常包含「條件」(判斷何時執行此動作) 與「操作」(具體執行的任務,例如發送告警通知、執行遠端指令等)。

  8. 升級 (Escalation) 在「動作」內部定義的一套客製化、階段性的處理流程。例如,一個問題發生後,可以設定升級機制:首先通知初階工程師;若 15 分鐘內問題未解決,則自動升級通知給資深工程師或主管。升級可以包含多個步驟,每個步驟可以有不同的通知對象或執行的遠端命令。

  9. 媒介類型 (Media Type) / 媒介 (Media) 傳送告警通知的具體方式或管道。Zabbix 內建支援多種媒介類型,如電子郵件 (Email)、簡訊 (SMS)。同時,也支援透過腳本 (Script) 的方式與外部通知系統整合,例如 Slack、Microsoft Teams、LINE Notify、Telegram 等。

  10. 通知 (Notification) 透過預先設定好的「媒介類型」,將與特定事件 (通常是問題產生或解決) 相關的告警訊息發送給指定的使用者或使用者群組。

  11. 遠端命令 (Remote Command) 預先定義好的,在滿足特定條件的情況下 (通常由「動作」觸發),可以在受監控主機上自動執行的指令或腳本。例如,當偵測到某個關鍵服務停止時,可以自動執行重啟該服務的命令。

  12. 模板 (Template) 一組可以被套用至一個或多個主機的標準化監控設定實體集合。模板中可以包含預設的監控項目、觸發器、圖形、應用程式分類、低階自動發現 (LLD) 規則、Web 檢測場景等。使用模板的主要目的是大幅簡化對大量主機的監控部署與維護工作,並確保監控策略的一致性。模板可以直接連結到個別主機,或透過主機群組間接套用。

  13. 應用程式 (Application) 在主機或模板層級,對相關的監控項目進行邏輯上的分組歸類。例如,可以將所有與 CPU 相關的監控項目 (如 CPU 使用率、CPU 負載、CPU 中斷等) 歸類到名為「CPU」的應用程式下,方便檢視與管理。

  14. Web 檢測 (Web Scenario) 透過模擬使用者瀏覽行為,執行一個或多個 HTTP/HTTPS 請求,來檢查網站或 Web 應用程式的可用性、回應時間、下載速度以及特定頁面內容是否正確等。

  15. 前端 (Frontend) 即 Zabbix 提供的 Web 操作介面 (已於「Zabbix 核心元件解析」中詳述),讓使用者能透過瀏覽器方便地管理及檢視整個 Zabbix 監控系統。

  16. Zabbix API (應用程式介面) Zabbix 提供的一組豐富的應用程式介面,採用 JSON RPC 協定。開發者或系統整合商可以透過 Zabbix API,以程式化、自動化的方式進行 Zabbix 物件 (如主機、監控項目、圖形等) 的建立、讀取、更新、刪除等操作,或執行其他客製化的任務,例如與 CMDB 系統整合、自動化報表產生等。

  17. Zabbix 伺服器 (Zabbix Server) Zabbix 軟體中實現監控功能的核心程式 (已於「Zabbix 核心元件解析」中詳述)。

  18. Zabbix 代理程式 (Zabbix Agent) 部署在受監控目標主機上,能夠主動監控本機資源和應用程式狀態的程式 (已於「Zabbix 核心元件解析」中詳述,包含 C 語言版與 Go 語言開發的 Zabbix Agent 2)。

  19. 被動 (Passive) 與 主動 (Active) 檢查模式 Zabbix Agent 支援兩種數據收集模式,這兩種模式是由監控項目的類型 (Item Type) 來決定的:

    • 被動模式 (Passive Check):在此模式下,Zabbix 伺服器 (或 Zabbix Proxy) 會主動向 Zabbix Agent 發出數據請求 (輪詢)。Agent 收到請求後,才收集對應的數據並回傳結果。此模式下,監控項目類型通常設定為 ‘Zabbix agent’。
    • 主動模式 (Active Check):在此模式下,Zabbix Agent 會先主動向 Zabbix 伺服器請求一份它需要監控的項目清單。然後,Agent 會依照這份清單的指示,定期獨立地收集數據,並主動將新的數據值回報給 Zabbix 伺服器。主動模式能有效減輕 Zabbix 伺服器的輪詢負載,尤其適用於 Agent 位於防火牆後方或網路連線品質不穩定的環境。此模式下,監控項目類型設定為 ‘Zabbix agent (active)’。
  20. Zabbix 代理伺服器 (Zabbix Proxy) 一個協助 Zabbix 伺服器收集數據,並分攤其整體負載的程式 (已于「Zabbix 核心元件解析」中詳述)。Proxy 會在其本機快取收集到的數據,然後再批次傳送到它所屬的 Zabbix 伺服器。部署 Zabbix Proxy 需要為其配置一個獨立的資料庫,用於儲存 Proxy 本身的設定以及暫存的監控數據。

參考資料

Zabbix-基础系列(一)-zabbix简介及原理