概述

定義

Zabbix 官網地址 https://www.zabbix.com/

Zabbix 官網檔案 https://www.zabbix.com/documentation

Zabbix GitHub原始碼地址 https://github.com/zabbix

Zabbix 是一個企業級的開源分散式監控、高度整合的網路監控解決方案。最新版本為6.2.4，官方檔案支援很多種語言，最新中文檔案支援到6.0版本。

Zabbix 誕生於1998年，核心元件採用C語言開發，Web端採用PHP開發。屬於老牌監控系統中的優秀代表，監控功能很全面，使用也很廣泛。是一款具備監控網路的眾多引數，可以監控網路、物理伺服器、虛擬機器器、應用程式、服務、資料庫、網站、雲等。

監控作用

實時採集監控資料：包括硬體、作業系統、中介軟體、應用程式等各個維度的資料。
實時反饋監控狀態：通過對採集的資料進行多維度統計和視覺化展示，能實時體現監控物件的狀態是正常還是異常。
預知故障和告警：能夠提前預知故障風險，並及時發出告警資訊。
輔助定位故障：提供故障發生時的各項指標資料，輔助故障分析和定位。
輔助效能調優：為效能調優提供資料支援，比如慢SQL，介面響應時間等。
輔助容量規劃：為伺服器、中介軟體以及應用叢集的容量規劃提供資料支撐。
輔助自動化運維：為自動擴容或者根據設定的SLA進行服務降級等智慧運維提供資料支撐。

使用理解

瞭解監控物件的工作原理：要做到對監控物件有基本的瞭解，清楚它的工作原理。比如想對JVM進行監控，你必須清楚JVM的堆記憶體結構和垃圾回收機制。
確定監控物件的指標：清楚使用哪些指標來刻畫監控物件的狀態？比如想對某個介面進行監控，可以採用請求量、耗時、超時量、異常數等指標來衡量。
定義合理的報警閾值和等級：達到什麼閾值需要告警？對應的故障等級是多少？不需要處理的告警不是好告警，可見定義合理的閾值有多重要，否則只會降低運維效率或者讓監控系統失去它的作用。
建立完善的故障處理流程：收到故障告警後，一定要有相應的處理流程和oncall機制，讓故障及時被跟進處理。

監控物件和指標

運維關注硬體和基礎監控，研發關注各類中介軟體和應用層的監控，產品關注核心業務指標的監控。

硬體監控：電源狀態、CPU狀態、機器溫度、風扇狀態、物理磁碟、raid狀態、記憶體狀態、網路卡狀態。
伺服器基礎監控
- CPU：單個CPU以及整體的使用情況
- 記憶體：已用記憶體、可用記憶體
- 磁碟：磁碟使用率、磁碟讀寫的吞吐量
- 網路：出口流量、入口流量、TCP連線狀態
資料庫監控：資料庫連線數、QPS、TPS、並行處理的對談數、快取命中率、主從延時、鎖狀態、慢查詢。
中介軟體監控
- Nginx：活躍連線數、等待連線數、丟棄連線數、請求量、耗時、5XX錯誤率
- Tomcat：最大執行緒數、當前執行緒數、請求量、耗時、錯誤量、堆記憶體使用情況、GC次數和耗時
- 快取（Redis）：成功連線數、阻塞連線數、已使用記憶體、記憶體碎片率、請求量、耗時、快取命中率
- 訊息佇列(Kafka)：連線數、佇列數、生產速率、消費速率、訊息堆積量
應用監控
- HTTP介面：URL存活、請求量、耗時、異常數
- RPC介面：請求量、耗時、超時量、拒絕量
- JVM ：GC次數、GC耗時、各個記憶體區域的大小、當前執行緒數、死鎖執行緒數
- 執行緒池：活躍執行緒數、任務佇列大小、任務執行耗時、拒絕任務數
- 連線池：總連線數、活躍連線數
- 紀錄檔監控：存取紀錄檔、錯誤紀錄檔
- 業務指標：視業務來定，比如PV、訂單量等

架構組成

