https://www.itcodemonkey.com/article/5617.html

來自：高效開發運維（微信號：DevOpsGeek），無明 譯，作者：Fred Moyer

我們應該監控服務，而不是容器。服務是長期存活的實體，而容器不是。我們應該記錄分布而不是聚合，不過要能夠從這些分布中生成聚合。

運營容器化的基礎設施帶來了一系列新的挑戰。我們需要增強容器、評估 API 端點的性能以及識別出基礎設施中的有害部分。Istio 服務網格可在不修改代碼的情況下實現 API 增強，并且不會帶來服務延遲。這篇文章將介紹如何全面了解 Kubernetes 基礎設施以及如何在基于容器的基礎設施中使用 Istio 服務網格。

Istio 概覽

Istio 是用于 Kubernetes 的服務網格，負責處理服務之間的通信，就像網絡路由軟件處理 TCP/IP 流量那樣。除了 Kubernetes 之外，Istio 還可以與基于 Docker 和 Consul 的服務發生交互。它與已經存在了一段時間的 LinkerD 有點相似。

Istio 是由來自谷歌、IBM、思科和 Lyft Envoy 的團隊共同開發的一個開源項目。Istio 最近剛滿一歲，卻已經被大規模部署到生產環境中。在寫這篇文章時 （2018 年 1 月 10 日），Istio 版本為 0.8。

那么，如何在 Kubernetes 生態系統中使用 Istio？可以這么說，Kubernetes 充當的是數據平面，Istio 則充當控制平面。Kubernetes 負責承載應用程序流量，進行容器的編配、部署和擴展。Istio 則負責路由應用程序流量，處理策略執行、流量管理和負載均衡問題。它還聚合遙測元素，如指標、日志和跟蹤。Istio 是基于容器基礎設施的協管員和警報員。

上圖描繪了服務網格的架構。Istio 為每項服務運行一個 Envoy 邊車代理。Envoy 代理通過 GRPC 調用將入站請求轉發至 Istio Mixer 服務。然后，Mixer 應用流量管理規則來聚合遙測元素。Mixer 是 Istio 的大腦。運維人員可以通過編寫 YAML 文件來指定 Envoy 如何重定向流量，還可以指定將哪些遙測元素推送到監控系統和觀測系統。我們可以在運行時根據具體情況應用相應的規則，無需重新啟動任何 Istio 組件。

Istio 支持多種適配器，用于將數據發送到各種監控工具，如 Prometheus、Circonus 或 Statsd。我們也可以同時啟用 Zipkin 和 Jaeger 跟蹤，生成圖形以便對服務進行可視化。

Istio 的部署非常簡單。大概七八個月之前，我們必須通過一系列 kubectl 命令將 Istio 安裝到 Kubernetes 群集上。現在當然也可以這么做，不過有另一種更加簡便的方式，就是在谷歌云平臺上點擊幾下鼠標即可部署啟用了 Istio 的 Kubernetes 群集，包括監控、跟蹤和示例應用程序。

另一個好處是，我們可以在不要求開發人員對他們的服務進行增強的情況下收集服務數據。這樣可以減少維護工作、消除代碼中的失敗點。它還提供了與供應商無關的接口，降低了被供應商鎖定的可能性。

借助 Istio，我們可以部署單個服務的不同版本，并權衡它們之間的流量。Istio 本身使用了多個不同的 pod，如下所示：

>?kubectl?get?pods?-n?istio-system NAME?????????????????????READY?STATUS??RESTARTS?AGE istio-ca-797dfb66c5??????1/1???Running??0???????2m istio-ingress-84f75844c4?1/1???Running??0???????2m istio-egress-29a16321d3??1/1???Running??0???????2m istio-mixer-9bf85fc68????3/3???Running??0???????2m istio-pilot-575679c565???2/2???Running??0???????2m grafana-182346ba12???????2/2???Running??0???????2m prometheus-837521fe34????2/2???Running??0???????2m

