使用 Kubernetes 和 Istio 進行基于容器的全面服務監控
原文連結：https://www.circonus.com/2018/06/comprehensive-container-based-service-monitoring-with-kubernetes-and-istio/
作者：Fred Moyer
譯者：殷龍飛
營運容器化基礎設施帶來了一系列新的挑戰。您需要對容器進行測試，評估您的 API 端點性能，并确定您的基礎架構中的不良的元件。Istio 服務網格可在不更改代碼的情況下實作 API 的檢測，并且可以自由的設定服務延遲。但是，你如何了解所有這些資料？用數學的方式，對，就是這樣。
Circonus 是 Istio 的第一個第三方擴充卡。在 之前的文章中，我們讨論了第一個用于監視基于 Istio 的服務的 Istio社群擴充卡。這篇文章将對此進行擴充。我們将解釋如何全面了解您的 Kubernetes 基礎設施。我們還将解釋如何為基于容器的基礎架構增加 Istio 服務網格實作。
Istio 概述
Istio 是 Kubernetes 的服務網格，這意味着它負責所有服務之間的通信和協調，就像網絡路由軟體為 TCP/IP 流量所做的一樣。除了 Kubernetes 之外，Istio 還可以與基于 Docker 和 Consul 的服務進行互動。它與 LinkerD 相似，它已經存在了一段時間。
Istio 是由 Google，IBM，思科和 Lyft 的 Envoy 開發的開源項目。該項目已經有一年的曆史了，而 Istio 已經進入了大規模生産環境。在這篇文章釋出時，目前版本為 0.8。
那麼，Istio 如何融入Kubernetes 生态系統？Kubernetes 充當資料層，Istio 充當控制層。Kubernetes 承載應用程式流量，處理容器編排，部署和擴充。Istio 路由應用程式流量，處理政策執行，流量管理和負載均衡。它還處理遙測聯合，如名額，日志和跟蹤。Istio 是基于容器的基礎設施的交叉防護裝置和報告部分。
上圖顯示了服務網格體系結構。Istio 為每項服務使用了一個 envoy sidecar proxy。Envoy 通過 GRPC 調用代理到 Istio Mixer 服務的入站請求。然後，Mixer 應用流量管理規則，并聯合請求遙測。Mixer 是 Istio 的大腦。運維人員可以編寫 YAML 檔案來控制 Envoy 如何重定向流量。他們還可以指定監測資訊推送和可觀測性系統的遙測技術。可以在運作時根據需要應用規則，而無需重新啟動任何 Istio 元件。
Istio 支援多種擴充卡将資料發送到各種監控工具。包括普羅米修斯，Circonus 或 Statsd。您也可以同時啟用Zipkin 和 Jaeger 追蹤。而且，您可以把可視化所涉及的服務生成圖形。
Istio 易于部署。回想起來，大約7到8個月之前，您必須通過一系列 kubectl 指令将 Istio 安裝到 Kubernetes 群集上。你今天仍然可以。但是現在，您隻需在 Google Cloud platform，隻需點選幾下滑鼠即可部署啟用了 Istio 的Kubernetes 群集，其中包括監視，跟蹤和示例應用程式。您可以很快運作起來，然後使用 istioctl 指令開始玩樂。
另一個好處是我們可以從服務中收集資料，而不需要開發人員對他們的服務進行測試以提供資料。這有很多好處。它減少了維護。它消除了代碼中的失敗點。它提供了供應商不可知的接口，這減少了供應商綁定的機會。
借助 Istio，我們可以部署不同版本的服務并權重它們之間的流量。Istio 本身使用多個不同的 pods 來操作，如下所示：
> kubectl get pods -n istio-system
NAME READY STATUS RESTARTS AGE
istio-ca-dfb66c5 / Running m
istio-ingress-f75844c4 / Running m
istio-egress-a16321d3 / Running m
istio-mixer-bf85fc68 / Running m
istio-pilot-c565 / Running m
grafana-ba12 / Running m
prometheus-fe34 / Running m
Istio 不完全是輕量級的。Istio 的強大功能和靈活性來源于一些運維成本。但是，如果您的應用程式中包含多個微服務，那麼您的應用程式容器将很快超過系統配置的容器。
服務級别目标
這個服務級别目标的簡要概述将為我們如何衡量我們的服務健康狀況奠定基礎。服務級别協定（SLA）的概念已經存在了至少十年。但就在最近，與服務級别目标（SLO）和服務級别名額（SLI）相關的線上内容數量迅速增加。
除了著名的 Google SRE書以外，兩本關于 SLO 的新書即将釋出。“站點可靠性工作手冊”有關于 SLO 的專門章節，Seeking SRE 有關于由 Circonus 創始人兼首席執行官 Theo Schlossnagle 定義 SLO 目标的章節。我們還建議觀看Seth Vargo 和 Liz Fong Jones 的 YouTube 視訊 “SLI，SLO，SLA，哦，我的！”，以深入了解 SLI，SLO 和 SLA 之間的差異。
總結一下：SLI 驅動 SLO，通知 SLA。
服務級别名額（SLI）是衡量服務健康狀況的名額。例如，我可以有一個 SLI，它表示在過去 5 分鐘内，我的第95 個百分點的首頁請求延遲應小于 300 毫秒。
服務級别目标（SLO）是 SLI 的目标或名額。我們采用 SLI，并擴充其範圍以量化我們期望我們的服務在戰略時間間隔内執行的情況。使用前面例子中的 SLI，我們可以說，我們希望滿足 SLI 為後續年份視窗的 99.9％ 設定的标準。
服務級别協定（SLA）是企業與客戶之間的協定，定義了未能滿足 SLO 的後果。一般來說，您的 SLA 所依據的SLO 将比您的内部 SLO 更寬松，因為我們希望我們的内部面向的目标比我們的外部目标更為嚴格。
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 還向我們提供每個請求的請求延遲，是以我們可以記錄每個服務請求完成的時間。
另外，Istio 為我們提供了一個 Grafana 儀表闆，它包含我們想要的部分：
我們想要的元件在上面的螢幕截圖中以紅色圈起來。我們在左上角的每秒操作請求率，右上角的每秒失敗請求數，以及底部的響應時間圖。這張圖上還有其他幾個名額，但讓我們仔細看看我們圈出的那些名額：
以上螢幕截圖顯示了儀表闆的速率元件。這非常簡單。我們計算傳回 200 響應代碼的請求數，并繪制一段時間内的速率圖。
Istio 儀表闆為傳回 5xx 錯誤代碼的響應做了類似的操作。在上面的螢幕截圖中，您可以看到它如何通過 ingress controller 或應用程式産品頁面本身的錯誤來分解錯誤。
該螢幕截圖顯示了請求持續時間圖。此圖是關于我們服務的健康狀況的最豐富資訊。這些資料由普羅米修斯監測系統提供，是以我們可以看到請求時間百分點，包括中位數，第90,95和第99百分位。
這些百分比為我們提供了服務如何執行的全面訓示。但是，這種方法存在一些值得研究的缺陷。在低活動期間，由于樣本數量有限，這些百分位數可能會大幅偏離。這可能會誤導您關于這些情況下的系統性能。我們來看看這種方法可能出現的其他問題：
持續問題：
- 百分位數是固定時間視窗上的聚合名額。
- 叢集健康無法重新彙總百分位數。
- 百分位不能被平均（這是一個常見的錯誤）。
- 這種方法存儲的聚合是輸出，而不是輸入。
- 用這種方法測量叢集 SLI 是很困難的。
百分位數通常比平均數提供更深的洞察力，因為它們用多個資料點而不是一個資料點來表示數值範圍。但是像平均值一樣，百分位數是一個彙總名額。它們是針對固定資料集在固定時間視窗上計算的。如果我們計算一個叢集成員的持續時間百分比，我們不能将其與另一個叢集成員合并，以獲得整個叢集的聚合性能名額。
普遍的誤解是百分位可以被平均; 除非産生它們的分布幾乎相同的極少數情況除外。如果你隻有百分位，而不是源資料，你不知道可能是這種情況。這是一個雞和雞蛋的問題。
這也意味着，如果您僅針對單個叢集成員衡量基于百分比的性能，則由于缺乏可合并性而無法為整個服務設定服務級别訓示符。
由于在固定的時間視窗内隻有4個延遲資料點，是以我們設定有意義的 SLI（以及是以，有意義的 SLO ）的能力在此處受到限制。是以，當您使用基于百分位的持續時間名額進行工作時，您必須問自己，您的 SLI 是否真的有很好的 SLI。通過使用數學來确定 SLI，我們可以做得更好，進而全面了解我們的服務的性能和健康狀況。
直方圖計量資料
以上是使用直方圖以微秒為機關顯示服務延遲資料的可視化。樣本數量位于 Y 軸上，樣本值（在本例中為微秒等待時間）位于 X 軸上。這是我們在 Circonus 開發的開源直方圖。（請參閱 C 和 Golang 中的開源代碼，或者在此處閱讀有關直方圖的更多資訊。）還有一些開源的直方圖實作，如 Ted Dunning 的 t-消化直方圖和 HDR 直方圖。
Envoy 項目最近采用了 Circonus 的對數線性直方圖庫的 C 實作。這使得 envoy 資料可以作為分布來收集。他們在實施中發現了一個非常小的錯誤，Circonus 非常樂意修複。這就是開源的美妙之處，由于有更多的人可以檢視代碼，更多的人可以發現問題，并修正問題，那麼随着時間的推移代碼将會越來越好。
直方圖可合并。隻要邊界相同，任何兩個或更多的直方圖可以合并。這意味着我們可以将此分布與其他分布結合起來。可合并度量對于監視和可觀察性非常有用。它們允許我們合并來自類似資源的輸出，例如服務成員，并獲得總體服務名額。
如上圖所示，此對數線性直方圖包含每個幂為 10 的 90 個容器。您可以看到100,000個到1M個之間的90個容器。在每個 10 的功率下，箱尺寸增加 10 倍。這使得我們能夠以高相對精度記錄各種各樣的值，而不需要提前知道資料分布。讓我們看看當我們覆寫一些百分點時，這看起來像什麼：
現在您可以看到我們的平均水準，第50百分位（也稱為中位數）和第 90 百分位。第 90 百分位是 90％ 樣本低于該值的值。
考慮我們之前的示例 SLI。通過以此格式顯示延遲資料，我們可以通過将直方圖合并為一個 5 分鐘的資料視圖，然後計算該分布的第 90 百分位數值，輕松計算服務的 SLI。如果它少于1,000毫秒，我們達到了我們的目标。
上面截圖中的 RED 儀表盤持續時間圖有四個百分點，第50,90,95和99個。我們也可以覆寫這些分布的百分位數。即使沒有資料，我們也可以看到請求分布可能看起來很粗糙的形式，但是這會做出很多假設。要看到基于幾個百分點的假設如何誤導，我們來看看具有其他模式的分布：
該直方圖顯示具有兩種不同模式的分布。最左邊的模式可能是由于緩存服務而産生的快速響應，以及來自磁盤的正确模式。僅僅使用四個百分點來衡量延遲就幾乎不可能辨識出這樣的分布。這給了我們一個百分點可以掩蓋的複雜性的感覺。考慮具有兩種以上模式的配置設定：
此分布至少有四種可見模式。如果我們對全分布進行數學運算，我們會在這裡找到 20 多種模式。您需要記錄幾個百分位以接近上面的延遲分布？關于下面的發行版怎麼樣？
由許多服務組成的複雜系統将生成無法用百分位準确表示的延遲分布。您必須記錄整個延遲分布才能充分表示它。這是将資料的完整分布存儲在直方圖中并根據需要計算百分位數的優選原因之一，而不是僅存儲幾個百分點。
這種直方圖可視化顯示了固定時間視窗上的分布。我們可以存儲多個發行版，以了解它随時間變化的情況，如下所示：
這是一個熱圖，它代表一組随時間變化的直方圖。想象一下，這個熱圖中的每一列都有一個從上面看的單獨的條形圖，顔色用于訓示每個垃圾箱的高度。這是來自 10 個負載均衡器叢集的響應延遲的 grafana 可視化。這使我們能夠深入了解整個叢集的系統行為，一周之内就有超過100萬個資料樣本。這裡的中位數大約在 500 微秒左右，以紅色帶表示。
以上是另一種類型的熱圖。此處，飽和度用于訓示每個容器的“高度”（較暗的色塊更“飽滿”）。此外，這次我們在熱圖上覆寫了一段時間内的百分比計算。百分位數是健壯的度量标準，非常有用，但不是它們自己。我們可以在這裡看到，随着延遲分布向上移動，90％ 以上的百分位數如何增加。
讓我們來看看這些基于分布的持續時間圖，看看我們是否可以生成比樣本 Istio 儀表闆更多的資訊：
上面的螢幕截圖是修改後的 RED 儀表闆，顯示基于分布的延遲資料。在左下角，我們顯示了一個固定時間視窗上的延遲直方圖。在它的右邊，我們使用熱圖将分布分解成更小的時間視窗。利用 RED 儀表闆的布局，我們可以通過幾個小組資訊全面了解我們的服務是如何運作的。這個特定的儀表闆是使用 Grafana 實作的，它使用 IRONdb時間序列資料庫服務，該資料庫本地存儲等待時間資料作為對數線性直方圖。
我們可以進一步擴充這個 RED 儀表闆，并将 SLI 覆寫到圖表上：
對于速率面闆，我們的 SLI 可能會保持每秒最低水準的請求。對于速率面闆，我們的 SLI 可能會保持每秒一定數量的錯誤。正如我們之前研究過持續時間 SLIs，我們可能希望我們的整個服務的第 99 個百分點由多個窗格組成，以在固定視窗内保持一定的延遲。使用存儲為直方圖的 Istio 遙測技術可以讓我們設定這些有意義的服務範圍的 SLI。現在我們還有很多工作要做，而且我們可以更好地審問我們的資料（見下文）。
提出正确的問題
是以現在我們已經把這些部分放在一起，并看到了如何使用 Istio 從我們的服務中擷取有意義的資料，讓我們看看我們可以回答哪些問題。
我們都喜歡能夠解決技術問題，但不是每個人都有同樣的重點。業務人員想回答關于業務如何的問題。您需要能夠回答以業務為中心的問題。讓我們來看看我們已經組裝的工具集，并将這些功能與業務提出 SRE 的幾個問題對齊：
示例問題：
- 在大促銷推廣後，有多少使用者在周二的速度降低中生氣？
- 我們是否在我們的購物結帳服務中超額配置或者配置不足？
考慮第一個例子。每個人都經曆了一次巨大的速度降低。比方說，市場推廣做得很大，流量增加了，運作速度降低了，使用者抱怨網站速度緩慢。我們如何量化每個人的速度有多慢？有多少使用者生氣了？比方說，市場營銷部門想知道這一點，以便他們可以向受影響的使用者發送 10％ 的折扣電子郵件，同時也希望避免同樣問題的再次發生。讓我們制作一個 SLI，并假設使用者注意到放緩并且在請求花費超過 500 毫秒時生氣。我們如何計算有多少使用者對這個500毫秒的 SLI 感到憤怒？
首先，我們需要将請求延遲記錄為分發。然後我們可以将它們繪制成熱圖。我們可以使用分布資料來計算超過500ms SLI 的請求的百分比，方法是使用逆百分比。我們将這個答案乘以該時間視窗中的請求總數，并随時間積分。然後我們可以繪制覆寫在熱圖上的結果：
在此螢幕截圖中，我們已經圈出了發生速度降低的熱圖的一部分。增加的延遲分布是相當緩慢的訓示。圖中的線表示受到一段時間影響的請求總數。
在這個例子中，我們設法錯過了 400 萬個請求的 SLI。哎呦。不明顯的是右邊的兩個額外減速，因為它們幅度較小。每個這些花費我們額外 200 萬 SLI 違規。哎喲。
我們可以進行這些類型的數學分析，因為我們将資料存儲為分布，而不是像百分位數之類的聚合。
我們來考慮另一個常見問題。我的服務是否置備或配置過度？
答案通常“視情況而定”。根據一天中的時間和一周的日子，負載會有所不同，除了因特殊事件而變化之外。那是在我們甚至考慮系統在負載下的行為之前。讓我們把一些數學工作，并使用延遲帶來可視化我們的系統如何執行：
上面的可視化顯示延遲分布随着時間的推移被延遲帶分解。這裡的頻段顯示 25ms 到 100ms，100-250ms，250-1000 和 1000ms 以下的請求數。顔色按照綠色顯示的快速請求分組，以減慢以紅色顯示的請求。
這種可視化告訴我們什麼？它表明，對我們的服務的請求非常迅速地開始，然後幾分鐘後快速請求的百分比就會下降，大約 10 分鐘後請求的緩慢百分比就會增加。這種模式重複了兩次交通會話。那告訴我們關于配置的是什麼？它表明，最初服務過度供應，但随後在 10-20 分鐘的過程中供應不足。聽起來像是自動縮放的好選擇。
我們也可以将這種類型的可視化添加到我們的 RED 儀表闆。這種類型的資料對業務利益相關者來說非常好 而且它不需要大量的技術知識投資來了解對業務的影響。
結論
我們應該監視服務，而不是容器。服務是長期存在的實體，容器不是。您的使用者不關心您的容器如何執行，他們關心您的服務如何執行。
你應該記錄分布而不是聚合。但是，那麼你應該從這些分布産生你的聚合。聚集體是非常有價值的資訊來源。但它們無法合并，是以它們不适合進行統計分析。
Istio 免費提供了很多東西。您不必使用代碼來編寫。您無需從頭開始建構高品質的應用程式架構。
使用數學提出并回答有關您的服務的問題，這對業務很重要。就是這一切，對吧？當我們通過回答企業價值觀的問題使系統可靠時，我們實作了組織的目标。