目标4个9的可用性？试试用 Prometheus 和 Grafana记录服务可用时间
作者 | Juanjo Ciarlante
譯者 | 關賀宇
SLO 是“服務水平目標”，意為在團隊內部設置目標，驅動測試閾值，例如“99.9% 的可用性”就是 SLO。本文重點介紹如何使用 Prometheus 和 Grafana 記錄服務處于 SLO 的時間。
在線服務的目標應該是提供與業務需求匹配的可用服務。此流程的關鍵部分應該涉及組織中的不同團隊，例如，從業務開發團隊到工程團隊。要驗證一個服務如何符合這些目標，可以用這些目標可衡量的“成就”來定義“閾值”，例如，“服務必須在 99.9% 的時間內可用”，這應該與用戶的期望和業務連續性相匹配。
SLA, SLO, SLI
已經有很多關于這些話題的文章，如果你不熟悉這些術語，我強烈建議你先閱讀谷歌關于 SLO(服務級別目標) 的 SRE 書籍中的文章。
總而言之：
-
SLA：服務水平協議
-
你承諾向用戶提供的服務，如果你無法滿足，可能會受到懲罰。
-
例如：“99.5%”的可用性。
-
關鍵詞：合同
-
-
SLO：服務水平目標
-
你在內部設置的目標，驅動你的測量閾值 (例如，儀表板和警報)。通常，它應該比 SLA 更嚴格。
-
示例：“99.9%”可用性 (所謂的“三個 9”)。
-
關鍵字：閾值
-
-
SLI：服務水平指標
-
你實際測量的是什么，以確定你的 SLO 是否在滿足目標 / 偏離目標。
-
示例：錯誤率、延遲。
-
關鍵詞：指標。
-
SLO 關注時間
99% 的可用性意味著什么？它不是 1% 的錯誤率 (失敗的 http 響應的百分比)，而是在一個預定義的時間段內可用服務的時間百分比。
?
在上面的儀表板中，服務在 1 小時內的錯誤率超過 0.1% (y 軸為 0.001)(錯誤峰值頂部的紅色小水平段)，從而在 7 天內提供 99.4% 的可用性：
這一結果中的一個關鍵因素是你選擇度量可用性的時間跨度 (在上面的示例中為 7 天)。較短的周期通常用作工程團隊 (例如 SRE 和 SWE) 的檢查點，以跟蹤服務的運行情況，而較長的周期通常用于組織 / 更廣泛的團隊的評審目的。
例如，如果你設置了 99.9% 的 SLO，那么服務可以停機的總時間如下:
-
30 天：43 分鐘 (3/4 小時)
-
90 天：129 分鐘 (~2 小時)
另一個無關緊要的“數字事實”是，給 SLO 多加一個 9 都會產生明顯的指數級影響。以下是 1 年的時間跨度的時間組成部分:
-
2 個 9: 99%: 5250min (87hrs 或 3.64 天)
-
3 個 9: 99.9%: 525min (8.7hrs)
-
4 個 9: 99.99%: 52.5min
-
5 個 9：99.999%：5min< - 經驗法則：5 個 9 -> 5 分鐘 (每年)
輸入錯誤預算
在服務可以停機的允許時間內，上面的數字可能被認為是錯誤預算，你可以從以下事件中消耗這些錯誤預算:
-
計劃維護
-
升級失敗
-
意想不到的故障
實際的結果是，上面的任何一種情況都將消耗服務的錯誤預算，例如，意外的停機可能會耗這些預算，從而在此期間阻止進一步的維護工作。
SLI 與度量有關
從上面可以清楚地看出，必須有服務指標來告訴我們什么時候認為服務可用／不可用。有幾種方法可以做到這一點：
-
RED：速率、錯誤、持續時間。
-
USE：利用率、飽和度和錯誤。
SLO 實現例子
讓我們舉一個具體的例子，遵循 RED 方法 (因為我們現有的度量標準更適合這種方法)：通過 Prmoetheus 和 Grafana 等監控工具創建警報和 dashboard，以支持 Kubernetes API 的目標 SLO。
此外，我們將使用 jsonnet 來構建規則和儀表盤文件，充分利用現有的庫助手。
-
Prometheus
-
Grafana
-
jsonnet
本文不是解釋如何在服務超出閾值時發出信號，而是重點介紹如何記錄服務處于這種情況的時間。
本文的其余部分將著重于創建 Prometheus 規則，以根據特定度量標準 (SLI) 的閾值捕獲“超出 SLO 的時間”。
定義 SLO 目標和指標閾值
讓我們定義一個簡單的目標：
-
SLO：99%，來自以下數據：
-
SLI：
-
錯誤率低于 1%
-
請求的 90% 的延遲小于 200ms
-
以 jsonnet 的形式編寫上述規范 (參見 [spec-kubeapi.jsonnet])：
slo:: {target: 0.99,error_ratio_threshold: 0.01,latency_percentile: 90,latency_threshold: 200, },找到 SLI
Kubernetes API 公開了幾個我們可以作為 SLI 使用的指標，使用 Prometheus rate()函數在短時間內 (這里我們選擇 5min，這個數字應該是抓取間隔的幾倍)：
-
apiserver_request_count：按verb、code、resource對所有請求進行計數，例如，獲得最近 5 分鐘的總錯誤率：
上面的公式放棄了所有的指標標簽 (例如，通過 httpverb、code)。如果你想保留一些標簽，你需要做如下的事情：
sum by (verb, code) (rate(apiserver_request_count{code=~"5.."}[5m]))/ ignoring (verb, code) group_left sum (rate(apiserver_request_count[5m]))-
apiserver_request_latencies_bucket：由動詞表示的延遲直方圖。例如，要獲得以毫秒為單位的第 90 個延遲分位數: (注意，le“less or equal”標簽是特殊的，因為它設置了直方圖桶間隔，參見 [Prometheus 直方圖和摘要][promql- 直方圖])：
在這里了解更多的：
-
bitnami-labs/kubernetes-grafana-dashboards
-
spec-kubeapi.jsonnet
-
promql-histogram
編寫 Prometheus 規則記錄所選 SLI
PromQL 是一種非常強大的語言，盡管截至 2018 年 10 月，它還不支持范圍的嵌套子查詢。我們需要能夠計算error ratio或超出閾值的latency的time ratio。
另外，作為一種良好的實踐，為了減少查詢 Prometheus 資源使用的時間，建議在諸如sum(rate(…))之類的預計算表達式中添加記錄規則。
舉一個例子來說明如何做到這一點，下面的一組記錄規則是從我們的 [bitnami-labs/kubernetes-grafana-dashboards] 存儲庫中構建的，用于捕獲上面的time ratio：
創建一個新的kubernetes: job_verb- code_instance:apiserver_requests:rate5m指標來記錄請求 速率：
record: kubernetes:job_verb_code_instance:apiserver_requests:rate5m expr: |sum by(job, verb, code, instance) (rate(apiserver_request_count[5m]))-
使用上面的度量，為請求的比率（總的）創建一個新的kubernetes: job_verb-code_instance:apiserver_requests:ratio_rate5m?：
-
使用上面的比率指標 (對于每個 http?code和verb)，創建一個新的指標來捕獲?錯誤率：
-
使用上面的錯誤率 (以及其他類似創建的kubernetes::job:apiserver_latency:pctl90rate5m，用于記錄過去 5 分鐘內的第 90 個百分位延遲，為簡單起見，未在上面顯示)，最后創建一個布爾指標來記錄 SLO 遵從性情況：
編寫 Prometheus 警報規則
上述kubernetes::job:slo_kube_api_ok最終指標對于儀表板和 SLO 遵從性的解釋非常有用，但是我們應該警惕上面哪個指標導致 SLO 消失，如下面的 Prometheus 警報規則所示：
-
高 API 錯誤率警告：
-
高 API 延遲警報
請注意，Prometheus 來自已經顯示的 jsonnet 輸出，閾值可以分別從$.slo.error_ratio_threshold和$.slo.latency_threshold中評估得出。
以編程方式創建 Grafana 儀表板
創建 Grafana 儀表板通常是通過與 UI 交互來完成的。這對于簡單的和 / 或“標準”儀表板（例如，從 https://grafana.com/dashboards ) 下載）來說是很好的，但是如果你想要實現最好的 devops 實踐，特別是對于 gitops 工作流，就變得很麻煩了。
社區正在通過各種努力來解決這個問題，例如針對 jsonnet、python 和 Javascript 的 Grafana 庫。考慮到我們的jsonnet實現，我們選擇了 grafonnet-lib。
使用jsonnet來設置 SLO 閾值和編碼 Prometheus 規則的一個非常有用的結果是，我們可以再次使用它們來構建 Grafana 儀表板，而不必復制和粘貼它們，也就是說，我們為這些保留了一個真實的來源。
例如:
-
關于$.slo.error_ratio_threshold，在我們的 Grafana 儀表板中設置 error_ratio_threshold 來設置 Grafana 圖形面板的閾值屬性，就像我們在前面為 Prometheus 警報規則所做的那樣。
-
記錄metric.rules.requests_ratiorate_job_verb_code.record使用情況 (而不是'kubernetes: job_verb_code_instance:apiserver_requests:ratio_rate5m')：
你可以在 dash-kubeapi.jsonnet 上了解我們的實現情況，下面是生成的儀表板的屏幕截圖：
總結? ?
我們在jsonnet文件夾下的 bitnami-labs/ kubernets-grafana -dashboards 存儲庫中實現了上述想法。
我們構建的 Prometheus 規則和 Grafana 儀表盤文件來自 jsonnet，如下所示：
-
[spec-kubeapi.[jsonnet]：盡可能多的數據規范 (閾值、規則和儀表板公式)
-
rules-kubeapi.jsonnet：輸出 Prometheus 記錄規則和警報
-
dash-kubeapi.jsonnet：輸出 Grafana 儀表盤，通過我們選擇的 bitnami_grafana.libsonnet 使用?grafonnet-lib。
-
英文原文：https://engineering.bitnami.com/articles/implementing-slos-using-prometheus.html
總結
以上是生活随笔為你收集整理的目标4个9的可用性？试试用 Prometheus 和 Grafana记录服务可用时间的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 解决eclipse显示jar源代码中文乱
- 下一篇： SAP并购史