Istio 實際上不是輕量級的。Istio 的強大功能和靈活性帶來了一些運營成本。但是，如果應用程序中包含多個微服務，那么應用程序容器很快會表現出比系統配置容器更大的優勢。

服務水平目標 (SLO)

關于服務水平目標的概述將為我們如何衡量服務健康狀況奠定基礎。服務水平協議（Service Level Agreement，SLA）的概念已經存在了至少十年。而直到最近，與服務水平目標（Service Level Objective，SLO）和服務水平指示器（Service Level Indicator，SLI）相關的網絡內容才出現爆發式的增長。

除了谷歌的那本“Site Reliability Engineering”之外，還有兩本有關 SLO 的新書即將問世。“The Site Reliability Workbook”有專門的章節介紹了 SLO，而 Circonus 創始人兼首席執行官 Theo Schlossnagle 在“Seeking SRE”的一個章節中對 SLO 的目標進行了定義。建議觀看由 Seth Vargo 和 Liz Fong Jones 呈獻的 YouTube 視頻“SLIs,SLOs, SLAs, oh my!” （鏈接：https://youtu.be/tEylFyxbDLE），以便深入了解 SLI、SLO 和 SLA 之間的差別。

總的來說：SLI 驅動 SLO，SLO 通知 SLA。

SLI 是衡量服務健康狀況的指標。例如，我們可以有這樣的一個 SLI，它表示在過去 5 分鐘內，95% 的主頁面請求延遲應小于 300 毫秒。

SLO 是 SLI 的目標。我們對 SLI 進行擴展，用以量化我們對服務在給定時間間隔內執行情況的期望。以上面的 SLI 為例，我們可以說，我們希望這個 SLI 設定的標準在下一年可以達到 99.9％。

SLA 是企業與客戶之間的協議，定義了未能滿足 SLO 的后果。一般來說，SLA 所依據的 SLO 比內部 SLO 更寬松，因為我們希望內部目標比外部目標更為嚴格。

RED 儀表盤

怎樣的 SLI 組合最適合用于量化主機和服務的健康程度？在過去幾年中，出現了一些新興的標準。其中最有影響力的是 USE 方法、RED 方法和谷歌 SRE 手冊中討論的“四個黃金信號”。

USE 方法由 Brendan Gregg 提出，旨在根據利用率、飽和度和錯誤指標量化系統主機的健康狀況。對于像 CPU 這樣的產品，我們可以使用常用的指標，如用戶、系統和閑置百分比。我們可以使用平均負載和運行隊列來衡量飽和度。UNIX 的 perf 分析器是用來測量 CPU 錯誤事件的一個很好的工具。

幾年前，Tom Wilkie 提出了 RED 方法。借助 RED 方法，我們對請求率、請求錯誤和請求持續時間進行監控。谷歌 SRE 手冊討論了如何使用延遲、流量、錯誤和飽和度這四個指標。這“四個黃金信號”主要針對服務健康，與 RED 方法類似，只是多了飽和度這一項。但在實踐中，可能難以量化服務飽和度。

那么，我們如何監控容器？容器存活期短，通過直接監控它們來識別服務健康狀況將帶來很多復雜的問題，例如高基數問題。通過聚合這些容器的輸出來監控它們會更容易和有效。如果一個服務是健康的，我們就不會在乎容器的行為是否正常。我們的編配框架會捕獲到這個容器，并用新的容器取而代之。

讓我們來看看如何將 Istio 的 SLI 作為 RED 儀表盤的一部分。首先看看 Istio 都提供了哪些遙測元素：

• 基于響應碼的請求數

• 請求時長

• 請求大小

• 響應大小

• 連接收到的字節

• 連接發送的字節

• 連接時長

• 基于模板的元數據（度量標簽）

Istio 提供了幾個有關收到的請求、響應延遲和連接信息的指標。請注意上述列表中的前兩項，我們希望將它們包含在 RED 儀表盤中。

Istio 還賦予我們添加度量標簽的能力，就是所謂的維度。我們可以按照主機、集群等對遙測元素進行拆解。我們可以通過計算請求數的一階導數來獲得每秒請求速率。我們還可以通過計算不成功請求數的導數來獲得錯誤率。Istio 還為我們提供了每個請求的延遲，因此我們可以記錄每個服務請求需要多少時間才能處理完。

