关于云原生:Kubernetes-稳定性保障手册-可观测性专题

4次阅读

共计 2819 个字符,预计需要花费 8 分钟才能阅读完成。

作者 | 悟鹏
起源 | 阿里巴巴云原生公众号

《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 技术的落地形式探讨

欢送大家留言交换应用 Kubernetes 过程中的稳定性保障问题,以及对稳定性保障的期待工具或服务。大家也可通过邮箱分割作者,进一步深刻交换:flyer.zyf@alibaba-inc.com

正文完
 0