Zabbix server：核心元件， Zabbix 軟體的中央程序，執行監控、與 Zabbix proxy 和 agent 互動，負責接收Agent、Proxy的監控資料，也支援JMX、SNMP等多種協定直接採集資料；負責資料的彙總儲存以及告警觸發等。
資料庫：Zabbix 收集的所有設定資訊以及資料都儲存在資料庫中，支援MySQL、Oracle等關係型資料庫，逐步支援時序資料庫。
前端：Zabbix的Web的介面，提供基於 Web 視覺化監控設定、展現、告警。
Zabbix proxy：可以代替 Zabbix server 收集效能監控項資料，可選，對於被監控機器較多的情況下，可使用Proxy進行分散式監控以減輕Server的壓力。
Zabbix agent ：部署在被監控目標上，以主動監控本地資源和應用程式的程序（硬碟、記憶體、處理器統計資訊等），採集本機的資料並行送給Proxy或者Server，資料收集方式同時支援主動Push和被動Pull 兩種模式。從 Zabbix 4.4 開始，有兩種型別的 agent 可用：Zabbix agent（輕量級，在許多平臺上支援，用 C 編寫）和 Zabbix agent 2（非常靈活，易於使用外掛擴充套件，用 Go 編寫）。
- 被動模式：agent 應答資料請求。Zabbix server（或 proxy）詢求資料，例如 CPU load，然後 Zabbix agent 返還結果。
- 主動模式：處理過程將相對複雜，Agent 必須首先從 Zabbix sever 索取監控項列表以進行獨立處理，然後會定期傳送採集到的新值給 Zabbix server。
Zabbix API：使用 JSON RPC 協定來建立、更新和獲取 Zabbix 物件（如主機、監控項、圖表等）或執行任何其他自定義任務。
Zabbix Java gateway ：獲取主機的JMX 計數器的值，Zabbix server向Zabbix Java gateway傳送請求，使用 JMX 管理 API 來遠端查詢相關的應用。
Zabbix sender：用來推播效能資料給 Zabbix Server 處理的命令列應用程式；通常用在定期推播可用性和效能資料等在長耗時的使用者指令碼上。
Zabbix get ：命令列應用，它可以用於與 Zabbix agent 進行通訊，並從 Zabbix agent 那裡獲取所需的資訊；通常被用於 Zabbix agent 故障排錯。

常用監控軟體分析

前面我們學習過Prometheus，這裡結合Zabbix、Open-falcon做下簡單的優劣勢分析

Zabbix
- 優勢
  - 產品成熟：擁有豐富的檔案資料（包括中文檔案）以及各種開源的資料採集外掛，能覆蓋絕大部分監控場景。
  - 採集方式豐富：支援Agent、SNMP、JMX、SSH等多種採集方式，支援主動和被動的資料傳輸方式。
  - 較強的擴充套件性：支援Proxy分散式監控，有agent自動發現功能，外掛式架構支援使用者自定義資料採集指令碼。
  - 設定管理方便：能通過Web介面進行監控和告警設定，操作方便，上手簡單。
- 劣勢
  - 效能瓶頸：機器量或者業務量大了後，關係型資料庫的寫入一定是瓶頸。
  - 應用層監控支援有限：如果想對應用程式做侵入式的埋點和採集（比如監控執行緒池或者介面效能），zabbix沒有提供對應的sdk，需要通過外掛式的指令碼編寫實現較為麻煩。
  - 資料模型不強大：不支援tag，沒法按多維度進行聚合統計和告警設定，不靈活。
  - 方便二次開發難度大：Zabbix採用的是C語言，二次開發成本較高。
Open-falcon：是小米2015年開源的企業級監控工具，採用Go和Python語言開發，這是一款靈活、高效能且易擴充套件的新一代監控方案，目前小米、美團、滴滴等超過200家公司在使用。核心優勢在於資料分片功能，能支撐更多的機器和監控項。
- 優勢
  - 自動採集能力：無需做任何設定Falcon-agent 就能自動採集伺服器的200多個基礎指標（比如CPU、記憶體等）。
  - 強大的儲存能力：底層採用RRDTool，並且通過一致性hash進行資料分片，構建了一個分散式的時序資料儲存系統，可延伸性強。
  - 靈活的資料模型：借鑑OpenTSDB，資料模型中引入了tag，這樣能支援多維度的聚合統計以及告警規則設定，大大提高了使用效率。
  - 外掛統一管理：Open-Falcon的外掛機制實現了對使用者自定義指令碼的統一化管理，可通過HeartBeat Server分發給agent，減輕了使用者自主維護指令碼的成本。
  - 個性化監控支援：基於Proxy-gateway，很容易通過自主埋點實現應用層的監控（比如監控介面的存取量和耗時）和其他個性化監控需求，整合方便。
- 劣勢
  - 整體發展一般：社群活躍度不算高，版本更新慢，支援粒度較弱。
  - 安裝比較複雜：元件較多，如果對整個架構不熟悉，安裝很難一蹴而就。
Prometheus：有Google和k8s加持，是容器監控方面的標配和主流方案。
- 優勢
  - 輕量管理：架構簡單，不依賴外部儲存，單個伺服器節點可直接工作，二進位制檔案啟動即可，屬於輕量級的Server，便於遷移和維護。
  - 較強的處理能力：監控資料直接儲存在Prometheus Server原生的時序資料庫中，單個範例可以處理數百萬的metrics。
  - 靈活的資料模型：同Open-Falcon，引入了tag，屬於多維資料模型，聚合統計更方便。
  - 強大的查詢語句：PromQL允許在同一個查詢語句中，對多個metrics進行加法、連線和取分位值等操作。
  - 很好地支援雲環境：能自動發現容器，同時k8s和etcd等專案都提供了對Prometheus的原生支援，是目前容器監控最流行的方案。
