以前，我寫過幾篇有關「線上問題排查」的文章，文中附帶了一些監控圖，有些讀者對此很感興趣，問我監控系統選型上有沒有好的建議？前端
目前我所經歷的幾家公司，監控系統都是自研的。其實業界有不少優秀的開源產品可供選擇，能知足絕大部分的監控需求，若是能從中選擇一款知足企業當下的訴求，顯然最省時省力。數據庫
這篇文章，我將對監控體系的基礎知識、原理和架構作一次系統性整理，同時還會對幾款最經常使用的開源監控產品作下介紹，以便你們選型時參考。內容包括3部分。緩存
必知必會的監控基礎知識安全
監控系統俗稱「第三隻眼」，幾乎是咱們天天都會打交道的系統，下面 4 項基礎知識我認爲是必需要了解的。服務器
監控系統的7大做用網絡
正所謂「無監控，不運維」，監控系統的地位不言而喻。無論你是監控系統的開發者仍是使用者，首先確定要清楚：監控系統的目標是什麼？它能發揮什麼做用？架構
實時採集監控數據：包括硬件、操做系統、中間件、應用程序等各個維度的數據。併發
實時反饋監控狀態：經過對採集的數據進行多維度統計和可視化展現，能實時體現監控對象的狀態是正常仍是異常。運維
預知故障和告警：可以提早預知故障風險，並及時發出告警信息。分佈式
輔助定位故障：提供故障發生時的各項指標數據，輔助故障分析和定位。
輔助性能調優：爲性能調優提供數據支持，好比慢SQL，接口響應時間等。
輔助容量規劃：爲服務器、中間件以及應用集羣的容量規劃提供數據支撐。
輔助自動化運維：爲自動擴容或者根據配置的SLA進行服務降級等智能運維提供數據支撐。
使用監控系統的正確姿式
出任何線上事故，先不說其餘地方有問題，監控部分必定是有問題的。
聽着很甩鍋的一句話，仔細思考好像有必定道理。咱們在事故覆盤時，一般會思考這3個和監控有關的問題：有沒有作監控？監控是否及時？監控信息是否有助於快速定位問題？
可見光有一套好的監控系統還不夠，還必須知道「如何用好它」。一個成熟的研發團隊一般會定一個監控規範，用來統一監控系統的使用方法。
瞭解監控對象的工做原理：要作到對監控對象有基本的瞭解，清楚它的工做原理。好比想對JVM進行監控，你必須清楚JVM的堆內存結構和垃圾回收機制。
肯定監控對象的指標：清楚使用哪些指標來刻畫監控對象的狀態？好比想對某個接口進行監控，能夠採用請求量、耗時、超時量、異常量等指標來衡量。
定義合理的報警閾值和等級：達到什麼閾值須要告警？對應的故障等級是多少？不須要處理的告警不是好告警，可見定義合理的閾值有多重要，不然只會下降運維效率或者讓監控系統失去它的做用。
創建完善的故障處理流程：收到故障告警後，必定要有相應的處理流程和oncall機制，讓故障及時被跟進處理。
監控的對象和指標都有哪些？
監控已然成爲了整個產品生命週期很是重要的一環，運維關注硬件和基礎監控，研發關注各種中間件和應用層的監控，產品關注核心業務指標的監控。可見，監控的對象已經愈來愈立體化。
這裏，我對經常使用的監控對象以及監控指標作了分類整理，供你們參考。
硬件監控
包括：電源狀態、CPU狀態、機器溫度、風扇狀態、物理磁盤、raid狀態、內存狀態、網卡狀態
服務器基礎監控
CPU：單個CPU以及總體的使用狀況
內存：已用內存、可用內存
磁盤：磁盤使用率、磁盤讀寫的吞吐量
網絡：出口流量、入口流量、TCP鏈接狀態
數據庫監控
包括：數據庫鏈接數、QPS、TPS、並行處理的會話數、緩存命中率、主從延時、鎖狀態、慢查詢
中間件監控
Nginx：活躍鏈接數、等待鏈接數、丟棄鏈接數、請求量、耗時、5XX錯誤率
Tomcat：最大線程數、當前線程數、請求量、耗時、錯誤量、堆內存使用狀況、GC次數和耗時
緩存 ：成功鏈接數、阻塞鏈接數、已使用內存、內存碎片率、請求量、耗時、緩存命中率
消息隊列：鏈接數、隊列數、生產速率、消費速率、消息堆積量
應用監控
HTTP接口：URL存活、請求量、耗時、異常量
RPC接口：請求量、耗時、超時量、拒絕量
JVM ：GC次數、GC耗時、各個內存區域的大小、當前線程數、死鎖線程數
線程池：活躍線程數、任務隊列大小、任務執行耗時、拒絕任務數
鏈接池：總鏈接數、活躍鏈接數
日誌監控：訪問日誌、錯誤日誌
業務指標：視業務來定，好比PV、訂單量等
監控系統的基本流程
不管是開源的監控系統仍是自研的監控系統，監控的整個流程大同小異，通常都包括如下模塊：
數據採集：採集的方式有不少種，包括日誌埋點進行採集（經過Logstash、Filebeat等進行上報和解析），JMX標準接口輸出監控指標，被監控對象提供REST API進行數據採集（如Hadoop、ES），系統命令行，統一的SDK進行侵入式的埋點和上報等。
數據傳輸：將採集的數據以TCP、UDP或者HTTP協議的形式上報給監控系統，有主動Push模式，也有被動Pull模式。
數據存儲：有使用MySQL、Oracle等RDBMS存儲的，也有使用時序數據庫RRDTool、OpentTSDB、InfluxDB存儲的，還有使用HBase存儲的。
數據展現：數據指標的圖形化展現。
監控告警：靈活的告警設置，以及支持郵件、短信、IM等多種通知通道。
主流監控系統介紹
下面再來認識下主流的開源監控系統，因爲篇幅有限，我挑選了3款使用最普遍的監控系統：Zabbix、Open-Falcon、Prometheus，會對它們的架構進行介紹，同時總結下各自的優劣勢。
Zabbix（老牌監控的優秀表明）
Zabbix 1998年誕生，核心組件採用C語言開發，Web端採用PHP開發。它屬於老牌監控系統中的優秀表明，監控功能很全面，使用也很普遍，差很少有70%左右的互聯網公司都曾使用過 Zabbix 做爲監控解決方案。
先來了解下Zabbix的架構設計：
Zabbix架構圖
Zabbix Server：核心組件，C語言編寫，負責接收Agent、Proxy發送的監控數據，也支持JMX、SNMP等多種協議直接採集數據。同時，它還負責數據的彙總存儲以及告警觸發等。
Zabbix Proxy：可選組件，對於被監控機器較多的狀況下，可以使用Proxy進行分佈式監控，它能代理Server收集部分監控數據，以減輕Server的壓力。
Zabbix Agentd：部署在被監控主機上，用於採集本機的數據併發送給Proxy或者Server，它的插件機制支持用戶自定義數據採集腳本。Agent可在Server端手動配置，也能夠經過自動發現機制被識別。數據收集方式同時支持主動Push和被動Pull 兩種模式。
Database：用於存儲配置信息以及採集到的數據，支持MySQL、Oracle等關係型數據庫。同時，最新版本的Zabbix已經開始支持時序數據庫，不過成熟度還不高。
Web Server：Zabbix的GUI組件，PHP編寫，提供監控數據的展示和告警配置。
下面是Zabbix的優點：
產品成熟：因爲誕生時間長且使用普遍，擁有豐富的文檔資料以及各類開源的數據採集插件，能覆蓋絕大部分監控場景。
採集方式豐富：支持Agent、SNMP、JMX、SSH等多種採集方式，以及主動和被動的數據傳輸方式。
較強的擴展性：支持Proxy分佈式監控，有agent自動發現功能，插件式架構支持用戶自定義數據採集腳本。
配置管理方便：能經過Web界面進行監控和告警配置，操做方便，上手簡單。
下面是 Zabbix 的劣勢：
性能瓶頸：機器量或者業務量大了後，關係型數據庫的寫入必定是瓶頸，官方給出的單機上限是5000臺，我的感受達不到，尤爲如今應用層的指標愈來愈多。雖然最新版已經開始支持時序數據庫，不過成熟度還不高。
應用層監控支持有限：若是想對應用程序作侵入式的埋點和採集（好比監控線程池或者接口性能），Zabbix沒有提供對應的SDK，經過插件式的腳本也能曲線實現此功能，我的感受Zabbix就不是作這個事的。
數據模型不強大：不支持tag，所以無法按多維度進行聚合統計和告警配置，使用起來不靈活。
方便二次開發難度大：Zabbix採用的是C語言，二次開發每每須要熟悉它的數據表結構，基於它提供的API更多隻能作展現層的定製。
Open-Falcon（小米出品，國內流行）
Open-Falcon是小米2015年開源的企業級監控工具，採用Go和Python語言開發，這是一款靈活、高性能且易擴展的新一代監控方案，目前小米、美團、滴滴等超過200家公司在使用它。
小米初期也使用的Zabbix進行監控，可是機器量和業務量上來後，Zabbix就有些力不從心了。所以，後來自主研發了Open-Falcon，在架構設計上吸收了Zabbix的經驗，同時很好地解決了Zabbix的諸多痛點。
先來了解下Open-Falcon的架構設計：
Open-Falcon架構圖，來自網絡
Falcon-agent：數據採集器和收集器，Go開發，部署在被監控的機器上，支持3種數據採集方式。首先它能自動採集單機200多個基礎監控指標，無需作任何配置；同時支持用戶自定義的plugin獲取監控數據；此外，用戶可經過http接口，自主push數據到本機的proxy-gateway，由gateway轉發到server。
Transfer：數據分發組件，接收客戶端發送的數據，分別發送給數據存儲組件Graph和告警斷定組件Judge，Graph和Judge均採用一致性hash作數據分片，以提升橫向擴展能力。同時Transfer還支持將數據分發到OpenTSDB，用於歷史歸檔。
Graph：數據存儲組件，底層使用RRDTool（時序數據庫）作單個指標的存儲，並經過緩存、分批寫入磁盤等方式進行了優化。聽說一個Graph實例可以處理8W+每秒的寫入速率。
Judge和Alarm：告警組件，Judge對Transfer組件上報的數據進行實時計算，判斷是否要產生告警事件，Alarm組件對告警事件進行收斂處理後，將告警消息推送給各個消息通道。
API：面向終端用戶，收到查詢請求後會去Graph中查詢指標數據，彙總結果後統一返回給用戶，屏蔽了存儲集羣的分片細節。
下面是Open-Falcon的優點：
自動採集能力：Falcon-agent 能自動採集服務器的200多個基礎指標（好比CPU、內存等），無需在server上作任何配置，這一點能夠秒殺Zabbix.
強大的存儲能力：底層採用RRDTool，而且經過一致性hash進行數據分片，構建了一個分佈式的時序數據存儲系統，可擴展性強。
靈活的數據模型：借鑑OpenTSDB，數據模型中引入了tag，這樣能支持多維度的聚合統計以及告警規則設置，大大提升了使用效率。
插件統一管理：Open-Falcon的插件機制實現了對用戶自定義腳本的統一化管理，可經過HeartBeat Server分發給agent，減輕了使用者自主維護腳本的成本。
個性化監控支持：基於Proxy-gateway，很容易經過自主埋點實現應用層的監控（好比監控接口的訪問量和耗時）和其餘個性化監控需求，集成方便。
下面是Open-Falcon的劣勢：
總體發展通常：社區活躍度不算高，同時版本更新慢，有些大廠是基於它的穩定版本直接作二次開發的，關於之後的前景其實有點擔心。
UI不夠友好：對於業務線的研發來講，可能只想便捷地完成告警配置和業務監控，可是它把機器分組、策略模板、模板繼承等概念所有暴露在UI上，感受在圍繞這幾個概念設計UI，理解有點費勁。
安裝比較複雜：我的的親身感覺，因爲它是從小米內部衍生出來的，雖然去掉了對小米內部系統的依賴，可是組件仍是比較多，若是對整個架構不熟悉，安裝很難一蹴而就。
Prometheus（號稱下一代監控系統）
Prometheus（普羅米修斯）是由前Google員工2015年正式發佈的開源監控系統，採用Go語言開發。它不只有一個很酷的名字，同時它有Google與Kubernetes的強力支持，開源社區異常火爆。
Prometheus 2016年加入雲原生基金會，是繼Kubernetes後託管的第二個項目，將來前景被至關看好。它和Open-Falcon最大不一樣在於：數據採集是基於Pull模式的，而不是Push模式，而且架構很是簡單。
先來了解下Prometheus的架構設計：
Prometheus架構圖，來自網絡
Prometheus Server：核心組件，用於收集、存儲監控數據。它同時支持靜態配置和經過Service Discovery動態發現來管理監控目標，並從監控目標中獲取數據。此外，Prometheus Server也是一個時序數據庫，它將監控數據保存在本地磁盤中，並對外提供自定義的PromQL語言實現對數據的查詢和分析。
Exporter：用來採集數據，做用相似於agent，區別在於Prometheus是基於Pull方式拉取採集數據的，所以，Exporter經過HTTP服務的形式將監控數據按照標準格式暴露給Prometheus Server，社區中已經有大量現成的Exporter能夠直接使用，用戶也可使用各類語言的client library自定義實現。
Push gateway：主要用於瞬時任務的場景，防止Prometheus Server來pull數據以前此類Short-lived jobs就已經執行完畢了，所以job能夠採用push的方式將監控數據主動彙報給Push gateway緩存起來進行中轉。
Alert Manager：當告警產生時，Prometheus Server將告警信息推送給Alert Manager，由它發送告警信息給接收方。
Web UI：Prometheus內置了一個簡單的Web控制檯，能夠查詢配置信息和指標等，而實際應用中咱們一般會將Prometheus做爲Grafana的數據源，建立儀表盤以及查看指標。
下面是Prometheus的優點：
輕量管理：架構簡單，不依賴外部存儲，單個服務器節點可直接工做，二進制文件啓動便可，屬於輕量級的Server，便於遷移和維護。
較強的處理能力：監控數據直接存儲在Prometheus Server本地的時序數據庫中，單個實例能夠處理數百萬的metrics。
靈活的數據模型：同Open-Falcon，引入了tag，屬於多維數據模型，聚合統計更方便。
強大的查詢語句：PromQL容許在同一個查詢語句中，對多個Metrics進行加法、鏈接和取分位值等操做。
很好地支持雲環境：能自動發現容器，同時Kubernetes和etcd等項目都提供了對Prometheus的原生支持，是目前容器監控最流行的方案。
下面是Prometheus的劣勢：
功能不夠完善：Prometheus從一開始的架構設計就是要作到簡單，不提供集羣化方案，長期的持久化存儲和用戶管理，而這些是企業變大後所必須的特性，目前要作到這些只能在Prometheus之上進行擴展。
網絡規劃變複雜：因爲Prometheus採用的是Pull模型拉取數據，意味着全部被監控的endpoint必須是可達的，須要合理規劃網絡的安全配置。
監控系統的選型建議
經過上面的介紹，你們對主流的監控系統應該有了必定的認識。面對選型問題，個人建議是：
先明確清楚你的監控需求：要監控的對象有哪些？機器數量和監控指標有多少？須要具有什麼樣的告警功能？
監控是一項長期建設的事情，一開始就想作一個 All In One 的監控解決方案，我以爲沒有必要。從成本角度考慮，在初期直接使用開源的監控方案便可，先解決有無問題。
從系統成熟度上看，Zabbix屬於老牌的監控系統，資料多，功能全面且穩定，若是機器數量在幾百臺之內，不用太擔憂性能問題，另外，採用數據庫分區、SSD硬盤、Proxy架構、Push採集模式均可以提升監控性能。
Zabbix在服務器監控方面佔絕對優點，能夠知足90%以上的監控場景，可是應用層的監控彷佛並不擅長，好比要監控線程池的狀態、某個內部接口的執行時間等，這種一般都要作侵入式埋點。相反，新一代的監控系統Open-Falcon和Prometheus在這一點作得很好。
從總體表現上來看，新一代監控系統也有明顯的優點，好比：靈活的數據模型、更成熟的時序數據庫、強大的告警功能，若是以前對Zabbix這種傳統監控沒有技術積累，建議使用Open-Falcon或者Prometheus。
Open-Falcon的核心優點在於數據分片功能，能支撐更多的機器和監控項；Prometheus則是容器監控方面的標配，有Google和Kubernetes加持。
Zabbix、Open-Falcon和Prometheus都支持和Grafana作快速集成，想要美觀且強大的可視化體驗，能夠和Grafana進行組合。
用合適的監控系統解決相應的問題便可，能夠多套監控同時使用，這種在企業初期很常見。
到中後期，隨着機器數據增長和個性化需求增多（好比但願統一監控平臺、打通公司的CMDB和組織架構關係），每每須要二次開發或者經過監控系統提供的API作集成，從這點來看，Open-Falcon或者Prometheus更合適。
若是非要自研，能夠多研究下主流監控系統的架構方案，借鑑它們的優點。
最後的話
本文對監控體系的基礎知識、原理和主流架構作了詳細梳理，但願有助於你們對監控系統的認識，以及在技術選型時作出更合適的選擇。
因爲篇幅問題，本文的內容並未涉及到全鏈路監控、日誌監控、以及Web前端和客戶端的監控，可見監控真的是一個龐大且複雜的體系，若是想理解透徹，必須理論結合實踐再作深刻。
對於運維監控體系，若是大家也有本身的經驗和體會，歡迎留言討論。
文章來源：IT人的職場進階，點擊查看原文。
Kubernetes管理員認證（CKA）培訓
本次CKA培訓課程，基於最新考綱，經過線下授課、考題解讀、模擬演練等方式，幫助學員快速掌握Kubernetes的理論知識和專業技能，並針對考試作特別強化訓練，讓學員能從容面對CKA認證考試，使學員既能掌握Kubernetes相關知識，又能經過CKA認證考試，學員可屢次參加培訓，直到經過認證。點擊下方圖片或者閱讀原文連接查看詳情。