国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

Prometheus監控的最佳實踐——關于監控的3項關鍵指標

tuantuan / 466人閱讀

摘要:本文將分享是為何以及如何開發出最佳實踐方法來使用在中監控應用程序的。什么是監控最近有很多關于的消息,尤其是在中監控應用程序這方面。方法遵循中提及的原則,聚焦于檢測最終用戶在使用服務時關心的東西。

本文來自Weaveworks的工程師Anita Burhrle在Rancher Labs與Weaveworks聯合舉辦的Online Meetup上的技術分享。在此次分享中,嘉賓們討論了如何使用Rancher、Weave Cloud和Prometheus來輕松部署、管理與監控Kubernetes。本文將分享Weave是為何以及如何開發出RED最佳實踐方法來使用Prometheus在Kubernetes中監控應用程序的。

什么是Prometheus監控?

最近有很多關于Prometheus的消息,尤其是在Kubernetes中監控應用程序這方面。深入RED方法之前,我們先了解一些背景內容。應用程序運行在容器上并由Kubernetes負責調度,在此環境中它們是高度自動化并且動態的。傳統的監控工具一般是基于服務器,只監控靜態的服務,所以當要在這種動態環境監控應用程序時,傳統的監控工具往往很難滿足這一需求。

這時就需要Prometheus出馬了。

Prometheus是一個開源項目,最初由SoundCloud的工程師開發。它專門用于監控那些運行在容器中的微服務。每經過一個時間間隔,數據都會從運行的服務中流出,存儲到一個時間序列數據庫中,這個數據庫之后可以通過PromQL語言查詢。另外,因為數據是以時間序列存儲的,當出現問題時,可以根據這些時間間隔進行診斷,另外還可以預測基礎設施的長期監控趨勢----這是Prometheus的兩大功能。

在Weaveworks,我們把服務搭建在Prometheus的開源分布上,并且創建了一個可擴展、多租戶的版本,這是我們軟件即服務概念的一部分,稱為Weave Cloud。

現在,該服務已經運行了幾個月,同時也使用Weave Cloud監控自己本身,在這個過程中我們積累到了一些有關監控云本機應用程序的經驗,并根據這些經驗設計了一個系統來確定在檢測代碼前需要測量什么。

該檢測什么?

在搭建Prometheus監控時,確定需要收集的指標類型十分重要,這些指標和應用程序相關。選擇的指標可以簡化故障發生時排除故障的流程,并且還可以在服務和基礎設施上保持很高的穩定性。為幫助理解instrument的重要性,我們定義了一個稱之為RED方法的系統。

RED方法遵循Four Golden Signals中提及的原則,聚焦于檢測最終用戶在使用web服務時關心的東西。

在RED方法中,我們通過監控三項關鍵指標來管理架構中的每個微服務:

(Request)Rate – 你的服務所服務的每秒的請求數

(Request)Errors – 每秒失敗的請求數

(Request)Duration – 每個請求所花費的時間,用時間間隔表示

RED方法希望由Rate、Errors、Duration三項指標涵蓋最典型的Web服務問題。同時這些指標還能夠反映出請求的錯誤率。通過這三項指標,我們就能監測到通常情況下會影響客戶體驗的問題。

如果想要獲得更細節的信息,還需要用到Saturation指標。Saturation指標用在USE(Utilization Saturation and Errors)方法中,它指的是一種帶有額外作業的資源,而該資源不能夠提供服務,因此必須添加到隊列中以備后續處理。

USE vs. RED方法

對比兩種方法,USE方法更側重于監控的性能,并以此為出發點尋找影響性能問題的根本原因以及其他系統的瓶頸。

在理想狀態下,我們可以在監控應用程序時同時使用USE和RED方法。

為什么要對每個服務衡量相同的指標

從監控的角度來看,如果能處理好每項服務,你的運營團隊就可以在此基礎上繼續擴展服務。

擴展性對運營團隊意味著什么?
我們從這個角度看待問題,一個團隊可以支持多少個服務。在理想狀態下,一個團隊可以支持的服務數量和團隊規模無關,而取決于其他因素,比如SLA協議的響應類型以及是否需要全天候覆蓋等等。

