《Zabbix企業級分佈式監控系統第2版》正式發佈

 吳兆鬆 資深系統工程師，Zabbix監控系統「紅寶書」做者，熟悉IT運維領域，對服務器運維、應用運維以及運維（DevOps）平臺的構思、設計、開發等都具備十分豐富的經驗，尤爲擅長IT監控系統的運維和開發，是國內最先一批使用和研究Zabbix的用戶，爲幾十個大型企業構建過Zabbix監控平臺體系。從業經歷至關豐富，對運維、編程、產品都有深刻的實踐，被業內人士戲稱爲「監控專家」。

本文主要闡述監控系統的發展歷程、監控系統的原理，以及監控系統的項目實踐，目的是讓你們全面瞭解監控系統。

監控，從中文的字義來看，有兩個內容，一是監測，二是控制，重點在第一個字眼「監」上，即監測、預防的意思。監控，對應的英文單詞是Monitoring。按照維基百科對於Monitoring的分類，在計算機領域，能夠將其分爲應用性能監控、業務交易監控、網絡性能監控、操做系統監控、網絡站點監控5種。上面5種類型將「監控」這個大概念劃分紅多個領域。咱們一般所說的監控，會模糊地包含以上5個細分領域的內容。在任何一個IT業務環境中，都會存在各類各樣的硬件設備、軟件應用等。按照邏輯層次劃分，咱們能夠將其劃分爲如圖1所示的模型。

圖1 IT業務架構環境邏輯層次模型

多種應用構成了複雜的IT業務系統，如何保證這些資源正常運轉，是各公司內IT部門的重要職責。要讓這些應用可以穩定地運行，則須要專業的IT人員進行規劃、設計、架構、維護和調優。在這個過程當中，爲了及時掌控基礎環境和業務應用系統的可用性，須要獲取各個組件的運行狀態，如CPU的利用率、系統的負載、服務的運行、端口的連通、帶寬流量、網站訪問狀態碼等信息，而這一切都離不開監控系統的支撐。

模塊組成

一個監控系統的組成大致能夠分爲兩部分：數據採集部分（客戶端，Agent）和數據存儲分析告警展現部分（服務器端，Server），如圖2所示。這兩部分構成了監控系統的基本模型。

圖2 監控系統的基本模型

採集協議

按照支持的協議方式，監控系統數據採集能夠分爲兩種：專用客戶端採集和公用協議採集（SNMP、IPMI、SSH、Telnet等）如圖3所示。

圖3 監控系統數據採集協議分類

採集模式

監控系統數據採集的工做模式能夠分爲被動模式（從服務器端到客戶端採集數據，對應的英文單詞是pull）和主動模式（客戶端主動上報數據到服務器端，對應的英文單詞是push）兩種，如圖4所示。一般，大多數監控系統都應該能同時支持這兩種工做模式，但不一樣的監控系統因爲採集技術不一樣，僅有部分可以同時支持這兩種工做模式。

圖4 監控系統數據採集的工做模式

通常來講，被動模式對監控控制端服務器的開銷較大，適合小規模的監控環境；主動模式對監控控制端服務器的開銷較小，適合大規模的監控環境。

監控指標

監控系統一般都支持一些常見的監控採集指標，如操做系統監控、應用程序監控等。部分常見的監控指標如表1所示。

表1 部分常見的監控指標

代理架構

對於大規模的監控環境，被監控節點多且監控類型多，監控產生的數據和網絡鏈接開銷很是大，數據採集方式除了使用主動採集模式，還須要使用代理架構，經過代理架構分攤服務器端的性能開銷。另外，代理架構還支持跨地域、跨網絡的分佈式監控。圖5爲常見的代理架構C/P/S（客戶端/代理端/服務器端，此處的Client和Agent意思等同，都表示客戶端，下同）架構。採用中間代理將大大提升監控服務器端的處理速度，從而支撐構建大型分佈式監控環境，從架構上支持異地多機房的需求。

圖5 監控系統的代理架構

