1.2 監控系統的實現原理
1.2.1 模塊組成
一個監控系統的組成大體可以分為兩部分：數據采集部分（客戶端，Agent）和數據存儲分析告警展示部分（服務器端，Server），如圖1-2所示。這兩部分構成了監控系統的基本模型。
1.2.2 采集協議
按照支持的協議方式，監控系統數據采集可以分為兩種：專用客戶端采集和公用協議采集（SNMP、IPMI、SSH、Telnet等），如圖1-3所示。
1.2.3 采集模式
監控系統數據采集的工作模式可以分為被動模式（從服務器端到客戶端采集數據，對應的英文單詞是pull）和主動模式（客戶端主動上報數據到服務器端，對應的英文單詞是push）兩種，如圖1-4所示。通常，大多數監控系統都應該能同時支持這兩種工作模式，但不同的監控系統由于采集技術不同，僅有部分能夠同時支持這兩種工作模式。
一般來說，被動模式對監控控制端服務器的開銷較大，適合小規模的監控環境；主動模式對監控控制端服務器的開銷較小，適合大規模的監控環境。
1.2.4 監控指標
監控系統通常都支持一些常見的監控采集指標，如操作系統監控、應用程序監控等。部分常見的監控指標如表1-1所示。
表1-1 部分常見的監控指標
對于大規模的監控環境，被監控節點多且監控類型多，監控產生的數據和網絡連接開銷非常大，數據采集方式除了使用主動采集模式，還需要使用代理架構，通過代理架構分攤服務器端的性能開銷。另外，代理架構還支持跨地域、跨網絡的分布式監控。常見的代理架構，即C/P/S（Client/Proxy/Server，客戶端/代理端/服務器端，此處的Client和Agent意思等同，都表示客戶端，下同）架構，如圖1-5所示。采用中間代理將大大提高監控服務器端的處理速度，從而支撐構建大型分布式監控環境，從架構上支持異地多機房的需求。
對于小型的監控環境，被監控節點不多且處于同一地域或網絡環境下，監控系統所需采集的監控數據量較少，采用C/S（Client/Server，客戶端/服務器端）架構即可滿足監控業務需求。
1.2.6 數據存儲
在監控客戶端采集數據之后，會將數據上傳給監控服務器端，監控服務器端程序將接收到的數據進行存儲。通常監控系統會選用以下幾種數據存儲方式。
（1）本地存儲。使用本地磁盤，基于文件的方式存儲。
（2）使用時序數據庫進行數據存儲，如古老的環狀數據庫（Round Robin Database, RRD）等。近年來，隨著時序數據技術的不斷發展，出現了比較成熟的時序數據庫，如OpenTSDB（底層存儲基于HBase）、Graphite、InfluxDB、Prometheus等，與直接使用文件的存儲方式相比，這些時序數據庫更加高效。
目前時序數據庫領域相關技術的發展速度較快，應用的生態也逐步完善，基于時序數據庫的監控系統會逐漸增多。從長遠角度來看，使用時序數據庫存儲監控數據，是必然的發展趨勢。
（3）使用數據庫管理系統（Database Management System, DBMS）進行數據存儲，如常見的MySQL、Oracle、SQL Server等。使用這種數據庫來存儲監控數據，當數據量達到一定規模時，其讀/寫效率均會顯著下降，數據庫的壓力比較大，通常優化方案思路有3種，一是減少數據的存儲量；二是優化數據庫本身，調整配置參數，優化運行環境；三是使用分布式數據庫和數據庫集群技術方案。故使用DBMS作為數據存儲的監控系統，對數據庫本身的掌握程度決定了監控系統能否在大規模環境下良好工作。
（4）使用NoSQL數據庫進行數據存儲。NoSQL相對于DBMS這種傳統的數據庫有著一些天然的優勢，單機的QPS通常較高。但NoSQL本身并不是為監控系統設計的，在數據結構存儲方面存在一些缺陷，故直接采用NoSQL作為監控數據存儲的監控系統產品較少。
（5）使用列存儲數據庫進行數據存儲。列存儲數據庫由于其設計之初專為大數據而有所考慮，故無須擔心其存儲容量，底層均有良好的解決方案。但由于其部署、運維均較為復雜，故一般監控系統也不會常采用這種技術作為數據庫存儲。這方面的數據庫代表為HBase。
（6）使用全文搜索引擎數據庫進行監控數據存儲。這方面的代表是Elasticsearch，其作為監控數據庫存儲監控數據具有天然的優勢，支持集群、分布式部署、容災，并且集群能夠提供較高的性能。目前采用全文搜索引擎數據庫進行監控數據存儲，典型的代表是ELK套件，而Zabbix監控系統也在這方面進行了嘗試，在Zabbix 4.0中可以選用Elasticsearch作為數據庫存儲。
以上我們看到在不同的場合下監控系統對數據的存儲要求會不同，因此，有些監控系統產品直接將數據庫存儲的選項交給了使用者來決定，會同時支持多種方式的數據庫存儲。
1.2.7 告警功能
監控系統的重要功能是根據設定的閾值進行告警，同時也要求在發生故障時有一定的故障自動化處理功能，對于特殊的告警還需要具備告警的升級功能，將不同級別的告警分成不同的梯度發送給不同的告警接收人。
雖然監控系統的重要功能是告警，但過多地發送告警，對于監控系統的使用效果來說，反而會不理想。因為人的精力是有限的，不可能隨時隨地等待著故障發生而立即處理故障，當告警過多時，我們需要優化監控系統。
在觸發和發送告警時，告警模塊需要支持故障的有效匯報和集中匯報，盡量避免出現“告警風暴”，防止同一時間大量發送重復、類似的告警，即告警功能支持對告警內容進行分析和自動處理，防止誤報、漏報及抖動。對于大多數監控系統來說，這一點都是一個值得挑戰和研究的課題。舉一個實際的例子，當機房網絡發生故障時，按照常規，用戶會收到無數條告警信息，內容是每臺設備的故障。但如果將告警聚合，我們希望收到的信息是“某機房存在網絡故障，受影響的設備IP地址是X.X.X.X，受影響的業務是XXX”。
事后還需要對告警信息進行統計分析，以方便對系統的運行情況進行分析統計，從而衡量系統的穩定性、可用性。通常使用SLA服務質量指標來衡量。
1.2.8 可擴展性
可擴展性是指監控系統本身具備良好的擴展能力，包括監控方式的擴展、監控能力的擴展、監控數據存儲的擴展、分布式的支持等。要求監控系統能夠隨著不同環境而做出改變和調整，大多數監控系統都具備一定的擴展能力。
對于告警，要求支持多種方式，如短信、郵件、即時通信和其他接口，且具備可定制化能力，可以對第三方告警介質提供可編程接口。這一點在很多場合都非常重要，例如，將告警結果發送到專用的告警分析系統。
監控系統需要根據實際應用的需求，實時/非實時地采集和展示數據。另外，還包括歷史趨勢數據的展示和分析，以及容量報表、可用性報告的生成。
1.2.9 總結歸納
以上我們共同學習了監控系統的組成、監控架構的設計、監控指標的采集、監控數據的存儲、監控告警的發送和分析，并探討了監控系統的可擴展性。通過對這些方面的探討，我們對監控有了一個全面的認識。
在一個監控系統中，構成要素為監控服務器端程序、數據存儲、被采集節點等相關模塊，其告警分析和自動故障處理功能由服務器端執行。在數據采集完成之后，需要對采集到的數據進行分析和處理，判斷是否有異常、是否符合告警條件。那么如何配置告警條件呢？通常是根據實際的經驗值、業務需求來設置告警閾值的。當達到告警條件時，則發送告警信息給管理人員。然而，對于有些故障，我們希望程序能自動處理，減少人工干預，讓程序自動修復，只在出現嚴重故障、程序無法判斷時，才發送告警通知管理人員處理。
一個監控系統往往需要集成資產管理系統，如圖1-6所示，資產管理功能可以從邏輯上展示業務用途的信息，通過對其進行數據分析，做到對投資與回報的反饋展示，為資產的合理規劃與使用提供依據。
從工作模式來看，監控系統的數據采集可以分為兩種：主動監控和被動監控。一個理想的監控系統采集端支持的采集方式越多，其擴展能力越強大，適用的環境場合越多。
監控系統需要具有對外提供API的能力，方便第三方應用系統對監控數據進行操作管理。通常能對外提供API功能的軟件，意味著其擴展能力更強大，因而會更加受到用戶的喜愛。API的方式一般可以分為RESTful、SOAP等，在API中使用的數據類型可以為JSON、XML等。從目前的趨勢來看，RESTful已經成為絕大多數API首選的方式。
監控系統需要對故障數據進行分析匯總，從故障數據中分析出現的概率，進而可以積累數據經驗，避免以后出現類似的問題。例如，通過分析統計機器硬件導致故障的概率有多大、哪些部件最容易出問題、出問題的影響概率有多大、立即解決問題的概率有多大等問題，在此基礎上進行分析匯總，就可以整理出有效的相應故障對策和技術應急方案。