另外，Istio 還為我們提供了一個 Grafana 儀表盤，它包含了我們想要的部分：

上面截圖中以紅色圈起來的部分是我們想要的組件。左上角是每秒操作請求速率，右上角是每秒失敗請求數，底下是響應時間。現在讓我們來仔細看看圈出的那幾個指標：

2018-07-10

這個截圖顯示了儀表盤的速率組件。我們統計返回 200 響應碼的請求數，并繪制成圖形。

Istio 儀表盤為返回 5xx 錯誤碼的響應做了類似的操作。在上面的截圖中，可以看到，它按照攝入控制器或應用程序產品頁的錯誤來區分錯誤。

這個截圖顯示了請求持續時間，提供了豐富的有關服務健康狀況的信息。這些數據由 Prometheus 監控系統提供，因此我們可以看到請求時間百分位，包括中位數、90th、95th 和 99th 這些百分位。

這些百分位為我們提供了有關服務執行情況的全面指示。但是，這種方法也存在一些缺陷。在活動不是很活躍的時候，由于樣本數量有限，這些百分位可能會大幅偏離，給我們帶來誤導。這種方法可能出現的其他問題：

持續時間問題：

• 百分位是基于固定時間窗口的聚合指標。

• 無法為群集健康重新聚合百分位。

• 不能計算百分位平均數（這是一個常見的錯誤）。

• 這種方法存儲的聚合是輸出，而不是輸入。

• 很難用這種方法測量集群 SLI。

百分位通常比平均數提供更深刻的洞見，因為它們使用多個數據點來表示數值范圍。但與平均數一樣，百分位是一種聚合度量。它們是基于固定時間窗口對固定數據集計算得出的。如果我們要計算某個集群成員的持續時間百分比，就不能將其與另一個集群成員合并，因為這樣得到的是整個集群的聚合指標。

我們不能計算百分位的平均數，除非產生這些百分位的分布幾乎是一樣的，但這種情況很少見。如果你只有百分位，而不是源數據，那么就不知道它是不是這種情況。這是一個雞生蛋和蛋生雞的問題。

這也意味著，如果你只是基于百分比衡量單個集群成員的性能，就會因缺少聚合而無法為整個服務設置 SLI。

由于在固定時間窗口內只有 4 個延遲數據點，我們只能在有限的范圍內設置有意義的 SLI。因此，在你使用基于百分位的持續時間指標時，必須問自己，你的 SLI 是否真的足夠好。我們可以借助數學來設定更好的 SLI，從而全面了解服務的性能和健康狀況。

直方圖遙測

上面是以微秒為單位顯示服務延遲數據的一個直方圖。樣本數量位于 Y 軸上，樣本值（微秒級延遲）位于 X 軸上。這是我們在 Circonus 開發的開源直方圖，也請參考 C 語言（https://github.com/circonus-labs/libcircllhist）和 Golang（https://github.com/circonus-labs/circonusllhist）的直方圖開源實現。還有其他一些開源的直方圖實現，如 Ted Dunning 的 t-digest 直方圖（https://github.com/tdunning/t-digest）和 HDR 直方圖（http://hdrhistogram.org/）。

Envoy 項目最近采用了 Circonus 開發的 C 語言版本的對數線性直方圖庫，因此可以顯示所收集數據的分布情況。

直方圖是可以合并的，只要 bin 的邊界相同，任何兩個或多個直方圖都可以合并在一起。這意味著我們可以將多個分布組合在一起。可合并的度量指標對于監控和可觀測性來說非常有用。我們因此可以合并來自相似資源（如服務成員）的輸出，并獲得聚合的服務指標。

如上圖所示，在這個對數線性直方圖中，每 10 次冪對應 90 個 bin。從圖中可以看到 100K 到 1M 個之間的 90 個 bin。對于每 10 次冪，bin 的大小就以 10 的倍數增長。這樣我們就能夠以較高的相對精度記錄各種數值，而不需要提前知道數據的分布情況。如果我們將一些百分位重疊起來會是什么樣子：

