目錄4. 監控系統的基本流程
主流監控系統介紹
監控系統的選型建議
最後的話
很多公司的監控系統都是自研的。
其實業界有很多優秀的開源產品可供選擇，能滿足絕大部分的監控需求，如果能從中選擇一款滿足企業當下的訴求，顯然最省時省力。
監控系統俗稱「第三隻眼」，幾乎是我們每天都會打交道的系統，下面 4 項基礎知識我認為是必須要了解的。
正所謂「無監控，不運維」，監控系統的地位不言而喻。不管你是監控系統的開發者還是使用者，首先肯定要清楚：監控系統的目標是什麼？它能發揮什麼作用？
實時採集監控資料：包括硬體、作業系統、中介軟體、應用程式等各個維度的資料。
實時反饋監控狀態：通過對採集的資料進行多維度統計和視覺化展示，能實時體現監控物件的狀態是正常還是異常。
預知故障和告警：能夠提前預知故障風險，並及時發出告警資訊。
輔助定位故障：提供故障發生時的各項指標資料，輔助故障分析和定位。
輔助效能調優：為效能調優提供資料支援，比如慢sql，介面響應時間等。
輔助容量規劃：為伺服器、中介軟體以及應用集群的容量規劃提供資料支撐。
輔助自動化運維：為自動擴容或者根據配置的sla進行服務降級等智慧型運維提供資料支撐。
出任何線上事故，先不說其他地方有問題，監控部分一定是有問題的。聽著很甩鍋的一句話，仔細思考好像有一定道理。我們在事故覆盤時，通常會思考這3個和監控有關的問題：有沒有做監控？監控是否及時？監控資訊是否有助於快速定位問題？
可見光有一套好的監控系統還不夠，還必須知道「如何用好它」。乙個成熟的研發團隊通常會定乙個監控規範，用來統一監控系統的使用方法。
如何使用監控系統:
了解監控物件的工作原理：要做到對監控物件有基本的了解，清楚它的工作原理。比如想對jvm進行監控，你必須清楚jvm的堆記憶體結構和垃圾**機制。
確定監控物件的指標：清楚使用哪些指標來刻畫監控物件的狀態？比如想對某個介面進行監控，可以採用請求量、耗時、超時量、異常量等指標來衡量。
定義合理的報警閾值和等級：達到什麼閾值需要告警？對應的故障等級是多少？不需要處理的告警不是好告警，可見定義合理的閾值有多重要，否則只會降低運維效率或者讓監控系統失去它的作用。
建立完善的故障處理流程：收到故障告警後，一定要有相應的處理流程和oncall機制，讓故障及時被跟進處理。
包括：電源狀態、cpu狀態、機器溫度、風扇狀態、物理磁碟、raid狀態、記憶體狀態、網絡卡狀態
包括：資料庫連線數、qps、tps、並行處理的會話數、快取命中率、主從延時、鎖狀態、慢查詢
無論是開源的監控系統還是自研的監控系統，監控的整個流程大同小異，一般都包括以下模組：
資料採集：採集的方式有很多種，包括日誌埋點進行採集（通過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 2023年誕生，核心元件採用c語言開發，web端採用php開發。它屬於老牌監控系統中的優秀代表，監控功能很全面，使用也很廣泛，差不多有70%左右的網際網路公司都曾使用過 zabbix 作為監控解決方案。
先來了解下zabbix的架構設計：
下面是 zabbix 的優勢：
下面是 zabbix 的劣勢：
open-falcon 是小公尺2023年開源的企業級監控工具，採用go和python語言開發，這是一款靈活、高效能且易擴充套件的新一代監控方案，目前小公尺、美團、滴滴等超過200家公司在使用它。
小公尺初期也使用的zabbix進行監控，但是機器量和業務量上來後，zabbix就有些力不從心了。因此，後來自主研發了open-falcon，在架構設計上吸取了zabbix的經驗，同時很好地解決了zabbix的諸多痛點。
先來了解下open-falcon的架構設計：
下面是open-falcon的優勢：
下面是open-falcon的劣勢：
prometheus（普羅公尺修斯）是由前google員工2023年正式發布的開源監控系統，採用go語言開發。它不僅有乙個很酷的名字，同時它有google與k8s的強力支援，開源社群異常火爆。
prometheus 2023年加入雲原生**會，是繼k8s後託管的第二個專案，未來前景被相當看好。它和open-falcon最大不同在於：資料採集是基於pull模式的，而不是push模式，並且架構非常簡單。
先來了解下prometheus的架構設計：
下面是prometheus的優勢：
下面是prometheus的劣勢：
先明確清楚你的監控需求：要監控的物件有哪些？機器數量和監控指標有多少？需要具備什麼樣的告警功能？
監控是一項長期建設的事情，一開始就想做乙個 all in one 的監控解決方案，我覺得沒有必要。從成本角度考慮，在初期直接使用開源的監控方案即可，先解決有無問題。
從系統成熟度上看，zabbix屬於老牌的監控系統，資料多，功能全面且穩定，如果機器數量在幾百台以內，不用太擔心效能問題，另外，採用資料庫分割槽、ssd硬碟、proxy架構、push採集模式都可以提高監控效能。
zabbix在伺服器監控方面佔絕對優勢，可以滿足90%以上的監控場景，但是應用層的監控似乎並不擅長，比如要監控執行緒池的狀態、某個內部介面的執行時間等，這種通常都要做侵入式埋點。相反，新一代的監控系統open-falcon和prometheus在這一點做得很好。
從整體表現上來看，新一代監控系統也有明顯的優勢，比如：靈活的資料模型、更成熟的時序資料庫、強大的告警功能，如果之前對zabbix這種傳統監控沒有技術積累，建議使用open-falcon或者prometheus.
open-falcon的核心優勢在於資料分片功能，能支撐更多的機器和監控項；prometheus則是容器監控方面的標配，有google和k8s加持。
zabbix、open-falcon和prometheus都支援和grafana做快速整合，想要美觀且強大的視覺化體驗，可以和grafana進行組合。
用合適的監控系統解決相應的問題即可，可以多套監控同時使用，這種在企業初期很常見。
到中後期，隨著機器資料增加和個性化需求增多（比如希望統一監控平台、打通公司的cmdb和組織架構關係），往往需要二次開發或者通過監控系統提供的api做整合，從這點來看，open-falcon或者prometheus更合適。
如果非要自研，可以多研究下主流監控系統的架構方案，借鑑它們的優勢。
由於篇幅問題，本文的內容並未涉及到全鏈路監控、日誌監控、以及web前端和客戶端的監控，可見監控真的是乙個龐大且複雜的體系，如果想理解透徹，必須理論結合實踐再做深入。
監控系統選型，這篇不可不讀！
目前我所經歷的幾家公司，監控系統都是自研的。其實業界有很多優秀的開源產品可供選擇，能滿足絕大部分的監控需求，如果能從中選擇一款滿足企業當下的訴求，顯然最省時省力。監控系統俗稱 第三隻眼 幾乎是我們每天都會打交道的系統，下面 4 項基礎知識我認為是必須要了解的。正所謂 無監控，不運維 監控系統的地位不...
OA系統選型為何要審慎？
oa系統的選型必須要審慎。很多使用者因為自身經驗不足，所以常在選型時受到 和產品表面功能的影響，進而選擇了一款較差的oa系統，以致於使所購買的oa系統成了花架子。故而，oa系統的選型要考慮核心層面。其中，oa系統的敏捷性就是極為重要的乙個核心層面。為什麼這樣說呢？1 不同使用者的管理需求不同 使用者...
監控系統技術選型
對比專案 prometheus open falcon zabbix 響應時間快快 快圖表tt t趨勢tt t趨勢 ff f自動發現tt tagenttt tagentlessff tsnmptt t外部指令碼ft t外掛程式tt t外掛程式建立 一般簡單 簡單告警tt tweb應用 部分控制 全部...