Kubernetes 稳定性保障手册 -- 可观测性专题，今晚我们通宵学习 SpringCloud

从上述交互图可了解到，系统的交互行为有如下几种形态：

• 系统内部

• 组件功能闭环，不与其他组件或系统交互

• 组件之间交互

• 系统之间

• 系统和系统之间进行交互

这样，通过如下两种形态的信息，就可以通过系统的外部输出了解到系统的内部状态：

• 组件闭环的信息

• 组件间或系统间流动的信息

可观测性的问题域是什么？

可观测性的核心在于 通过观测数据、满足不同人群、对于系统状态的理解需求，这里先抽象观测数据的生命周期，有如下图示：

观测数据通过 App 生成，经过中间处理环节后进行存储，然后提供查询服务。

观测数据服务于不同类型的人群，如产品的用户、业务、研发、SRE，不同的人群通过不同的形态来使用这些数据，包括 SLA / SLO / SLI / Alert 等。

根据可观测数据的生命周期，可粗略总结可观测性的问题域：

• 生成端

• 观测数据的数据模型

• 观测数据的生成

• 观测数据的导出

• 处理端

• 观测数据的采集

• 观测数据的处理

• 观测数据的导出

• 存储端

• 观测数据的存储

• 观测数据的查询

• 观测数据的使用

• 使用端

• 观测数据的消费

软件开发生命周期中，可观测性的服务目标是什么？

从项目整体视角来看软件开发的生命周期，有如下的流程：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nslyMlQx-1617331290052)(https://static001.geekbang.org/infoq/79/794559f8f2b3713f716df62b2c98e5b2.png)]

细化下来：

在软件开发生命周期中，有 4 类角色。面对 4 类角色，可观测性的服务目标会有差异：

Note:

• 可靠 与 稳定 不是等同的关系，可靠 包含了 稳定+及时满足功能需求 特征

SRE 可以投入的方向

基础服务：

可以将 OpenTelemetry 作为基础落地上述事项，参见：《OpenTelemetry 简析》。

与此同时，可以探索可视化的稳定性保障服务，从全局视角加快问题发现、定位、解决，一张图把握集群中「组件自身」和「组件之间交互」的健康状态 ，形如下图：

以此为入口，从整体把握集群状态，关联异常信息，处理问题时有的放矢。

Serverless 场景下可观测性

Serverless 是目前很有前景的云上计算形态，阿里云提供了比较完整的 Serverless 计算产品，如下：

不同 Serverless 计算环境的一个主要差异点在于运行环境的持续时间，以此为出发点，可以抽象出 Serverless 计算环境中可观测性的核心，然后分解出相应的解决方案：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0PFJx0ra-1617331290060)(https://static001.geekbang.org/infoq/78/782738592dc0fa6b15606541c4b8816c.png)]

根据运行环境持续时长的不同，可粗略划分为 3 类：

• 天级别

• 小时级别

• 分钟或秒级别

这些运行环境均可以通过虚拟机、容器或 WebAssembly 等技术实现，区别点在于业务层面限定的运行环境持续时长。

根据运行环境持续时长的特征，平台和用户的关注核心会有相应的变化：

• 天级别的运行环境，平台方的核心在于提供可靠的运行环境，由用户自由管理应用

• 对于可观测性，平台方核心在于运行环境可靠性，用户核心在于应用环境稳定性和请求响应性能

• 小时级别的运行环境，平台方的核心在于围绕应用提供管理服务，用户聚焦于业务自身

• 对于可观测性，平台方核心在于应用运行稳定性和请求响应性能，用户核心在于业务特征

• 分钟或秒级别的运行环境，平台方的核心在于细粒度的用户业务逻辑管理，用户更聚焦在业务的敏感特征

• 对于可观测性，平台方核心在于请求响应可靠性和业务特征，用户核心在于核心业务特征

对于 FaaS 场景，THUNDRA 公司 的 demo 提供了比较好的示例以供参考 (截取 3 个示例)：

• 函数

• 应用

• 架构