可以看到，現在有平均值、50th 百分位（也稱為中位數）和 90th 百分位。90th 百分位是指 90％樣本低于該值。

現在回到之前的 SLI 示例，如果按照這種格式來顯示延遲數據，就可以通過將直方圖合并在一起來獲得 5 分鐘的數據視圖，然后計算出該分布的 90th 百分位，從而得到服務的 SLI。如果它低于 1,000 毫秒，就達到了我們的目標。

上面截圖中的 RED 儀表盤包含了四個百分位：50th、90th、95th 和 99th。我們也可以重疊這些百分位。即使在沒有數據的情況下，我們也可以看到請求分布的大致輪廓，當然，這里需做出很多假設。要想知道僅基于幾個百分位做出的假設將給我們造成怎樣的誤導，可以看看這個帶有其他模式的分布：

這個直方圖顯示了兩種不同模式的分布。左邊的模式表示快速響應，可能是因為使用了緩存，而右邊的表示從磁盤上讀取數據再做出響應。僅使用四個百分位來衡量延遲幾乎不可能辨別這種分布。可見，百分位會隱藏掉一些復雜性。現在讓我們來看看具有兩種以上模式的分布：

這個分布至少有四種模式。如果我們在全分布上運行數學運算，可以找到 20 多種模式。那么我們需要記錄多少個百分位才能獲得一個近似于上面這樣的延遲分布呢？又比如下面這個分布呢？

由很多服務組成的復雜系統將生成無法用百分位準確表示的延遲分布，我們必須記錄整個延遲分布才能完整地表示它。這就是為什么要將數據的完整分布放在直方圖中，并根據實際需要計算出百分位，而不只是保存幾個百分位。

這種直方圖顯示了固定時間窗口上的分布。我們可以存儲多個分布，以了解它隨時間變化的情況，如下所示：

這是一個熱圖，代表一組隨時間變化的直方圖。想象一下，這個熱圖中的每一列都有一個單獨的條形圖，用顏色來表示每個 bin 的高度。這是一個集群（包含 10 個負載均衡器）響應延遲在 Grafana 中的可視化。我們因此能夠深入了解整個集群一周之內的行為，這里包含了 100 萬個數據樣本。這里的中位數大約在 500 微秒左右，以紅色條形表示。

上面是另一種類型的熱圖，其中使用飽和度表示每個 bin 的“高度”（塊顏色越深表示越“飽和”）。此外，這次我們在熱圖上重疊了隨時間變化的百分位。百分位是可靠的度量指標，而且非常有用，但它們本身并不能發揮這種作用。我們可以看到 90 以上的百分位將如何隨著延遲分布向上移動而增加。

讓我們來看看這些時間段分布圖，看看是否可以生成比樣本儀表盤包含更多信息的東西：

上面的截圖是修改后的 RED 儀表盤，顯示了基于分布的延遲數據。左下角顯示了固定時間窗口的延遲直方圖。在它的右邊，我們使用熱圖將分布分解成更小的時間窗口。利用 RED 儀表盤的布局，我們只需要借助幾個信息面板就可以全面了解我們的服務是如何運作的。這個儀表盤是使用 Grafana 實現的，后臺使用了 IRONdb 時間序列數據庫，該數據庫在本地存儲延遲數據，用于構建對數線性直方圖。

我們可以進一步擴展這個 RED 儀表盤，并將 SLI 重疊到上面：

對于速率面板，我們的 SLI 可能會保持最低水平的每秒請求數，每秒錯誤數也可能保持在某個值之下。正如我們之前研究過的 SLI，我們可能希望整個服務的 99th 百分位在固定時間窗口內保持一定的延遲。我們可以借助這些直方圖來設置有意義的 SLI。現在我們還有很多工作要做，而且可以更好地審查我們的數據。

問正確的問題

我們已經把所有的東西都放在了一起，并看到了如何利用 Istio 從服務中獲取有意義的數據，現在讓我們看看可以解決哪些問題。

