一. 監控系統的功能概述
監控、從中文的字義來看,有兩個內容,一是檢測,二是控制。重點在第一個字眼,即檢測、預防的意思。
監控,對應的英文單詞是 Monitoring。在計算機領域,可以將其分為5種監控類型。
- 應用性能監控
- 業務交易監控
- 網絡性能監控
- 操作系統監控
- 網絡站點監控
上面5種類型將監控這個概念劃分成了多個領域。我們通常所說的監控,都會模糊的包含以上5個細分的領域。在任何一個 IT業務環境中,都會存在各種各樣的硬件設備、軟件應用等。
按照邏輯層次劃分,我們可以將我們可以將監控行為劃分為5個層次:基礎設施監控、系統層監控應用層監控、業務監控、端用戶體驗監控。
最底層基礎設施監控:這層一般由運維人員負責,涉及到的方面比較接近硬件體系,例如網絡,交換機,路由器等低層設備,這些設備的可靠性穩定性就直接影響到上層服務應用的穩定性,所以需要對網絡的流量,丟包情況、錯包情況,連接數等等這些基礎設施的核心指標進行監控。
系統層監控:這層涵蓋了物理機、虛擬機、操作系統等,這些都是屬于系統級別監控的方面,主要對幾個核心指標進行監控,如cpu 使用率、內存占用率,磁盤 I0 和網絡帶寬情況。
應用層監控:這層涉及到方面和服務緊密相關,例如對 url訪問的性能,訪問的調用數,訪問的延遲,還有對服務提供性能進行監控,服務的錯誤率等,同時對sql?也需要進行監控,查看是否有慢 sql。對于cache 來說,需要監控緩存的命中率和性能,每個服務的響應時間等等。
二. 監控系統的實現原理
1. 模塊組成
一個監控系統的組成大體可以分為兩部分:數據采集部分和數據存儲、分析告警、展示部分,這兩部分構成了監控系統的基本模型。
2. 采集協議
按照支持的協議方式,監控 IT數據采集可以分為兩種:專用客戶端采集和公用協議采集。
3. 監控模式
監控系統數據采集的工作模式可以分為被動模式和主動模式。被動模式指的是服務器端到客戶端采集數據;主動模式是客戶端主動上報數據到服務器。
一般來說被動模式對監控端服務器的開銷較大,適合小規模的監控環境:被動模式對監控端服務器的開銷較小,適合大規模的監控環境。
4. 理架構
對于大規模的監控環境,被監控節點比較多,并且監控類型也很多,監控產生的數據和網絡連接開銷非常大,數據采集方式除了使用主動模式之外,還需要使用代理的架構,通過代理架構分攤服務器端的性能開銷。另外,代理架構還支持跨地域、跨網絡的分布式監控。常見的代理架構為 C/S/P 架構,即 client/Proxy/Server。
三:監控系統的開源產品
1:zabbix
Zabbix是一款出色的企業級運維監控平臺,可用于監控從服務器、網絡設備到 web 應用程序和數據庫的性能和可用性的一切;它可以安裝在 Linux、AIX、Windows、Solaris、Macos x、FreeBsD、openBSD 等系統上使用,具有非常良好的適配能力
2:Prometheus+Grafana
Prometheus是一個開源系統監控和警報工具包,主要用于對基礎設施的監控,包括服務器(CPU、MEM等)、數據庫(MYSQL、PostgresQL 等)、web 服務等,幾乎所有東西都可以通過Prometheus 進行監控。
3:Cacti
Cacti 是一款網絡流量監測圖形分析工具,它連接到 RRDTo01,生成與網絡數據相關的圖表,具有非常強大的數據和用戶管理功能,可以指定每一個用戶能査看樹狀結構、host 以及任何一張圖,還可以與LDAP 結合進行用戶驗證,同時也能自己增加模板。
4:Nagios
Nagios 是一個監控系統運行狀態和網絡信息的監控系統,它可以監控所指定的本地或遠程主機以及服務,同時提供異常通知功能等;能夠監控幾乎所有類型的組件,如網絡協議、操作系統、系統指標、用程序、服務、web 服務器、網站、中間件等。
5:Checkmk
Checkmk 是一個高度可擴展的監控工具,可監控服務器、網絡、云資產、數據庫、容器、物聯網等。
它有兩種模式可用,基礎版完全開源并提供免費和無限制的監控,企業版附帶附加功能。
Checkmk 具有部署快、高度自動化、配置靈活的特點。
6:openNMS
OpenNMS 是一個企業級基于 Java/XML 的分布式網絡和系統監控管理平臺。它能夠顯示網絡中各中終端和服務器的狀態和配置,為管理網絡提供有效的信息。它專為 Linux 設計,但也支持 windows、Solaris 和 OSX。
OpenNMS 可以使用 JMX、WMI、SNMP、NRPE、XML HTTP、JDBC、XML、JSON 等收集系統指標。
7:Netdata
Netdata 是一款 Linux 性能實時監測工具,它可以為 Linux 系統、應用程序、SNMP 服務等提供實時的性能監測,目前在物理系統、虛擬機、容器和物聯網/邊緣設備上運行。Netdata具有監控指標多而廣,數據收集速度快等特點,可以同時并發監控數萬個指標,交互式可視化和富有洞察力的健康警報可以即時診斷基礎架構中的異常情況。
8:LibreNMS
LibreNMS 是一個開源、功能豐富且強大的網絡監控系統,易于安裝和配置,可以在多種平臺上使用,它提供了廣泛的功能,包括對各種協議的支持、性能監控、警報等;支持廣泛的供應商、設備和協議,包括 Cisco、Linux、Windows、HP、Juniper、Dell、FreeBsD、Brocade、citrix、f5 Networks 等還可以根據接口進行接口分組,使用 SNMP、CDP、ARP、FDP、OSPF、LLDP、BGP 自動發現整個網絡。
四. Zabbix 系統概述
Zabbix 是一款開源的企業級 IT 基礎設施監控解決方案,由 Alexei Vladishev 于 2001 年開發,現由 Zabbix SIA 公司維護。它專為實時監控網絡服務、服務器健康狀況、應用程序及云資源而設計,通過分布式架構支持大規模監控場景,適用于從小型企業到大型數據中心的多種環境。
核心功能
- 多維度監控能力
- 基礎設施監控:支持 Linux/Windows 服務器、網絡設備(路由器/交換機)的 CPU、內存、磁盤、網絡帶寬等指標監控。
- 應用性能管理(APM):跟蹤數據庫(MySQL、PostgreSQL)、Web 服務(Nginx、Tomcat)、中間件的性能,如查詢延遲、連接數、事務處理速度等。
- 云服務監控:兼容 AWS、Azure、OpenStack 等云平臺,監控虛擬資源(如 EC2 實例、負載均衡器)的使用情況。
- 自定義監控:通過插件或腳本擴展監控范圍,適配企業特定業務需求(如自定義日志分析、業務指標跟蹤)。
- 靈活的數據采集方式
- Agent 模式:在被監控設備上安裝 Zabbix Agent,主動上報數據(如 CPU 使用率)。
- 無 Agent 模式:通過 SNMP、JMX、SSH 等協議直接獲取數據,適用于無法安裝代理的設備(如網絡設備)。
- Trapper 模式:由被監控端主動推送數據到 Zabbix 服務器,適用于防火墻環境或反向代理場景。
- 智能告警與通知
- 觸發器(Trigger):基于預設規則(如“CPU 使用率 >90% 持續 5 分鐘”)自動觸發告警。
- 通知渠道:支持郵件、短信、Slack、釘釘、微信等多種方式,確保運維團隊及時響應。
- 事件收斂:合并重復告警,避免“告警風暴”,提高故障處理效率。
- 數據可視化與分析
- 儀表盤與圖形界面:實時展示監控指標趨勢(如 CPU 利用率曲線、網絡流量圖)。
- 歷史報表:生成 CSV、PDF 等格式的報表,支持數據導出,用于容量規劃、性能分析和合規審計。
- 自定義圖表:適配企業運維中心的可視化需求,支持多監控項組合展示。
- 自動化與擴展性
- 自動發現:自動識別網絡中的新設備(如通過 IP 范圍掃描)并添加到監控列表。
- Proxy 架構:通過代理服務器分擔主服務器負載,支持跨機房、跨地域的分布式監控。
- API 集成:提供 REST API,可與 ITSM、CMDB 等系統集成,實現自動化運維流程。
- 系統架構
- Zabbix 采用 C/S(客戶端-服務器)架構,核心組件包括:
- Zabbix Server:中央組件,負責數據收集、存儲、分析和告警觸發。
- Zabbix Agent:部署在被監控設備上,主動或被動上報數據。
- Database:存儲配置信息、監控數據和歷史記錄,支持 MySQL、PostgreSQL、Oracle 等。
- Web Interface:基于 PHP 的 Web 前端,提供配置、展示和告警管理界面。
- Zabbix Proxy:可選組件,代替 Server 收集性能數據,減輕主服務器負載。
- 技術優勢
- 開源免費:社區版完全開源,企業可根據需求自由定制,降低成本。
- 高擴展性:支持插件、API 接口和自定義腳本,輕松適配復雜 IT 環境。
- 成熟生態:社區活躍,文檔和教程豐富,易于學習和部署。
- 企業級能力:支持數萬節點監控,具備高可用性(HA)和分布式架構,滿足大型企業需求。
- 跨平臺兼容:支持 Windows、Linux、Unix 等主流操作系統,以及 VMware、Docker 等虛擬化平臺。
五. Zabbix的功能特性
Zabbix 作為一款功能全面的開源監控系統,其核心特性覆蓋了從數據采集到智能告警、從可視化展示到自動化運維的全流程。
多維度數據采集與監控
- 支持多種監控類型
- 主機監控:跟蹤服務器、工作站、虛擬機的可用性(如 Ping 檢測)和資源使用率(CPU、內存、磁盤 I/O)。
- 網絡設備監控:通過 SNMP 協議監控路由器、交換機、防火墻的接口流量、錯誤包、帶寬利用率等。
- 應用服務監控:支持 HTTP/HTTPS、FTP、SMTP 等服務的可用性檢測,以及自定義端口和服務狀態的監控。
- 數據庫監控:集成 JMX、ODBC 等接口,監控 MySQL、PostgreSQL、Oracle 等數據庫的連接數、查詢性能、鎖等待等指標。
- 云資源監控:兼容 AWS EC2、Azure VM、OpenStack 實例等云服務的狀態和資源使用情況。
靈活的數據采集方式
- Zabbix Agent:輕量級代理程序,主動上報數據(如 /proc 文件系統信息)或響應 Server 請求。
- 無 Agent 模式:通過 SNMP、IPMI、SSH、Telnet 等協議直接獲取數據,適用于無法安裝代理的設備。
- 外部檢查:調用自定義腳本或第三方工具(如 Nmap、Prometheus Exporter)采集數據,擴展監控范圍。
- 依賴監控:定義監控項之間的依賴關系(如“Web 服務依賴數據庫服務”),避免誤報。
- 智能告警與事件管理
- 觸發器(Trigger)與條件判斷
- 基于監控項的閾值或表達式(如 {server:cpu.user.last(0)}>90)定義觸發條件。
- 支持邏輯運算符(AND/OR)和復雜表達式,實現多條件組合告警(如“CPU >90% 且內存 <10% 剩余”)。
- 依賴觸發器:避免上層服務故障觸發下層組件的冗余告警(如“數據庫故障時,不觸發應用服務的高負載告警”)。
多渠道通知與升級策略
- 通知方式:支持郵件、短信、Slack、釘釘、Webhook、企業微信等,可自定義通知模板(如包含故障時間、影響范圍)。
- 告警升級:定義未確認告警的升級路徑(如“首次通知運維人員,30 分鐘后未處理則通知主管”)。
- 維護模式:臨時屏蔽特定主機或服務的告警,避免維護期間產生噪音。
- 事件關聯與根因分析
- 事件標簽:為告警添加標簽(如“網絡故障”“數據庫鎖等待”),便于分類和過濾。
- 問題時間線:展示告警從觸發到恢復的全過程,結合相關監控數據輔助定位根因。
- 拓撲可視化:通過自動發現或手動配置網絡拓撲,直觀展示故障傳播路徑。
數據存儲與歷史分析
- 高性能數據存儲
- 時序數據庫優化:Zabbix 原生支持高效存儲數值型監控數據,支持按時間范圍壓縮歷史數據(如保留 7 天原始數據,30 天聚合數據)。
- 分區表設計:數據庫表按時間分區,提升歷史數據查詢速度。
- 外部存儲集成:支持將歷史數據導出到外部數據庫(如 TimescaleDB)或對象存儲(如 S3),降低主庫壓力。
- 歷史數據分析與報表
- 趨勢預測:基于歷史數據生成趨勢圖,預測資源使用峰值(如“下周 CPU 負載可能達到 95%”)。
- SLA 報告:統計服務可用性(如“Web 服務 99.9% 可用”),生成合規性報告。
- 自定義報表:通過 SQL 查詢或內置報表工具生成業務相關報表(如“按部門統計資源消耗”)。
可視化與用戶界面
- 動態儀表盤
- 拖拽式布局:支持自定義儀表盤,組合圖表、地圖、文本框等組件。
- 實時刷新:圖表數據可配置自動刷新間隔(如每 5 秒更新一次)。
- 多屏適配:儀表盤支持響應式設計,適配不同設備屏幕(如 PC、大屏、移動端)。
- 高級圖表類型
- 拓撲圖:展示主機、服務之間的依賴關系,支持動態狀態標記(如綠色表示正常,紅色表示故障)。
- 熱力圖:可視化資源使用率分布(如“按小時統計 CPU 負載熱力圖”)。
- 3D 圖表:展示多維數據(如“按地區、時間統計網絡流量”)。
- 用戶權限管理
- 基于角色的訪問控制(RBAC):定義用戶組(如“運維組”“管理員”),分配不同權限(如“只讀”“配置修改”)。
- 審計日志:記錄所有用戶操作(如“用戶 A 修改了觸發器 B 的閾值”),滿足合規性要求。
自動化與擴展性
- 自動發現與配置
- 網絡自動發現:通過 ICMP Ping、SNMP 掃描自動識別網絡中的主機和服務。
- LLD(Low-Level Discovery):動態生成監控項、觸發器(如“自動發現磁盤分區并監控使用率”)。
- API 集成:通過 REST API 與 CMDB、ITSM 系統同步資產信息,實現監控配置自動化。
- 插件與第三方集成
- 社區插件:Zabbix 官方和社區提供大量插件(如監控 Docker、Kafka、Elasticsearch)。
- Webhook 支持:通過 Webhook 將告警信息推送至 Jira、PagerDuty 等外部系統。
- Prometheus 集成:通過 Zabbix-Prometheus 適配器采集 Prometheus 指標,實現混合監控。
- 高可用與分布式架構
- Zabbix Proxy:在分支機構部署代理服務器,集中上報數據至主 Server,減少帶寬占用。
- 集群模式:支持多臺 Zabbix Server 組成集群,實現負載均衡和故障轉移。
- 數據庫高可用:集成 MySQL Galera、PostgreSQL 流復制等方案,保障數據可靠性。
安全與合規性
- 數據加密
- 傳輸加密:支持 HTTPS、SSH 協議加密數據傳輸。
- 存儲加密:可選數據庫加密插件(如 MySQL Transparent Data Encryption)保護歷史數據。
- 認證與授權
- 多因素認證(MFA):集成 Google Authenticator、DUO 等實現雙因素認證。
- 單點登錄(SSO):支持 LDAP、SAML 協議與企業身份系統集成。
- 合規性支持
- 審計日志:記錄所有配置變更和用戶操作,滿足 GDPR、ISO 27001 等合規要求。
- 數據保留策略:自定義歷史數據保留周期,避免數據泄露風險。
六. Zabbix角色及架構
Zabbix 的角色與架構設計圍繞分布式監控需求展開,通過模塊化組件和靈活的權限管理實現高效、可擴展的監控解決方案
Zabbix 核心角色
- Zabbix Server
- 功能:作為監控系統的中樞,負責接收、處理和存儲所有監控數據,觸發告警規則,生成報表,并管理分布式組件(如 Proxy)。
- 關鍵進程:
- Poller:主動采集 Agent 數據。
- Trapper:接收 Agent 主動推送的數據。
- Alert:處理告警規則并觸發通知。
- Notifier:通過郵件、短信等方式發送告警。
- 部署建議:單節點建議監控不超過 5000 臺主機,超大規模環境需結合 Proxy 分布式部署。
- Zabbix Proxy
- 功能:可選組件,用于分布式監控場景,替代 Server 收集本地數據并批量轉發,減輕 Server 負載。
- 核心特性:
- 本地緩存:斷網時暫存數據,網絡恢復后自動續傳。
- 獨立數據庫:存儲短期數據(如未發送的歷史數據),與 Server 數據庫分離。
- 部署建議:每個 Proxy 建議監控不超過 5000 個監控項,與 Server 保持穩定網絡連接。
- Zabbix Agent
- 功能:輕量級數據采集器,部署在被監控設備上,支持兩種模式:
- 被動模式:響應 Server/Proxy 的輪詢請求(默認端口 10050/TCP)。
- 主動模式:主動推送數據到 Server/Proxy,適合大規模環境。
- 擴展性:支持自定義監控項(UserParameters)和 SNMP、JMX 等協議。
- 功能:輕量級數據采集器,部署在被監控設備上,支持兩種模式:
- Database
- 支持類型:MySQL/MariaDB(最常用)、PostgreSQL、Oracle、IBM DB2。
- 設計特點:
- 分區存儲:歷史數據按周分區,趨勢數據按月分區。
- 定期歸檔:建議配置腳本自動歸檔舊數據,避免表膨脹。
- 性能優化:
- 調整 innodb_buffer_pool_size(建議 8GB 以上)。
- 啟用 innodb_log_file_size(如 512MB)提升寫入性能。
- Web Interface
- 技術棧:基于 PHP+JavaScript 的前端,提供儀表盤、配置管理、報表生成等功能。
- 安全建議:啟用 HTTPS 加密訪問,配置 API 白名單。
- REST API:支持與第三方系統(如 Jira、釘釘)集成。
Zabbix 架構類型
- 單 Server 架構
- 適用場景:小型環境(<100 臺設備)。
- 特點:Server 與數據庫同機部署,簡單易維護,但性能瓶頸明顯。
- 主備 Server 架構
- 適用場景:中型企業(100-1000 臺設備)。
- 特點:
- 雙 Server 部署(主備),數據庫獨立并采用主從復制。
- 通過 Keepalived 實現 VIP 漂移,保障高可用。
- 示例配置:
- 上海數據中心:主 Server + Proxy1(IDC1)、Proxy2(IDC2)。
- 北京數據中心:備 Server + Proxy3(IDC3)。
- 多級 Proxy 架構
- 適用場景:超大規模環境(>1000 臺設備)。
- 特點:
- 區域 Proxy:按地理分布部署(如北京 Proxy、上海 Proxy)。
- 業務 Proxy:按業務系統劃分(如 ERP Proxy、CRM Proxy),實現故障隔離。
- 網絡隔離 Proxy:跨越防火墻部署(DMZ Proxy、內網 Proxy),通過 Proxy 中轉數據。
權限管理:用戶、組與角色
- 用戶(User)
- 屬性:別名、密碼、語言、時區等。
- 權限繼承:通過用戶組分配權限,無法直接修改自身角色。
- 用戶組(User Group)
- 功能:組織用戶并分配主機組權限。
- 權限級別:
- Read-write:讀寫訪問。
- Read-only:只讀訪問。
- Deny:拒絕訪問。
- 標簽過濾器:基于標簽(如業務部門、環境)過濾問題集。
- 角色(Role)
- 定義:權限集合,簡化權限管理。
- 預定義角色:
- Admin:管理用戶和配置,但無超級權限。
- Super Admin:完全控制權。
- Guest:只讀訪問部分數據。
- 自定義角色:通過“管理”→“用戶角色”創建,支持細粒度權限控制(如限制 API 訪問)。
七. 部署zabbix
資源清單
操作系統 | 主機名 | IP | 角色 |
OpenEuler | zabbix | 192.168.10.107 | zbbix服務端 |
OpenEuler | proxy | 192.168.10.106 | zabbix proxy |
OpenEuler | server01 | 192.168.10.101 | 被監控節點 |
OpenEuler | server01 | 192.168.10.102 | 被監控節點 |
基礎環境
關閉防火墻和SELinux
修改主機名
1. 部署zabbix源
添加zabbix源
安裝軟件包
備注:
- zabbix6.4.8 需要的各個平臺軟件的版本:
- mysql的版本要求8.0.30-8.1.X
- mariadb 的版本要求10.5.60-11.1.X
- nginx 的版本要求1.20 or later
- php 的版本要求7.4.0-8.2.X
配置數據庫
導入數據
沒有報錯誤信息就是導入成功
配置zabbix server
修改/etc/zabbix/zabbix_server.conf文件129行去掉注釋
配置zabbix頁面
修改/etc/nginx/conf.d/zabbix.conf文件 去掉注釋
啟動服務
2. zabbix頁面配置
登錄zabbix
http://192.168.10.107:8080
3. 解決圖像字體顯示問題
4. 配置被監控端Agent
添加zabbix源和安裝軟件包
配置agent
修改/etc/zabbix/zabbix_agentd.conf文件 分別是117行、171行、182行
啟動服務
添加主機?
數據采集--》主機--》創建主機
直接添加主機
- 主機名稱:和 Agent 服務配置文件中的 Hostname 保持一致
- 模板:有很多自帶的模板,也可以自己創建
- 主機群組:可以選擇已有的,也可以自己創建一個群組
- 接口:添加 Agent 節點,IP 地址填寫被監控節點的IP
第二個別監控主機一樣的操作
注意配置文件里面的名稱
5. 部署proxy
添加zabbix源
安裝軟件包
導入數據(在zabbix server節點執行)
(proxy節點執行)
IP地址修改為zabbix server的ip
zabbix server節點執行
配置zabbix proxy
修改/etc/zabbix/zabbix_proxy.conf文件
- 大約 32 行左右,修改為 zabbix server 節點的 IP
- Server=192.168.10.107
- 大約 42 行左右,可以修改,這里不做修改,后續 web 頁面添加時名字要和這里保持一致
- Hostname=Zabbix proxy
- 大約 157 行左右,取消注釋修改為 zabbix server 節點的 IP
- DBHost=192.168.10.107
- 大約 194 行左右,取消注釋為數據庫的密碼
- DBPassword=zabbix
啟動服務
web頁面添加proxy
管理--》proxy--》創建agent代理
勾選點應用?
修改server01或server02的地址指向proxy重啟
可以看到proxy有東西了而且可用性是綠色就成功了