對於小型的監控環境，被監控節點很少且處於同一地域或網絡環境下，監控系統所需採集的監控數據量較少，採用C/S（Client/Server，客戶端/服務器端）架構便可知足監控業務需求。

數據存儲

在監控客戶端採集數據以後，會將數據上傳給監控服務器端，監控服務器端程序將接收到的數據進行存儲。一般監控系統會選用如下幾種數據存儲方式。

本地存儲。使用本地磁盤，基於文件的方式存儲。

使用時序數據庫進行數據存儲，如古老的環狀數據庫（Round Robin Database, RRD）等。近年來，隨着時序數據技術的不斷髮展，出現了比較成熟的時序數據庫，如OpenTSDB（底層存儲基於HBase）、Graphite、InfluxDB、Prometheus等，與直接使用文件的存儲方式相比，這些時序數據庫更加高效。目前時序數據庫領域相關技術的發展速度較快，應用的生態也逐步完善，基於時序數據庫的監控系統會逐漸增多。從長遠角度來看，使用時序數據庫存儲監控數據，是必然的發展趨勢。

使用數據庫管理系統（DatabaseManagement System）進行數據存儲，如常見的MySQL、Oracle、SQL Server等。使用這種數據庫來存儲監控數據，當數據量達到必定規模時，其讀/寫效率均會顯著降低，數據庫的壓力比較大，一般優化方案思路有3種，一是減小數據的存儲量；二是優化數據庫自己，調整配置參數，優化運行環境；三是使用分佈式數據庫和數據庫集羣技術方案。故使用DBMS做爲數據存儲的監控系統，對數據庫自己的掌握程度決定了監控系統可否在大規模環境下良好工做。

使用NoSQL數據庫進行數據存儲。NoSQL相對於DBMS這種傳統的數據庫有着一些自然的優點，單機的QPS一般較高。但NoSQL自己並非爲監控系統設計的，在數據結構存儲方面存在一些缺陷，故直接採用NoSQL做爲監控數據存儲的監控系統產品較少。

使用列存儲數據庫進行數據存儲。列存儲數據庫因爲其設計之初專爲大數據而有所考慮，故無須擔憂其存儲容量，底層均有良好的解決方案。但因爲其部署、運維均較爲複雜，故通常監控系統也不會常採用這種技術做爲數據庫存儲。這方面的數據庫表明爲HBase。

使用全文搜索引擎數據庫進行監控數據存儲。這方面的表明是Elasticsearch，其做爲監控數據庫存儲監控數據具備自然的優點，支持集羣、分佈式部署、容災，而且集羣可以提供較高的性能。目前採用全文搜索引擎數據庫進行監控數據存儲，典型的表明是ELK套件，而Zabbix監控系統也在這方面進行了嘗試，在Zabbix 4.0中能夠選用Elasticsearch做爲數據庫存儲。

以上咱們看到在不一樣的場合下監控系統對數據的存儲要求會不一樣，所以，有些監控系統產品直接將數據庫存儲的選項交給了使用者來決定，會同時支持多種方式的數據庫存儲。

告警功能

監控系統的重要功能是根據設定的閾值進行告警，同時也要求在發生故障時有必定的故障自動化處理功能，對於特殊的告警還須要具有告警的升級功能，將不一樣級別的告警分紅不一樣的梯度發送給不一樣的告警接收人。

雖然監控系統的重要功能是告警，但過多地發送告警，對於監控系統的使用效果來講，反而會不理想。由於人的精力是有限的，不可能隨時隨地等待着故障發生而當即處理故障，當告警過多時，咱們須要優化監控系統。

在觸發和發送告警時，告警模塊須要支持故障的有效彙報和集中彙報，儘可能避免出現「告警風暴」，防止同一時間大量發送重複、相似的告警，即告警功能支持對告警內容進行分析和自動處理，防止誤報、漏報及抖動。對於大多數監控系統來講，這一點都是一個值得挑戰和研究的課題。舉一個實際的例子，當機房網絡發生故障時，按照常規，用戶會收到無數條告警信息，內容是每臺設備的故障。但若是將告警聚合，咱們但願收到的信息是「某機房存在網絡故障，受影響的設備IP地址是X.X.X.X，受影響的業務是XXX」。

