zabbix監控-----基礎（簡介）
文章目錄
1. 爲什麼需要監控系統
- 在互聯網企業中，每個企業都會有自己的業務，需要通過底層的各種服務器或者服務器集羣，比如：硬件設備、軟件設備等。
- 多種應用構成複雜的IT業務系統，保證這些資源的正常運轉，是一個公司IT部門的職責。而要讓這些應用能夠穩定地運行，則需要專業IT人員進行設計、架構、維護和調優。在這個過程中，爲了及時掌控基礎環境和業務應用系統的可用性，需要獲取各個組件的運行狀態，如CPU的利用率、系統的負載、服務的運行、端口的連通、帶寬流量、網站訪問狀態碼等信息。而這一切都離不開監控系統。
2. 監控系統的實現
- 一個監控系統的組成大致的可以分爲兩部分：數據採集部分（客戶端）和數據存儲分析告警展示部分（服務器端）
- 數據採集的工作模式可以分爲被動模式（服務器端到客戶端採集數據）和主動模式（客戶端主動上報數據到服務器端）。通常，大多數的監控系統都能夠支持這兩種模式。被動模式對服務器的開銷較大，比較適合小規模的監控環境；主動模式對服務器的開銷較小，比較適合大規模的監控環境。
- 採集數據的協議方式可以分爲兩種：專用客戶端採集和公用協議採集（SNMP、SSH、Telnet等）。
- 對於採集到的監控數據，可以將其存儲到數據庫或者文本或者其他方式，具體採用哪一種，應根據實際需求來決定。怎麼規劃監控系統的架構設計呢?
- 對於一般的監控環境，被監控的節點不多，產生的數據較少，採用C/S(Client/Server，客戶端/服務器端)架構就足夠了，下圖這種架構適合於規模較小、處於同一地域的環境。
- 對於大規模的監控環境，被監控的節點多，且監控類型多，監控產生的數據和網絡連接開銷會非常巨大，而且由於跨地域等多種因素，需要分佈式的解決方案，常見的方式爲C/P/S (Client/Proxy/Server,客戶端/代理端/服務器端)架構，採用中間代理將大大提高監控服務器端的處理速度，從而能支撐構建大型分佈式監控的環境。
- 監控系統更重要的功能是告警和故障處理，這對及時解決問題和故障自愈非常重要。告警的時候，需要考慮到故障的有效彙報和集中彙報，防止出現“告警洪水“，即同一類告警信息重複大量地發送。
3. 常見的開源監控系統
3.1 prometheus
- Prometheus 是雲原生應用程序最受認可的時間序列監控解決方案，由 CNCF 託管，使用 Go 語言開發，是 Google BorgMon 監控系統的類似實現。
- Prometheus 使用的是 Pull 模型，Prometheus Server 通過 HTTP 的 pull 方式到各個目標拉取監控數據。它使用局部配置來描述要收集的端點和收集所需的間隔。 每個端點都有一個客戶端收集數據並在每次請求時更新該表示（或者客戶端是配置的）。 收集此數據並將其保存在本地磁盤上的高效存儲引擎中。 存儲系統使用每個度量標準的僅附加文件。
- prometheus系統架構圖
- Prometheus 包含一種高級表達式語言，用於選擇和顯示名爲 PromQL 的數據。此數據可以通過 REST API 以圖形或表格顯示或由外部系統使用。表達式語言允許用戶創建迴歸，分析實時數據或趨勢歷史數據。標籤也是用於過濾和查詢數據的絕佳工具。標籤可以與每個度量標準名稱相關聯。
- Prometheus 附帶 AlertManager 來處理警報。AlertManager 允許進行警報聚合以及更復雜的流量以限制發送警報的時間。假設在開關關閉的同時 10 個節點突然出問題，你可能不需要發送有關這 10 個節點的告警，因爲接到報警的每個人在開關修好之前可能無法執行任何操作。使用 AlertManager，可以僅向網絡團隊發送有關開關告警，並在其中包含其他可能受影響系統的信息；也可以向系統團隊發送電子郵件（而不是頁面），以便他們知道這些節點已關閉，除非系統在開關修復後沒有恢復，否則他們不需要響應。 如果發生這種情況，則 AlertManager 將重新激活那些被開關警報抑制的警報。
3.2 Graphite
- Graphite 是一款用 Python 寫的開源企業級監控繪圖工具，可以在廉價機硬件上運行。Graphite 可以實時收集、存儲、顯示時間序列類型的數據，它由三個軟件組件組成：
- carbon - 基於 Twisted 的進程，用於監聽並接收數據；
- whisper - 專門存儲時序數據的小型數據庫，在設計上類似於RRD；
- graphite webapp - 基於 Django 的網頁應用程序，可以從 whisper數據庫獲取時間序列數據並且進行展示。
- graphite架構圖
- Graphite 是一個基於推送的系統，通過讓應用程序推送數據到 Graphite 的 Carbon 組件中，從應用程序接收數據。 Carbon 將此數據存儲在 Whisper 數據庫中，Graphite Web 組件讀取 Carbon 它的和數據庫，允許用戶在瀏覽器中繪製數據圖或通過 API 提取數據。一個非常酷的功能是能夠將這些圖形導出爲圖像或數據文件，以便將它們輕鬆嵌入到其他應用程序中。
- Graphite 的另一個有趣功能是能夠存儲與時序指標相關的任意事件。可以在 Graphite 中添加和跟蹤應用程序或基礎架構部署， 這允許運維人員或開發人員對問題進行故障排除，能獲得正在調查的異常行爲環境中更多的背景信息。
3.3 InfluxDB
InfluxDB 是一個相對較新的時序數據庫，使用 Go 語言編寫，無需外部依賴，安裝配置非常方便，適合構建大型分佈式系統的監控系統。
其設計目標是實現分佈式和水平伸縮擴展。
InfluxDB 的一些主要特徵：
- 無結構 (無模式)：可以是任意數量的列
- 可以設置 metric 的保存時間
- 支持與時間有關的相關函數 (如min、max、sum、count、mean、median 等)，方便統計
- 支持存儲策略: 可以用於數據的刪改。(influxDB沒有提供數據的刪除與修改方法)
- 支持連續查詢: 是數據庫中自動定時啓動的一組語句，和存儲策略搭配可以降低 InfluxDB 的系統佔用量。
- 原生的 HTTP 支持，內置 HTTP API
- 支持類似 sql 語法
- 支持設置數據在集羣中的副本數
- 支持定期採樣數據，寫入另外的measurement，方便分粒度存儲數據
- 自帶 web 管理界面，方便使用 (登入方式：http://< InfluxDB-IP>:8083)
3.4 MRTG
- MRTG (Multi Router Traffic Grapher)是一套可用來繪製網絡流量圖的軟件，由瑞士奧爾滕的TobiasOetiker與DaveRand所開發，以GPL授權。MRTG最早的版本是在1995年春推出的，用Perl 語言寫成，可跨平臺使用，數據採集用SNMP協議，MRTG將收集到的數據通過Web頁面以GIF或PNG格式繪製出圖像，並以日、周、月爲單位分別繪出，可以查詢最大值和最小值。
- MRTG原本只能繪出網絡設備的流量圖，後來發展出了各種插件。因此，網絡以外的設備也可由MRTG監控，例如，服務器的硬盤使用量、CPU的負載等。
3.5 Cacti
- Cacti (英文含義爲仙人掌)是一套基於PHP、MySQL、SNMP和RRDtool開發的網絡流量監測圖形分析工具。它通過snmpget來獲取數據，使用RRDtool繪圖，但使用者無須瞭解RRDtool複雜的參數。它提供了非常強大.的數據和用戶管理功能，可以指定每-一個用戶能查看樹狀結構、主機設備以及任何一張圖，還可以與LDAP結合進行用戶認證，同時也能自定義模板，在歷史數據的展示監控方面，其功能相當不錯。
- Cacti通過添加模板，使不同設備的監控添加具有可複用性，並且具備可自定義繪圖的功能，具有強大的運算能力(數據的疊加功能)。
3.6 SmokingPing
- SmokePing主要用於監視網絡性能，包括常規的ping、WWW服務器性能、DNS查詢性能、SSH性能等。底層也是用RRDtool做支持，特點是繪製的圖非常漂亮，網絡丟包和延遲用顏色和陰影來表示，支持將多張圖疊放在一-起。其作者(Tobi Oetiker)還開發了MRTG和RRDtool等工具。
3.7 Nagios
- Nagios是—個企業級的監控系統，可監控服務的運行狀態和網絡信息等，並能監視所指定的本地或遠程主機參數以及服務，同時提供異常告警通知功能等。
- Nagios可運行在Linux和UNIX平臺上，同時提供一一個可選的基於瀏覽器的Web界面，以方便系統管理人員查看網絡狀態、各種系統問題，以及日誌等。
- Nagios的功能側重於監控服務的可用性，能及時根據觸發條件告警。
- 目前，Nagios 也佔領了- -定的市場份額，不過從筆者的觀察來看，Nagios 並沒有與時俱進，已經不能滿足於多變的監控需求，架構的擴展性和使用的便捷性有待增強，其高級功能集成在商業版Nagios XI中。
3.8 zenoss core
- Zenoss Core ( 簡稱Zenoss)是開源企業級IT管理軟件，它允許IT管理員依靠單一的Web控制檯來監控網絡架構的狀態和健康度。
- Zenoss Core的強大功能來自深入的列表與配置管理數據庫，用於發現和管理公司IT環境的各類資產(包括服務器、網絡和其他結構設備)。Zenoss 可以創建關鍵資產清單和對應的組件級別(接口、服務、進程、已安裝的軟件等)。建立好.模型後，Zenoss就可以監控和報告IT架構中各種資源的狀態和性能狀況了。同時還提供與CMDB關聯的事件和錯誤管理系統，以協助提高各類事件和提醒的管理
效率，以此提高IT管理人員的效率。 - Zenoss Core採用SNMP來採集數據。
3.9 Ganglia
- Ganglia是-一個跨平臺的、可擴展的、高性能的分佈式監控系統，如集羣和網格。它基於分層設計，使用廣泛的技術，用RRDtool 存儲數據，具有可視化.界面，適合於對集羣系統的自動化監控。其精心設計的數據結構和算法使得監控端到被監控端的連接開銷非常低。目前已經有成千上萬的集羣正在使用這個監控系統,可以輕鬆地處理2000個節點的集羣環境。
3.10 opentsdb
- 開源監控系統OpenTSDB用HBase存儲所有時序(無須採樣)的數據，來構建一個分佈式、可伸縮的時間序列數據庫。它支持秒級數據採集，支持永久存儲，可以做容量規劃，並很容易地接入到現有的告警系統裏。OpenTSDB可以從大規模的集羣(包括集羣中的網絡設備、操作系統、應用程序)中獲取相應的採集指標，並進行存儲、索引和服務，從而使這些數據更容易讓人理解，如Web化、圖形化等。
- 在對實時性要求比較高的場合，OpenTSDB是一個很好的選擇。它支持秒級別的數據採集，這在其他監控系統中是無法想象的。因得益於其存儲系統的選擇,所以它支持大數據分析。因此，這個開
源軟件在未來的環境中會有更多的用戶，也會獲得更廣泛的支持。
3.11 zabbix
- Zabbix是-一個分佈式監控系統，支持多種採集方式和採集客戶端，有專用的Agent (代理)，也可以支持SNMP、IPMI、 JMX、Telnet、SSH等多種協議，它將採集到的數據存放到數據庫，然後對其進行分析整理，達到條件觸發告警。其靈活的擴展性和豐富的功能是其他監控系統所不能比的。相對來說，它的總體功能做得非常優秀。
4. 監控系統的實現
- 監控系統往往需要對物理硬件和應用軟件的性能和參數進行數據彙集，實現集中管理和統一 分析。
- 在一個監控系統中，構成要素爲監控服務器端程序、數據存儲、被採集節點等相關模塊，其告警分析和自動故障處理功能由服務器端執行。在數據採集完成之後，需要對採集到的數據進行分析和處理，判斷是否有異常，是否屬於告警條件。告警條件如何設置呢?通常是根據實際的經驗值、業務需求來設置告警閾值。
- 達到告警條件時，則發送告警信息給管理人員，然而，對於有些故障，我們希望
程序能自動處理，減少人工干預，讓程序自動修復，只在出現嚴重故障、程序無
法判斷的時候，才告警通知管理人員處理。 - 一個監控系統往往需要集成資產管理,可以從邏輯上展示業務和功能的信息，通過對其進行數據分析，做到對投資與回報的一“個反饋展示，爲資產的合理規劃與使用提供了依據。
- 從其工作模式來看，監控系統的數據採集可以分爲兩種:主動監控和被動監控，一個理想的監控系統，其採集端支持的採集方式越多，其擴張能力越強大，適用的環境場合越多。
- 監控系統需要提供一一個API， 方便其他功能系統對監控數據進行操作管理，這在業務系統精密的情況下顯得特別重要，通常能對外提供API功能的軟件，其用戶羣會更廣，產品會越做越好。API一般可以分爲RESTful、SOAP等形式，數據類型有JSON、XML等多種。從目前的趨勢來看，RESTful 已經成爲絕大多數API首選的方式。
- 監控系統需要對故障數據進行分析彙總，從故障中分析出現的概率，從而可以積累經驗，避免以後出現類似的問題。例如，由於機器硬件導致的故障，其概率有多大，哪些部件最容易出問題，出問題的影響概率多大，問題解決的概率有多大。從監控的數據中就可以分析並發現相關數據，在此基礎上進行分析彙總，可以整理出相應的對策和相應的技術應急方案。
5. 監控系統對時間的要求
- 監控系統需要根據實際應用的需求，實時/非實時地採集和展示數據。另外，包括歷史趨勢數據的展示和分析，以及容量報表、可用性報告的生成。
6. 監控系統的告警需求
- 支持多種方式，如短信、郵件、IM和其他接口。具備可定製化功能，對第三方告警介質提供可編程接口。這一-點在很多場合非常重要，例如，將告警結果發送到專用的告警分析系統。
- 支持對告警內容的分析自動處理，防止誤報、漏報，以及防止抖動。這一點對大多數監控系統都是一個值得挑戰和研究的課題。例如，一個機房網絡發生故障，按照常規告警內容，會收到無數條告警信息，內容是每個設備的故障，而對於更高級的告警信息，我們希望收到的是“某機房存在網絡故障，受影響的設備的IP是X.X.X.X~ X.X.X.X， 受影響的業務是XXX."， 這樣做的目的是讓告警信息更智能、更有效，防止“告警炸彈”的產生。簡而言之，監控數據的採集、存儲、分析和故障報告是每個監控系統的基本功能，其他複雜的附加功能則是監控系統的增值業務。