如何將可支持的服務數量與團隊規模去藕化?
辦法是讓每一個服務都變得一樣。這既減少了團隊針對特定的服務進行培訓的數量,還減少了在高壓事件響應場景或者所謂“認知負載”這些針對特定服務的特殊情況發生時,呼叫者需要記錄的內容。

容量規劃:
考慮QPS(每秒查詢次數)和延遲

自動化任務以及發出警報:
RED方法的優點在于它可以幫助你考慮如何在儀表板中顯示信息。通過這三個指標,你可以對儀表板的布局進行調整,讓它更易于閱讀,并在問題發生時發出警報。例如,一個布局可能意味著 --- 每個服務都有一個不同的Weave Cloud記事本,包含了PromQL查詢的請求&錯誤,以及每個服務的延遲。

毫無疑問,如果把所有的服務都視為一樣的,那么將會更加易于自動化執行重復任務。

PromQL查詢

在Weave Cloud上監控RED方法中的指標

局限性

事實上,這種方法(RED)僅適用于請求驅動的服務——比如,它在處理面向批處理的服務或者流服務時會發生錯誤。對于請求驅動它也不是完全適用,當需要監控其他東西——比如主機CPU&內存或者緩存資源時,USE方法表現的更好。

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/27060.html

相關文章

  • 容器監控實踐Prometheus基本架構

    摘要:根據配置文件,對接收到的警報進行處理,發出告警。在默認情況下,用戶只需要部署多套,采集相同的即可實現基本的。通過將監控與數據分離,能夠更好地進行彈性擴展。參考文檔本文為容器監控實踐系列文章,完整內容見 系統架構圖 1.x版本的Prometheus的架構圖為:showImg(https://segmentfault.com/img/remote/1460000018372350?w=14...

    gghyoo 評論0 收藏0
  • 容器監控實踐Prometheus基本架構

    摘要:根據配置文件,對接收到的警報進行處理,發出告警。在默認情況下,用戶只需要部署多套,采集相同的即可實現基本的。通過將監控與數據分離,能夠更好地進行彈性擴展。參考文檔本文為容器監控實踐系列文章,完整內容見 系統架構圖 1.x版本的Prometheus的架構圖為:showImg(https://segmentfault.com/img/remote/1460000018372350?w=14...

    elina 評論0 收藏0
  • 容器監控實踐—node-exporter

    摘要:比如定義了基礎的數據類型以及對應的方法收集事件次數等單調遞增的數據收集當前的狀態,比如數據庫連接數收集隨機正態分布數據,比如響應延遲收集隨機正態分布數據,和是類似的庫的詳細解析可以參考本文為容器監控實踐系列文章,完整內容見 概述 Prometheus從2016年加入CNCF,到2018年8月畢業,現在已經成為Kubernetes的官方監控方案,接下來的幾篇文章將詳細解讀Promethu...

    Pink 評論0 收藏0
  • 容器監控實踐—node-exporter

    摘要:比如定義了基礎的數據類型以及對應的方法收集事件次數等單調遞增的數據收集當前的狀態,比如數據庫連接數收集隨機正態分布數據,比如響應延遲收集隨機正態分布數據,和是類似的庫的詳細解析可以參考本文為容器監控實踐系列文章,完整內容見 概述 Prometheus從2016年加入CNCF,到2018年8月畢業,現在已經成為Kubernetes的官方監控方案,接下來的幾篇文章將詳細解讀Promethu...

    VPointer 評論0 收藏0
  • Kubernetes集群監控詳解

    摘要:儀表板是一個附加組件,它能提供集群上運行的資源的概述信息。可以很容易地創建圖形,并且把它們合并稱儀表板,而這些儀表板由一個強大的身份驗證和授權層保護,它們還可以和其他儀表板進行共享而不需要訪問服務器本身。 介 紹 Kubernetes在Github上擁有超過4萬顆星,7萬以上的commits,以及像Google這樣的主要貢獻者。Kubernetes可以說已經快速地接管了容器生態系統,成...

    A Loity 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<