Kubernetes 穩定性保障手冊 -- 可觀測性專題

做者 | 悟鵬
來源 | 阿里巴巴雲原生公衆號

《Kubernetes 穩定性保障手冊》系列文章：

• Kubernetes 穩定性保障手冊 -- 極簡版
• Kubernetes 穩定性保障手冊 -- 日誌專題
• Kubernetes 穩定性保障手冊 -- 可觀測性專題（本文）

伴隨你們對穩定性重視程度的不斷提高、社區可觀測性項目的火熱，可觀測性成爲了一個很熱門的話題，站在不一樣的角度會產生不一樣的理解。

咱們從軟件開發的生命週期出發，嘗試造成對可觀測性的一個宏觀理解，並從 SRE 和 Serverless 兩個角度具化可觀測性的理解以及實踐。

目的

• 加強認知，經過全局把握來提高競爭力
• 經過合理的設計和實踐，爲將來帶來可能性

目標

• 針對可觀測性的理解達成一致
• 針對可觀測性的發展方向達成一致

什麼是可觀測性？

從 wikipedia: Observability 可理解到 可觀測性 的定義：

In control theory, observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs.

Consider a physical system modeled in state-space representation. A system is said to be observable if, for any possible evolution of state and control vectors, the current state can be estimated using only the information from outputs (physically, this generally corresponds to information obtained by sensors). In other words, one can determine the behavior of the entire system from the system's outputs. On the other hand, if the system is not observable, there are state trajectories that are not distinguishable by only measuring the outputs.

簡單表述爲，可觀測性是一種方法，經過系統的外部輸出推導出系統內部的狀態。

下圖簡化了系統的組成和系統間的交互：

從上述交互圖可瞭解到，系統的交互行爲有以下幾種形態：

• 系統內部

  • 組件功能閉環，不與其餘組件或系統交互
  • 組件之間交互

• 系統之間

  • 系統和系統之間進行交互

這樣，經過以下兩種形態的信息，就能夠經過系統的外部輸出瞭解到系統的內部狀態：

• 組件閉環的信息
• 組件間或系統間流動的信息

可觀測性的問題域是什麼？

可觀測性的核心在於 經過觀測數據、知足不一樣人羣、對於系統狀態的理解需求，這裏先抽象觀測數據的生命週期，有以下圖示：

觀測數據經過 App 生成，通過中間處理環節後進行存儲，而後提供查詢服務。

觀測數據服務於不一樣類型的人羣，如產品的用戶、業務、研發、SRE，不一樣的人羣經過不一樣的形態來使用這些數據，包括 SLA / SLO / SLI / Alert 等。

根據可觀測數據的生命週期，可粗略總結可觀測性的問題域：

• 生成端

  • 觀測數據的數據模型
  • 觀測數據的生成
  • 觀測數據的導出

• 處理端

  • 觀測數據的採集
  • 觀測數據的處理
  • 觀測數據的導出

• 存儲端

  • 觀測數據的存儲
  • 觀測數據的查詢
  • 觀測數據的使用

• 使用端

  • 觀測數據的消費

軟件開發生命週期中，可觀測性的服務目標是什麼？

從項目總體視角來看軟件開發的生命週期，有以下的流程：

細化下來：

在軟件開發生命週期中，有 4 類角色。面對 4 類角色，可觀測性的服務目標會有差別：

Note:

• 可靠 與 穩定 不是等同的關係，可靠 包含了 穩定+及時知足功能需求 特徵

SRE 能夠投入的方向

基礎服務：

能夠將 OpenTelemetry 做爲基礎落地上述事項，參見：《OpenTelemetry 簡析》。

與此同時，能夠探索可視化的穩定性保障服務，從全局視角加快問題發現、定位、解決，一張圖把握集羣中「組件自身」和「組件之間交互」的健康狀態 ，形以下圖：

以此爲入口，從總體把握集羣狀態，關聯異常信息，處理問題時有的放矢。

Serverless 場景下可觀測性

Serverless 是目前頗有前景的雲上計算形態，阿里雲提供了比較完整的 Serverless 計算產品，以下：

不一樣 Serverless 計算環境的一個主要差別點在於運行環境的持續時間，以此爲出發點，能夠抽象出 Serverless 計算環境中可觀測性的核心，而後分解出相應的解決方案：

根據運行環境持續時長的不一樣，可粗略劃分爲 3 類：

• 天級別
• 小時級別
• 分鐘或秒級別

這些運行環境都可以經過虛擬機、容器或 WebAssembly 等技術實現，區別點在於業務層面限定的運行環境持續時長。

根據運行環境持續時長的特徵，平臺和用戶的關注核心會有相應的變化：

• 天級別的運行環境，平臺方的核心在於提供可靠的運行環境，由用戶自由管理應用

  • 對於可觀測性，平臺方核心在於運行環境可靠性，用戶核心在於應用環境穩定性和請求響應性能

• 小時級別的運行環境，平臺方的核心在於圍繞應用提供管理服務，用戶聚焦於業務自身

  • 對於可觀測性，平臺方核心在於應用運行穩定性和請求響應性能，用戶核心在於業務特徵
• 分鐘或秒級別的運行環境，平臺方的核心在於細粒度的用戶業務邏輯管理，用戶更聚焦在業務的敏感特徵
  • 對於可觀測性，平臺方核心在於請求響應可靠性和業務特徵，用戶核心在於核心業務特徵

對於 FaaS 場景，THUNDRA 公司 的 demo 提供了比較好的示例以供參考 (截取 3 個示例)：

• 函數

• 應用

• 架構

小結

經過對可觀測性概念、問題域、不一樣層級需求等造成深刻理解，能夠造成對可觀測性的理解大圖，而後在此基礎上與業務結合，加強業務在可觀測性方面的競爭力，同時迭代理解，技術與業務相互促進。

References

• wikipedia: Observability
• wikipedia: Service-level objective
• wikipedia: Service-level agreement
• wikipedia: Service level
• Google-Wide Profiling: A Continuous Profiling Infrastructure for Data Centers
• conprof - Continuous Profiling
• OpenTelemetry Proposal issues: Adding profiling as a support event type
• Kubernetes scalability and performance SLIs/SLOs
• 從 DevOps 到 NoOps，Serverless 技術的落地方式探討