02-監控系統的淺析

前言：設計一個監控系統從哪入手呢？

前篇已經提到過監控系統的重要性，那麼一個較爲良好的監控系統應該從哪幾方面上手的呢？我我的理解能夠經過如下幾個方面入手：

• 評估業務類型，架構體系；
• 分類監控；
• 監控技術方案選型；
• 監控人員規劃；
• 監控系統的部署；
• 數據採集；
• 監控數據分析與算法；
• 系統測試；
• 自動化管理；
• 圖形化展現。

大體從以上幾點開始，下面咱們簡單來介紹上面所說。

一、評估業務類型與架構體系

當下各個企業的產品不一樣，業務方向不一樣，程序代碼不一樣，系統架構更不一樣，對於各個地方的細節都須要有必定程度的認知才能夠開啓設計的源頭。

好比，咱們以系統架構爲例，若是你是老牌服務 VS 微服務 我相信面向服務的監控體系必定會比面向主機監控更加順暢的多；又好比Python亦或者Java，更甚者PHP都有着不一樣的監控體系，因此這裏要根據自身狀況相結合進行合理的選擇。

二、分類監控

分類監控，咱們將須要的監控項進行整合分類便於後期管理實施的便捷性，那麼通常可分爲：業務級別監控、系統級別監控、網絡監控、程序代碼監控、日誌監控、用戶行爲分析監控、其餘種類監控。

舉例來如，以下：

• 業務監控： 包含 用戶訪問QPS, DAU日活, 訪問狀態, 業務接口等
• 系統監控： 主要是跟操做系統相關的 基本監控項 CPU/內存/硬盤/IO/TCP/帶寬 等
• 網絡監控： 對網絡狀態的監控，丟包率，延遲 等
• 日誌監控： 監控中的重頭戲，每每單獨設計和搭建，所有種類的日誌都有采集的需求；
• 程序監控： 通常須要和開發人員配合，程序中嵌入各類接口直接獲取數據；

三、監控技術的方案

目前各類監控軟件層出不窮，包括開源的、商業的、自行開發的等幾百種的可選方案；選取呢應該針對企業的架構特色，大小，種類，人員多少 等等 選取合適的技術方案，而不該該熟悉那個則上那個，那樣可能會給後期擴展升級帶來巨大的挑戰。

四、監控人員

運維團隊自身就應該將相關任務進行消化掉，同時劃分相關項目功能模塊，責任到人；中間難免須要開發團隊的配合，不少監控設計的工做，也須要尋求開發人員配合才能夠進行。

五、監控系統的部署

監控系統首選須要評估，存儲週期，高可用問題，以及多AZ（多機房，多可用區）問題，根據存在的這個問題咱們進行選擇部署形式。

六、數據採集

目前來講，數據採起形式多爲Agent採起；工具多爲一下幾種：

• Shell：最快速清亮，不帶有複雜邏輯的監控，最適合Get系統參數，或者搭載服務器上的應用參數；
• Python：運維人員的必備語言，模塊很是多適合不少的複雜邏輯，可是Agent部署過重；
• awk：Linux的文本處理工具，通常搭配Shell使用；
• lua：嵌入式監控首選，好比：OpenResty；
• Go：將來有晉升爲運維必回的另外一門高性能語言了，客戶端很是輕量，缺點：目前相關庫還不夠完善；
• 其餘：。。。。

數據採集通常分爲兩種形式：

• 頻率性採集：每隔多長時間獲取下對應監控項的數值；
• 持續性採集：多用於網絡監控，Log監控；

七、監控數據分析和算法

若是你不配置對數據的分析（有些分析須要算法的加持），那麼存放在哪裏的只是一堆沒用的數據；當咱們可以把數據轉化成爲監控公式與報警的閾值才能發揮出監控本該有的意義。

好比：CPU狀態，傳統監控多爲採用系統負載load來判斷系統繁忙狀態， 那你如何肯定是用戶態仍是系統態，以及更多的信息呢？ 假如咱們經過算法對CPU使用狀況統計5分鐘的增加比率超過0.8，同時持續了30分鐘呢？是否是比load更加能夠清晰呢。

八、監控穩定測試

無論採集形式如何，只要運行才Linux上，多會對系統有或多或少的影響，因此穩定性測試，就是經過一段時間的觀測，確保能平滑上線。

九、自動化管理

隨着業務量增大，機器、服務增多咱們就須要對監控值進行管理以及Agent的擴展等問題，自動化的由於會很大程度上縮短咱們對監控系統的維護成本。

我這裏推薦: Ansible，有興趣的小夥伴能夠了解下。

十、圖形化

想想酷炫的大屏；採集的數據和準備好的算法相結合，就能夠作出一個很是棒的圖形展現，好比：多數據源聚合展現，多源對比等等。

因此，監控成圖也是很重要的一個點。

小結

上面扯了一堆，其實咱們須要結合自身實際狀況以及將來的發展趨勢來作設計便可。