過後還須要對告警信息進行統計分析，以方便對系統的運行狀況進行分析統計，從而衡量系統的穩定性、可用性。一般使用SLA服務質量指標來衡量。

可擴展性

可擴展性是指監控系統自己具有良好的擴展能力，包括監控方式的擴展、監控能力的擴展、監控數據存儲的擴展、分佈式的支持等。要求監控系統可以隨着不一樣環境而作出改變和調整，大多數監控系統都具有必定的擴展能力。

對於告警，要求支持多種方式，如短信、郵件、即時通訊和其餘接口，且具有可定製化能力，能夠對第三方告警介質提供可編程接口。這一點在不少場合都很是重要，例如，將告警結果發送到專用的告警分析系統。

監控系統須要根據實際應用的需求，實時/非實時地採集和展現數據。另外，還包括歷史趨勢數據的展現和分析，以及容量報表、可用性報告的生成。

總結概括

以上咱們共同窗習了監控系統的組成、監控架構的設計、監控指標的採集、監控數據的存儲、監控告警的發送和分析，並探討了監控系統的可擴展性。經過對這些方面的探討，咱們對監控有了一個全面的認識。

在一個監控系統中，構成要素爲監控服務器端程序、數據存儲、被採集節點等相關模塊，其告警分析和自動故障處理功能由服務器端執行。在數據採集完成以後，須要對採集到的數據進行分析和處理，判斷是否有異常、是否符合告警條件。那麼如何配置告警條件呢?一般是根據實際的經驗值、業務需求來設置告警閾值的。當達到告警條件時，則發送告警信息給管理人員。然而，對於有些故障，咱們但願程序能自動處理，減小人工干預，讓程序自動修復，只在出現嚴重故障、程序沒法判斷時，才發送告警通知管理人員處理。

一個監控系統每每須要集成資產管理系統，如圖6所示，資產管理功能能夠從邏輯上展現業務用途的信息，經過對其進行數據分析，作到對投資與回報的反饋展現，爲資產的合理規劃與使用提供依據。

圖6 監控系統與資產管理系統的集成

從工做模式來看，監控系統的數據採集能夠分爲兩種：主動監控和被動監控。一個理想的監控系統採集端支持的採集方式越多，其擴展能力越強大，適用的環境場合越多。

監控系統須要具備對外提供API的能力，方便第三方應用系統對監控數據進行操做管理。一般能對外提供API功能的軟件，意味着其擴展能力更強大，於是會更加受到用戶的喜好。API的方式通常能夠分爲RESTful、SOAP等，在API中使用的數據類型能夠爲JSON、XML等。從目前的趨勢來看，RESTful已經成爲絕大多數API首選的方式。

監控系統須要對故障數據進行分析彙總，從故障數據中分析出現的機率，進而能夠積累數據經驗，避免之後出現相似的問題。例如，經過分析統計機器硬件致使故障的機率有多大、哪些部件最容易出問題、出問題的影響機率有多大、當即解決問題的機率有多大等問題，在此基礎上進行分析彙總，就能夠整理出有效的相應故障對策和技術應急方案。

監控系統項目概述

在大型的IT架構環境中，IT系統的組成部分一般是跨區域分佈在多個省市的；跨節點，多IDC，網絡線路分爲電信、聯通、移動等；業務類型衆多、系統構成複雜、業務需求多樣，是這種大型環境的特色。在互聯網業務中，新舊替代的速度是很是迅速的，所以，監控系統要能知足業務不斷變化的需求。

在這種環境中構建監控系統，首先要作的事情是掌握全局信息，以及須要考慮業務將來的發展趨勢。接下來是選擇合適的技術方案，一般，這個技術方案既要能知足於當前業務須要，又要能知足於不斷增加的業務需求，因此進行合理的規劃和預測，加上必定的理論和實踐經驗，才能設計出一套比較完美的解決方案。

在大規模的監控系統中，須要考慮如下因素。

