作者 | 悟鵬
來源 | 阿里巴巴云原生公眾號

《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 等。

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

• 生成端

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

• 處理端

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

• 存儲端

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

• 使用端

  • 觀測數據的消費

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

從項目整體視角來看軟件開發的生命周期，有如下的流程：

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-nslyMlQx-1617331290052)(https://ucc.alicdn.com/pic/developer-ecology/7d8633ef2801470184bb95596e350311.png)]

細化下來：

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

Note:

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

SRE 可以投入的方向

基礎服務：

可以將 OpenTelemetry 作為基礎落地上述事項，參見：《OpenTelemetry 簡析》。

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

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

Serverless 場景下可觀測性

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

不同 Serverless 計算環境的一個主要差異點在于運行環境的持續時間，以此為出發點，可以抽象出 Serverless 計算環境中可觀測性的核心，然后分解出相應的解決方案：

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-0PFJx0ra-1617331290060)(https://ucc.alicdn.com/pic/developer-ecology/51b3f393b3a14e59a401c959148c9b13.png)]

根據運行環境持續時長的不同，可粗略劃分為 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 技術的落地方式探討

歡迎大家留言交流使用 Kubernetes 過程中的穩定性保障問題，以及對穩定性保障的期待工具或服務。大家也可通過郵箱聯系作者，進一步深入交流：flyer.zyf@alibaba-inc.com。

總結

以上是生活随笔為你收集整理的Kubernetes 稳定性保障手册 -- 可观测性专题的全部內容，希望文章能夠幫你解決所遇到的問題。

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