有方法論提導，在技戰術方面纔不會偏離目錄。html
使用服務級別做爲關鍵語，召示着承諾和責任。框架
https://www.circonus.com/2018/06/comprehensive-container-based-service-monitoring-with-kubernetes-and-istio/工具
服務級別目標
這個服務級別目標的簡要概述將爲咱們如何衡量咱們的服務健康情況奠基基礎。服務級別協議（SLA）的概念已經存在了至少十年。但就在最近，與服務級別目標（SLO）和服務級別指標（SLI）相關的在線內容數量迅速增長。url
除了著名的 Google SRE書之外，兩本關於 SLO 的新書即將發佈。「站點可靠性工做手冊」有關於 SLO 的專門章節，Seeking SRE 有關於由 Circonus 創始人兼首席執行官 Theo Schlossnagle 定義 SLO 目標的章節。咱們還建議觀看Seth Vargo 和 Liz Fong Jones 的 YouTube 視頻 「SLI，SLO，SLA，哦，個人！」，以深刻了解 SLI，SLO 和 SLA 之間的差別。spa
總結一下：SLI 驅動 SLO，通知 SLA。.net
服務級別指標（SLI）是衡量服務健康情況的指標。例如，我能夠有一個 SLI，它表示在過去 5 分鐘內，個人第95 個百分點的主頁請求延遲應小於 300 毫秒。視頻
服務級別目標（SLO）是 SLI 的目標或指標。咱們採用 SLI，並擴展其範圍以量化咱們指望咱們的服務在戰略時間間隔內執行的狀況。使用前面例子中的 SLI，咱們能夠說，咱們但願知足 SLI 爲後續年份窗口的 99.9％ 設置的標準。htm
服務級別協議（SLA）是企業與客戶之間的協議，定義了未能知足 SLO 的後果。通常來講，您的 SLA 所依據的SLO 將比您的內部 SLO 更寬鬆，由於咱們但願咱們的內部面向的目標比咱們的外部目標更爲嚴格。blog
RED 儀表板
SLI 的哪些組合最適合量化主機和服務健康？在過去幾年中，出現了一些新興的標準。最高標準是 USE 方法，RED方法和 Google SRE 手冊中討論的「四個金色信號」。
Brendan Gregg 介紹了USE 方法，該方法旨在根據利用率，飽和度和錯誤指標量化系統主機的健康情況。對於像CPU 這樣的產品，咱們能夠爲用戶，系統和閒置百分比使用常見的利用率指標。咱們可使用平均負載量和運行隊列進行飽和度的斷定。UNIX perf 分析器是測量 CPU 錯誤事件的好工具。
Tom Wilkie 幾年前介紹了 RED方法。用 RED。咱們監控請求率，請求錯誤和請求持續時間。Google SRE 手冊討論瞭如何使用延遲，流量，錯誤和飽和度指標。這些「 四個金色信號 」以服務健康爲目標，與 RED 方法相似，但他添加了飽和度指標。在實踐中，可能難以量化服務飽和度。
那麼，咱們如何監控容器？容器是短時間實體。直接監視它們以辨別咱們的服務健康情況會出現許多複雜的問題，例如高基數問題。綜合監控這些容器的服務輸出會更容易和更有效。若是服務是健康的，咱們不在意一個容器是異常。有可能咱們的編排框架不管如何都會收穫這個容器，並用新的框架取而代之。
讓咱們考慮如何最好地將 Istio 的 SLI 做爲 RED 儀表板的一部分進行集成。爲了組成咱們的 RED 儀表板，咱們來看看 Istio 提供的遙測記錄：
- 請求按響應代碼計數
- 請求時長
- 請求大小
- 響應大小
- 鏈接收到的字節
- 鏈接發送字節
- 鏈接時間
- 基於模板的元數據（度量標籤）
Istio 提供了有關它收到的請求，產生響應的延遲和鏈接級別數據的幾個指標。請注意上面列表中的前兩項; 咱們但願將它們包含在咱們的 RED 儀表板中。
Istio 還賦予咱們添加度量標籤的能力，這就是所謂的尺寸。所以，咱們能夠經過主機，集羣等來分解遙測 。咱們能夠經過獲取請求計數的一階導數來得到每秒請求的速率。咱們能夠經過請求不成功的請求計數的派生來得到錯誤率。Istio 還向咱們提供每一個請求的請求延遲，所以咱們能夠記錄每一個服務請求完成的時間。