我們都希望能夠解決技術問題，但不是每個人都專注于此。業務人員會問業務方面的問題，所以你要能夠回答這些問題。接下來讓我們看看已經組裝好的工具將怎樣解決業務人員向 SRE 提出的問題：

示例問題：

• 在周二的大促活動后，有多少用戶因為速度變慢而感到不愉快？

• 我們的結帳服務是過度配置了還是配置不足？

先看第一個例子。每個人可能都有過訪問龜速網站的體驗。假設一次市場大推廣導致流量暴增，性能下降，用戶抱怨網站速度太慢。我們如何量化速度有多慢？有多少用戶感到不愉快？假設市場營銷部門想知道這些問題的答案，然后就可以向受影響的用戶發送 10％折扣的電子郵件，同時希望避免同樣問題再次發生。我們定義了一個 SLI，假設用戶注意到速度變慢，并在請求超過 500 毫秒時感到生氣。我們如何基于這個 500 毫秒的 SLI 計算有多少用戶感到生氣？

首先，我們需要記錄請求延遲，然后將它們繪制成熱圖。我們可以使用分布數據來計算超過 500 毫秒 SLI 的請求的百分比（借助反向百分位），然后將其乘以該時間窗口中的請求總數，最后將隨時間變化的結果重疊在熱圖上：

在上面的截圖中，我們已經在熱圖上圈出了速度變慢的部分。增加的延遲分布足以告訴我們速度變慢了。圖中的線表示受影響的請求總數隨時間變化的情況。

在這個例子中，有 400 萬個請求達不到我們的 SLI。右邊的兩處速度變慢不是很明顯，因為它們的幅度較小，但每處都有 200 萬個請求達不到 SLI。

我們可以繼續進行這類數學分析，因為數據被存儲為分布，而不只是聚合的百分位。

現在讓我們來考慮另一個問題，即我們的服務是配置不足還是配置過度？

答案通常是“視情況而定”。除了碰上特殊日子，負載在一天中和一周中的每一天也都有所不同。在我們搞清楚系統在特定負載下的行為之前，我們所知道的就是這些。現在我們來做一些簡單的數學運算，使用延遲來可視化系統是如何運行的：

上面的可視化顯示了延遲分布隨時間變化的情況，包括低于 25 毫秒的請求數、25 毫秒到 100 毫秒的請求數、100 毫秒到 250 毫秒的請求數、250 毫秒到 1000 毫秒的請求數以及超過 1000 毫秒的請求數。它們按照顏色進行分組，綠色表示快速請求，紅色表示慢請求。

這種可視化告訴了我們什么？我們可以看到，服務請求在一開始非常快，幾分鐘后快請求的百分比下降，大約 10 分鐘后慢請求的百分比增加。這種模式在兩次流量會話中重復出現。這又告訴了我們什么？這表明，最初服務過度配置，但在隨后的 10 到 20 分鐘內配置不足。看起來，這里很適合使用自動伸縮。

我們也可以將這種類型的可視化添加到 RED 儀表盤中。這種類型的數據對業務利益相關者來說非常有用，而且他們不需要掌握大量的技術知識就可以了解它們對業務的影響。

? 結論??

我們應該監控服務，而不是容器。服務是長期存活的實體，而容器不是。用戶并不關心容器如何運行，他們只關心服務如何運行。

我們應該記錄分布而不是聚合，不過要能夠從這些分布中生成聚合。聚合是非常有價值的信息來源。但它們是不可合并的，因此不適用于統計分析。

Istio 提供了很多現成的東西，我們沒有必要去修改我們的代碼，也沒必要從頭開始構建高質量的應用程序框架。

使用數學方法提出并回答有關服務的問題。當我們通過解決重要的業務問題讓系統變得更加可靠時，其實是實現了組織的目標。

轉載于:https://www.cnblogs.com/davidwang456/articles/9311470.html

總結

以上是生活随笔為你收集整理的详解如何使用Istio监控基于容器的服务的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。