成熟企業級開源監控解決方案Zabbix6.2關鍵功能實戰-上
@
概述
定義
Zabbix 官網文檔 //www.zabbix.com/documentation
Zabbix GitHub源碼地址 //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 //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頁面 //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]"
在Zabbix的Web頁面中的配置-主機中，可以看到默認監控zabbix-server的主機資訊，修改zabbix-agent1的容器名稱
等待一小段時間後可用性列就變為綠色也即是可用狀態
在Zabbix的Web頁面中監測-主機，然後再列表中Zabbix server點擊最新數據，可以查到當前主機的監控項最新數據了，當然也可以直接點擊最新數據頁面輸入搜索條件查詢，至此完成了一個簡單入門示例。
**本人部落格網站 **IT小神 www.itxiaoshen.com
