天天看點

Prometheus監控(4)

Prometheus監控(4)

資料監控是及時、有效的回報出資料異常的一種手段,通過對資料的監控去觀察是否異常,進而分析資料。

資料分析是以業務場景和業務目标為思考起點,業務決策作為終點,按照業務場景和業務目标分解為若幹影響的因子和子項目,圍繞子項目做基于資料現狀分析,知道改善現狀的方法。

例如:采集CPU 的七種 等待狀态參數 , 采集⽤戶每秒通路請求量 QPS

對于這些"基本機關"的資料采集 本⾝是必須的 也是沒有疑問的。

但是這⾥有⼀個問題

采集回來的機關資料 如果沒有懂⾏的⼈ 将它們形成 監控公式 和 報警門檻值。

那采集資料就沒有任何意義了。

Prometheus監控(4)

cpu監控

關于CPU,有3個重要的概念:上下文切換(context switchs),運作隊列(Run queue)和使用率(utilization)。

  • 上下文切換:

  目前流行的CPU在同一時間内隻能運作一個線程,超線程的處理器可以在同一時間運作多個線程(包括多核CPU),Linux核心會把多核的處理器當作多個單獨的CPU來識别。

     一個标準的Linux核心何以支援運作50~50000個程序運作,對于普通的CPU,核心會排程和執行這些程序。每個程序都會分到CPU的時間片來運作,當一個程序用完時間片或者被更高優先級的程序搶占後,它會備份到CPU的運作隊列中,同時其他程序在CPU上運作。這個程序切換的過程被稱作上下文切換。過多的上下文切換

會造成系統很大的開銷。

  

  • 運作隊列:

  每個CPU都會維持一個運作隊列,理想情況下,排程器會不斷讓隊列中的程序運作。程序不是處在sleep狀态就是run able狀态。如果CPU過載,就會出現排程器跟不上系統的要求,導緻可運作的程序會填滿隊列。隊列愈大,程式執行時間就愈長。“load”用來表示運作隊列,用top 指令我們可以看到CPU一分鐘,5分鐘和15分鐘内的運作隊列的大小。這個值越大表明系統負荷越大。

  

  • CPU使用率:

   CPU使用率可分為一下幾個部分

   User Time—執行使用者程序的時間百分比;

   System Time—執行核心程序和中斷的時間百分比;

   Wait IO—因為IO等待而使CPU處于idle狀态的時間百分比;

   Idle—CPU處于Idle狀态的時間百分比。

top指令

TOP是一個動态顯示過程,即可以通過使用者按鍵來不斷重新整理目前狀态.如果在前台執行該指令,它将獨占前台,直到使用者終止該程式為止.比較準确的說,top指令提供了實時的對系統處理器的狀态監視.它将顯示系統中CPU最“敏感”的任務清單.該指令可以按CPU使用.記憶體使用和執行時間對任務進行排序;而且該指令的很多特性都可以通過互動式指令或者在個人定制檔案中進行設定。

Prometheus監控(4)

CPU采集回來的 平均負載數值,以及CPU的時間⽚分布百分⽐ nagios top

如果作為⼀個運維架構師 不懂得 Linux中CPU各種參數的深⼊原理

例如 平均負載是如何計算的, CPU的時間⽚分布是如何分類的,什麼叫作 ⽤戶态/核心态 CPU等待/處理時間 什麼是 Interuptable/uniteruptable CPU等待等等這些概念。那麼即便資料被采集回來的再精細準确 你也利⽤不好。

如果 我們使⽤那種⽼式的傻⽠式的監控 如nagios , ⾥⾯的監控腳本很全⾯(shell sh return, bin),⽣成報警規則 和 門檻值也很簡單,缺點卻顯⽽易見:監控的太粗糙 實⽤性不強。

例如業務級别監控的算法 運維⾃⾝⽆法做到⼗分專業。

因為本⾝跟作業系統⽆關,是跟資料算法相關。

舉個例⼦:如果我想通過Prometheus實作對⽤戶通路QPS的 精确監控。