- 劣勢
  - 功能不夠完善：Prometheus從一開始的架構設計就是要做到簡單，不提供叢集化方案，長期的持久化儲存和使用者管理，而這些是企業變大後所必須的特性，目前要做到這些只能在Prometheus之上進行擴充套件。
  - 網路規劃變複雜：由於Prometheus採用的是Pull模型拉取資料，意味著所有被監控的endpoint必須是可達的，需要合理規劃網路的安全設定。

版本選型

LTS穩定版本每一年半釋出一次，對於所有穩定版本，五年的服務與支援。目前Zabbix版本支援期限列表如下，建議企業選型使用時選擇LTS版本如6.0

Zabbix LTS 特點：

支援期限更長，例如：為潛在的安全問題及bug迭代更新
令人期待的高質量更新以及全新的功能點
快速更新，可適用於多變的複雜環境
在版本升級方面，更容易規劃管理

俗語

host（主機）：要通過 IP/DNS 監控的聯網裝置。
host group（主機組）：主機的邏輯分組；可能包含主機和模板。主機組中的主機和模板沒有以任何方式相互連結。在為不同使用者組分配主機存取許可權時使用主機組。
item（監控項）：你想要接收的主機的特定資料，一個度量/指標資料。
value preprocessing（值預處理）：在資料存入資料庫之前轉化/預處理接收到的指標資料。
trigger（觸發器）：一個被用於定義問題閾值和 "評估" 控項接收到的資料的邏輯表示式。當接收到的資料高於閾值時，觸發器從 'Ok' 變成 'Problem' 狀態。當接收到的資料低於閾值時，觸發器保留/返回 'Ok' 的狀態。
event（事件）：一次發生的需要注意的事情，例如觸發器狀態改變、自動發現/agent 自動註冊。
event tag（事件標籤）：預設的事件標記可以被用於事件關聯，許可權細化設定等。
event correlation（事件關聯）：一種靈活而精確地將問題與其解決方法聯絡起來的方法比如說，你可以定義觸發器A告警的異常可以由觸發器B解決，觸發器B可能採用完全不同的資料採集方式。
problem（問題）：一個處在 "問題" 狀態的觸發器。
problem update（問題更新）：Zabbix 提供的問題管理選項，例如新增評論、確認、更改嚴重性或手動關閉。
action（動作）：對事件作出反應的預先定義的方法。一個動作由多個操作（例如傳送通知)）和條件（什麼情況下執行操作）組成。
escalation（升級）：用於在動作中執行操作的自定義場景；傳送通知/執行遠端命令的序列。
media（媒體）：傳送告警通知的渠道；傳輸媒介。
notification（通知）：通過選定的媒體通道傳送給使用者的關於某個事件的訊息。
remote command（遠端命令）：在某些條件下在受監控主機上自動執行的預定義命令。
template（模板）：可以應用於一個或多個主機的一組實體集（包含監控項、觸發器、圖表、低階別自動發現規則、web場景等）。模版的應用使得主機上的監控任務部署快捷方便；也可以使監控任務的批次修改更加簡單。模版是直接關聯到每臺單獨的主機上。
web scenario（web 場景）：檢查一個網站的可用性的一個或多個HTTP請求。

安裝

部署方式

Zabbix支援多種安裝方式，可單項安裝也可以混合安裝，包括如下：

二進位制安裝；
原始碼安裝；
容器安裝；
Web介面安裝。

部署

# 下載docker專案
wget https://github.com/zabbix/zabbix-docker/archive/refs/tags/6.2.4.tar.gz
# 解壓
tar -xvf 6.2.4.tar.gz
# 進入目錄
cd zabbix-docker-6.2.4
# 通過docker-compose一鍵安裝啟動，由於本機埠衝突，修改zabbix-web-nginx-mysql的埠為180和1443
docker-compose -f docker-compose_v3_centos_mysql_latest.yaml up -d
# 檢視容器
docker-compose -f docker-compose_v3_centos_mysql_latest.yaml ps

存取Zabbix的Web頁面 http://192.168.50.95:180/，輸入使用者名稱 Admin 以及密碼 zabbix ，進入全域性檢視頁面。

設定為中文，通過使用者設定，選擇語言為中文，點選更新後就為中文版。

zabbix-agent

# 模擬啟動zabbix-agent1為Zabbix server的
docker run --name zabbix-agent1 -e ZBX_HOSTNAME="Zabbix server" --network zabbix-docker-624_zbx_net_backend -e ZBX_SERVER_HOST="zabbix-docker-624_zabbix-server_1"  -d zabbix/zabbix-agent:latest
# 進入zabbix-docker-624_zabbix-server_1的容器
docker exec -it zabbix-docker-624_zabbix-server_1 /bin/bash
# 執行測試命令，可以獲取到監控項的值
zabbix_get -s zabbix-agent1 -p 10050 -k "system.cpu.load[all,avg1]"