作者 | 悟鵬
來源 |
阿裡巴巴雲原生公衆号《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: 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 過程中的穩定性保障問題，以及對穩定性保障的期待工具或服務。大家也可通過郵箱聯系作者，進一步深入交流：[email protected]。