關於相親原始碼的監控系統搭建，你瞭解多少？

為了保證相親原始碼的正常執行，在開發時我們需要實現一個監控系統，不過關於相親原始碼監控系統的搭建，有很多需要我們瞭解的內容，接下來將對監控體系的基礎知識、原理和架構做一次系統性整理。

01 必知必會的監控基礎知識

相親原始碼的監控系統俗稱「第三隻眼」，幾乎是我們每天都會打交道的系統，下面 4 項基礎知識我認為是必須要了解的。

1. 監控系統的7大作用

正所謂「無監控，不運維」，在相親原始碼開發中監控系統的地位不言而喻。不管你是監控系統的開發者還是使用者，首先肯定要清楚：監控系統的目標是什麼？它能發揮什麼作用？

• 實時採集監控資料：包括相親原始碼硬體、作業系統、中介軟體、應用程式等各個維度的資料。
• 實時反饋監控狀態：通過對相親原始碼採集的資料進行多維度統計和視覺化展示，能實時體現監控物件的狀態是正常還是異常。
• 預知故障和告警：能夠提前預知故障風險，並及時發出告警資訊。
• 輔助定位故障：提供故障發生時的各項指標資料，輔助故障分析和定位。
• 輔助效能調優：為相親原始碼效能調優提供資料支援，比如慢SQL，介面響應時間等。
• 輔助容量規劃：為伺服器、中介軟體以及應用叢集的容量規劃提供資料支撐。
• 輔助自動化運維：為相親原始碼自動擴容或者根據配置的SLA進行服務降級等智慧運維提供資料支撐。

2. 使用監控系統的正確姿勢

出任何線上事故，先不說其他地方有問題，監控部分一定是有問題的。

聽著很甩鍋的一句話，仔細思考好像有一定道理。我們在事故覆盤時，通常會思考這3個和監控有關的問題：相親原始碼有沒有做監控？監控是否及時？監控資訊是否有助於快速定位問題？

可見光有一套好的監控系統還不夠，還必須知道「如何用好它」。一個成熟的研發團隊通常會定一個監控規範，用來統一監控系統的使用方法。

• 瞭解監控物件的工作原理：要做到對監控物件有基本的瞭解，清楚它的工作原理。比如想對相親原始碼進行監控，你必須清楚相親原始碼的工作原理。
• 確定監控物件的指標：清楚使用哪些指標來刻畫監控物件的狀態？比如想對相親原始碼某個介面進行監控，可以採用請求量、耗時、超時量、異常量等指標來衡量。
• 定義合理的報警閾值和等級：達到什麼閾值需要告警？對應的故障等級是多少？不需要處理的告警不是好告警，可見定義合理的閾值有多重要，否則只會降低相親原始碼運維效率或者讓監控系統失去它的作用。
• 建立完善的故障處理流程：收到故障告警後，一定要有相應的處理流程和oncall機制，讓故障及時被跟進處理。

3.監控的物件和指標都有哪些？

監控已然成為了整個相親原始碼生命週期非常重要的一環，運維關注硬體和基礎監控，研發關注各類中介軟體和應用層的監控，相親原始碼關注核心業務指標的監控。可見，監控的物件已經越來越立體化。
這裡，我對常用的監控物件以及監控指標做了分類整理，供大家參考。

3.1 硬體監控

包括：電源狀態、CPU狀態、機器溫度、風扇狀態、物理磁碟、raid狀態、記憶體狀態、網路卡狀態

3.2 相親原始碼伺服器基礎監控

• CPU：單個CPU以及整體的使用情況
• 記憶體：已用記憶體、可用記憶體
• 磁碟：磁碟使用率、磁碟讀寫的吞吐量
• 網路：出口流量、入口流量、TCP連線狀態

3.3 相親原始碼資料庫監控

包括：資料庫連線數、QPS、TPS、並行處理的會話數、快取命中率、主從延時、鎖狀態、慢查詢