1.分佈式架構是首要考慮因素。要求系統架構具有分佈式的設計，原則是將中心節點壓力分散在各邊緣節點上，使其儘量監控更多的設備。

2.數據存儲擴展的問題。節點數量增長到必定規模後，給監控數據的存儲帶來了十分嚴峻的挑戰，數據存儲擴展的問題是整個監控系統可否正常工做的前提條件。

3.高可用性和健壯性、穩定可靠的系統架構、冗餘的災備，是大型監控系統必備條件。

4.提供API的能力，易於與第三方集成。在大型環境中，一個孤立的監控系統會給其餘業務系統形成很大的麻煩，一般須要花費更多的精力進行改造，使其爲其餘系統提供所需的數據。

5.具有自動化功能。自動化是解放繁重的體力勞動最有效的方式，將來的運維必定更智能、更偏向於業務，以業務爲核心，而不是僅僅解決系統的底層問題。

以上觀點適用於任何監控系統，而不只僅是Zabbix。

監控系統項目背景

在企業的生命歷程中，在不一樣階段突顯的矛盾均有不一樣體現。在初始階段，以業務的原型實現爲主；在發展階段，以知足業務增加需求爲主；在穩定階段，以優化業務成本和發展爲主。而技術在不一樣階段所具備的做用也是不一樣的，以業務爲驅動的公司，技術一般起輔助支撐做用；以技術爲命脈的公司，技術爲其核心資源；以互聯網爲表明的公司，每每是技術和業務協調發展，以知足企業的成長髮展須要，對技術從業人員的要求很是高，一般技術更新換代速度較快，要求技術人員可以根據不一樣的業務，採用不一樣的技術方案；以傳統業務爲表明的公司，每每是業務發展在前，技術落地在後，其技術決策週期每每較長，管理者以求穩定大局爲主，故大多數技術人員都比較保守，不會輕易採用較新的技術。在明白這個前提下，針對本身所在公司的特色，對於監控系統的構建每每會考慮得更全面。

在IT運維管理中，平常的工做能夠分爲三類：一是基礎環境搭建；二是維護與更新；三是監控告警與調整優化。在維護與更新的工做中，能夠採用手動或自動化工具來實現，都可以知足不一樣企業的需求。對於配置統1、基礎環境一致的環境，一般會採用統一的配置管理工具，如Puppet、SaltStack、Ansible、Chef等。而有些環境，配置變動不頻繁，其無法統一管理，如一年半載可能才發生一次變動，而相同規模的設備很少，在這種狀況下，配置管理工具就沒法發揮它的優點了。可是對於監控告警系統，不管是互聯網公司仍是傳統公司，都是必不可少的，由於IT設備並非100%可靠的，就算是100%可靠的設備，也會有人爲因素形成服務不可用。所以，集中的監控告警平臺建設，是每一個公司IT部門都十分關心的問題，即便是不懂IT技術的公司成員，也知道監控告警系統是必需的。

在瞭解了IT監控系統的重要性後，咱們來看看具體的監控需求。通常來講，監控系統的構建能夠分爲以下幾個層面。

基礎架構設施的監控，包括硬件服務器、存儲、網絡、虛擬化等。

應用存活與基本性能的監控，包括數據庫、Web應用、中間件、消息隊列、緩存等。

代碼內部的工做狀態監控，這屬於監控的細分領域，須要採用其餘技術來實現，如採用開源的PinPoint、Zipkin、CAT、OpenTraceing等APM監控工具，這種層面的監控，須要軟件工程師在編寫業務代碼時，採用業務監控指標的埋點，進行整個業務調用鏈的監控，通常須要軟件架構師來規劃設計，項目的總體推進實現過程一般較難。

日誌流監控，監控應用設備和應用軟件的日誌，並從日誌中提取相關的指標進行分析，其實現方式有開源的套件ELK等。

在Zabbix可以支持的監控範圍中，上面提到的部分功能被支持。因此，在構建監控系統以前，必須明白監控的具體需求範圍，以避免範圍擴大，從而形成需求蔓延和監控系統使用效果滿意度的降低。