那麼對于 監控圖形 曲線 QPS上漲 QPS下跌, QPS凸起, QPS和曆史資料的⽐較⽅法 等等這些都屬于業務級别的監控門檻值類型。

需要有專業的資料分析⼈員的協助 才可以算出優良的算法。

例如:如果我現在想針對目前QPS下跌率進⾏報警計算, 那麼⽤什麼養的公式針對我們的業務類型更貼切?

是選擇計算目前5分鐘内的平均值 當 < ⼀個固定數值的時候 報警合适?

是選擇 計算目前10分鐘的總量 然後和 前⼀個⼩時同⼀時段⽐較合适?

是選擇 計算目前⼀⼩時的平均值 和 過去⼀周内 每⼀天的同⼀時段的時間⽐較合适?

依此類推,這些資料算法 本⾝跟Linux⽆關,隻有⾮常專業的 資料計算團隊 才可以給出⼀個最合理的算法 協助我們的報警規則。

監控自動化

監控用戶端的批量部署,監控服務端的HA再安裝,監控項⽬的修改,監控項⽬的監控叢集變化。

Prometheus監控(4)

⾃動化的引進 會很⼤程度上 縮短我們對監控系統的維護成本。

這⾥給出⼏個執行個體:Puppet(配置⽂件部署), Jenkins(CI 持續內建部署) , CMDB(運維⾃動化的最⾼資源管理平台 和 理念 )。。。。等等。

監控圖形化⼯作

采集的資料 和 準備好的監控算法,最終需要⼀個好的圖形展⽰才能發揮最好的作⽤。

監控的設計搭建需要⼤量的技術知識,但是對于⼀個觀察者來說(⽼闆),往往不需要多少技術,隻要能看懂圖就好(例如 ⽼闆想看看 目前⽤戶通路量狀況,想看看 整體CPU⾼不⾼ 等等)。

自動圖表化:可以從資料背景刷選出我們想要看的資料,并且每個版塊都制成圖表,便于我們快速檢視。舉例:把使用者每個觸發行為都加上埋點,按時間次元去查詢我們想要的資料。

Prometheus監控(4)

手動圖表化

最常用的有以下幾種圖表:

(1)柱狀圖

柱狀圖通常描述的是分類資料,用于顯示一段時間内的資料變化或顯示各項之間的比較情況。

Prometheus監控(4)

(2)折線圖

折線圖可以顯示随時間(根據常用比例設定)而變化的連續資料。

Prometheus監控(4)

(3)餅圖

餅圖以二維或三維格式顯示每一數值相對于總數值的大小。

Prometheus監控(4)

(4)條形圖

條形圖顯示各個項目之間的比較情況。

Prometheus監控(4)

(5)散點圖

散點圖也叫 X-Y 圖,它将所有的資料以點的形式展現在直角坐标系上,以顯示變量之間的互相影響程度,點的位置由變量的數值決定。

Prometheus監控(4)

(6)漏鬥圖

漏鬥圖适用于業務流程比較規範、周期長、環節多的單流程單向分析,通過漏鬥各環節業務資料的比較,能夠直覺地發現和說明問題所在,為決策者提供一定的參考。

Prometheus監控(4)

(7)面積圖

面積圖又叫區域圖,面積圖強調數量随時間而變化的程度, 它是在折線圖的基礎之上形成的, 它将折線圖中折線與自變量坐标軸之間的區域使用顔色或者紋理填充,顔色的填充可以更好的突出趨勢資訊。

Prometheus監控(4)

以上7種圖表都是在分析資料中經常使用的,可以根據分析資料的展示去選擇不同的圖表。

資料監控和資料分析對于營運來說是非常重要的,做好資料監控,減少産品出現bug,影響使用者的體驗,減少重大事故的發生。

Prometheus監控(1)

三豐,公衆号:soft張三豐Prometheus監控(1)

Prometheus監控(2)

三豐,公衆号:soft張三豐Prometheus監控(2)

Prometheus監控(3)

三豐,公衆号:soft張三豐Prometheus監控(3)

微服務核心之服務編排

三豐,公衆号:soft張三豐服務編排

一文看懂service mesh

三豐,公衆号:soft張三豐一文看懂service mesh