3.4 相親原始碼中介軟體監控

• Nginx：活躍連線數、等待連線數、丟棄連線數、請求量、耗時、5XX錯誤率
• Tomcat：最大執行緒數、當前執行緒數、請求量、耗時、錯誤量、堆記憶體使用情況、GC次數和耗時
• 快取 ：成功連線數、阻塞連線數、已使用記憶體、記憶體碎片率、請求量、耗時、快取命中率
• 訊息佇列：連線數、佇列數、生產速率、消費速率、訊息堆積量

3.5 應用監控

• HTTP介面：URL存活、請求量、耗時、異常量
• RPC介面：請求量、耗時、超時量、拒絕量
• JVM ：GC次數、GC耗時、各個記憶體區域的大小、當前執行緒數、死鎖執行緒數
• 執行緒池：活躍執行緒數、任務佇列大小、任務執行耗時、拒絕任務數
• 連線池：總連線數、活躍連線數
• 日誌監控：訪問日誌、錯誤日誌
• 業務指標：視業務來定，比如PV、訂單量等

4. 監控系統的基本流程

無論是開源的監控系統還是自研的監控系統，監控的整個流程大同小異，一般都包括以下模組：

• 資料採集：採集的方式有很多種，包括日誌埋點進行採集（通過Logstash、Filebeat等進行上報和解析），JMX標準介面輸出監控指標，被監控物件提供REST
  API進行資料採集（如Hadoop、ES），系統命令列，統一的SDK進行侵入式的埋點和上報等。
• 資料傳輸：將採集的相親原始碼資料以TCP、UDP或者HTTP協議的形式上報給監控系統，有主動Push模式，也有被動Pull模式。
• 資料儲存：有使用MySQL、Oracle等RDBMS儲存的，也有使用時序資料庫RRDTool、OpentTSDB、InfluxDB儲存的，還有使用HBase儲存的。
• 資料展示：資料指標的圖形化展示。
• 監控告警：靈活的告警設定，以及支援郵件、簡訊、IM等多種通知通道。

02監控系統的選型建議

面對選型問題，我的建議是：

1、先明確清楚相親原始碼監控需求：要監控的物件有哪些？機器數量和監控指標有多少？需要具備什麼樣的告警功能？

2、監控是一項長期建設的事情，一開始就想做一個 All In One 的監控解決方案，我覺得沒有必要。從成本角度考慮，在初期直接使用開源的監控方案即可，先解決有無問題。

3、從系統成熟度上看，老牌的監控系統，資料多，功能全面且穩定，如果機器數量在幾百臺以內，不用太擔心相親原始碼效能問題，另外，採用資料庫分割槽、SSD硬碟、Proxy架構、Push採集模式都可以提高監控效能。

4、在伺服器監控方面佔絕對優勢的監控系統，可以滿足相親原始碼90%以上的監控場景，但是應用層的監控似乎並不擅長，比如要監控執行緒池的狀態、某個內部介面的執行時間等，這種通常都要做侵入式埋點。相反，新一代的監控系統Open-Falcon和Prometheus在這一點做得很好。

5、從整體表現上來看，新一代監控系統也有明顯的優勢，比如：靈活的資料模型、更成熟的時序資料庫、強大的告警功能。

6、用合適的監控系統解決相親原始碼相應的問題即可，可以多套監控同時使用，這種在企業初期很常見。

7、到中後期，隨著相親原始碼機器資料增加和個性化需求增多，往需要二次開發或者通過監控系統提供的API做整合。

8、如果非要自研，可以多研究下主流監控系統的架構方案，借鑑它們的優勢。

03最後的話

本文對監控體系的基礎知識、原理和主流架構做了詳細梳理，希望有助於大家對監控系統的認識，以及在相親原始碼搭建監控系統進行技術選型時做出更合適的選擇。

本文轉載自網路，轉載僅為分享乾貨知識，如有侵權歡迎聯絡雲豹科技進行刪除處理
原文連結：