在一般意義的監控建設項目中，通常的需求有：創建基於網絡、存儲、虛擬化、應用、數據庫系統、緩存、消息隊列等的監控預警體系，設備和服務的宕機、恢復均須要實時反饋給運維團隊。監控目標觸發預警後能夠設置重複的輪詢做業確認問題是否存在。設置合理的預警級別，根據預警的重要程度、緊急程度、問題處理程度，預警反饋給不一樣級別的人員。

在監控系統的構建過程當中，監控系統並非孤立存在的，它每每須要與其餘系統打通，造成閉環，讓工做的各個環節進行流通。所以，企業在創建監控系統的過程當中，每每是按照標準產品，加上個性化定製來實現的。

在IT運維管理框架中，每每從邏輯結構上劃分爲五個平臺和一箇中心配置庫（簡稱「五臺一庫」），分別是集中監控平臺、流程管理平臺、數據展示平臺、自動化操做平臺、歷史數據分析平臺和配置管理數據庫（CMDB）。它們的功能以下。

監控平臺：構建整個IT監控架構，實現集中事件管理，併爲面向業務的監控管理打下基礎。

流程管理平臺：整合並標準化運維的平常工做，將平常的工做規範化，並透明化。

數據展示平臺：建設統一報表平臺和統一門戶平臺，將有效加強數據利用和展現效果。

自動化操做平臺：完成對整個IT操做的集中管控和自動化。

歷史數據分析平臺：集中存放歷史數據，提供後期統一分析及規劃。

配置管理數據庫：記錄完整的、準確的IT環境中各組件的信息和彼此間的關聯關係，做爲惟1、可信的數據源，爲周邊系統提供支撐數據。

所以，在這種背景環境下，咱們須要從新審視企業中的IT監控系統項目。不管是高速發展的互聯網企業，仍是平穩發展的傳統企業，抑或是金融保險企業，其構建監控系統的目的都同樣，都是經過監控系統發現故障與問題，並及時通知相關負責人，一線工程師可以根據故障報告快速處理，並對處理的過程和結果進行整理分析，造成知識積累，對於能夠預見的常規故障，制定出應急方案。

監控系統項目步驟

1.梳理現有環境——知己知彼：在接手監控系統構建項目以前，須要梳理現有的環境，從基礎設施、應用系統、日誌分析、應用性能等多個維度進行分析。

2.肯定監控目標——願景宏大：肯定監控系統的目標，是監控網絡設備、服務器仍是應用，以便採起相應的策略。

3.項目規劃藍圖——按部就班：在肯定目標後，須要對整個系統進行詳細規劃，能夠對目標進行一個明確的規劃，好比何時取得什麼樣的成績，交付什麼樣的功能，最終創建一個什麼樣的監控系統。

4.功能逐步深刻——精益求精：採用精益的思惟模式，先從小的功能作起，解決當前環境中的主要矛盾，而後逐步擴大環境，從本團隊作起，再推廣到其餘團隊，最後推廣至全公司。

5.吸收百家之長——資源整合：與其餘系統進行整合，好比與CMDB整合、與ITSM服務流程整合、與自動化運維工具整合、與代碼發佈整合。

6.不斷總結成長——取長補短：經過對環境的不斷驗證，總結過去的經驗，不斷簡化整個監控流程，並定製出符合實際需求的監控功能。

本文節選自新版Zabbix紅寶書《Zabbix企業級分佈式監控系統（第2版）》，採用最新穩定版本Zabbix 4.0並配備大量真實監控案例，是升級版的最大亮點。

本書基於最新穩定版本Zabbix 4.0，對Zabbix的各項功能進行了詳細而深刻的講解，讓讀者真正經過一本書就可以徹底掌握Zabbix監控系統的核心技術。

本書第1版內容收穫了大量讀者好評，是一本實戰性很強的工具書，讀者將其稱爲監控領域的「紅寶書」，書中所寫內容都可以在生產環境中直接應用。而在第2版中，採納了以往讀者的寶貴意見，增長了做者的最新研究成果，擴充了大量內容，但繼續保持由淺入深、由易到難的寫做風格。