可观测性 — Overview

Posted 2022-08-17 范桂飓

目录

文章目录

• 目录
• 云原生可观测性的背景
• 云原生可观测性与传统监控的区别
• 可观测性的维度
• • 基础设施层
  • 业务层
• 可观测性系统的技术栈
• • 可观测性的数据结构类型
  • 可观测性的系统组件
• CNCF OpenTelemetry
• 可观测性系统的应用场景

云原生可观测性的背景

在云原生时代，基础设施与 Application 的构建和部署都发生了极大变化，例如：架构微服务化、运行时环境容器化、业务系统依赖关系复杂化，运行实例生命周期短等等。随着 Cloud Native Application 得规模不断扩大，复杂度愈来愈高，而其中潜藏的问题和风险也随之增多。

所以，云原生时代的监控要求可以进行实时动态的调整，而传统预先配置再监控的方式已经无法适应云原生的场景。在这个背景下，2018 年 CNCF 社区引入了云原生可观测性（Observability）这一理念。

可观测性概念最早由 Apple 工程师 Cindy Sridharan 提出，作为监控的进一步延伸，可观测性与监控的区别可以总结为：“监控告诉我们系统的哪些部分是工作的，而可观测性告诉我们哪里为什么不工作了。”

谷歌给出可观测性的核心价值很简单 —— 快速排障（Troubleshooting）。

可观测性是云原生场景必不可少的一环，关系到云原生实践能否在生产环境顺利实施。

云原生可观测性与传统监控的区别

云原生可观测性由传统监控演进而来。但传统监控是面向运维的，从系统外部视角去观察系统的运行状态；而云原生可观测性是从系统内部出发，基于 “白盒化” 的思路去监测系统内部的运行情况。

可观测性贯穿了 Application 从开发诞生到下线消亡的整个生命周期，包括开发、测试、上线、部署、发布。通过分析 Application 的 Metrics（指标）、Traces（链路）、Logs（日志）等数据，构建完整的观测模型，从而实现故障诊断、根因分析和快速恢复。

所以，云原生可观测性不仅包含了传统监控的能力，更多的是面向业务，强调将业务全过程透明化的理念。

可观测性的维度

基础设施层

从基础设施层来看，这里的可观测性与传统的主机监控有一些相似和重合的地方，比如：计算、存储、网络等主机资源的监控，对进程、磁盘 IO、网络流量等系统指标的监控等。

对于云原生的可观测性，这些传统的监控指标依然存在，但是考虑到云原生中采用的容器、服务网格、微服务等新技术、新架构，其可观测性又会有新的需求和挑战。例如，在资源层面要实现 CPU、内存等在容器、Pod、Service、Tenant 等不同层的识别和映射；在进程的监控上要能够精准识别到容器，甚至还要细化到进程的系统调用、内核功能调用等层面；在网络上，除了主机物理网络之外，还要包括 Pod 之间的虚拟化网络，甚至是应用之间的 Mesh 网络流量的观测。

业务层

从应用层来看，在微服务架构下，主机上的应用变得异常复杂，这既包括应用本身的平均延时、应用间的 API 调用链、调用参数等，还包括应用所承载的业务信息，比如业务调用逻辑、参数等信息。

可观测性系统的技术栈

可观测性的数据结构类型

当前，主流的可观测性系统主要基于 Metrics（指标）、Tracing（链路）、Logging（日志）三大数据类型构建，基本涵盖了一个 Application 所能产生的大部分可观测性数据，足以让开发运维人员洞察 Application 的运行状态。

• Metrics：主要用于监控告警（Monitoring & Alert）场景，通常存储在时序数据库。
• Tracing：主要用于业务依赖调研链的链路追踪（Tracing）场景，通常存储在日志数据库。
• Logging：主要用于日志审计（Logging）场景，通常存储在日志数据库。

2017 年，Peter Bourgon 在参加了 Distributed Tracing Summit 后发表的一篇博文，简要地介绍了 Metrics、Tracing、Logging 三者的定义和关系。这三种数据在可观测性中都有各自的发挥空间，每种数据都没办法完全被其他数据代替。

可观测性的系统组件

在 CNCF Landscape 中，可观测性的相关产品被分为 Monitoring（监控告警）、Tracing（链路追踪）、Logging（日志审计）三大类，这些产品有开源的，也有商业的，比如：

• Monitoring：Prometheus、Cortex、Zabbix、Grafana、Sysdig 等。
• Tracing：Jaeger、zipkin、SkyWalking、OpenTracing、OpenCensus 等。
• Logging：Loki、ELK、Fluentd、Splunk 等。

CNCF OpenTelemetry

利用上述 Monitoring、Tracing、Logging 三大类产品的组合，用户可以比较快速的搭建出一个可观测性系统。但是，针对 Metrics、Traces、Logs 三大类数据格式，用户往往需要搭建三套独立的系统，并且内部涉及的组件更多，维护成本很高。

中国信通院《可观测性技术发展白皮书》指出，可观测平台能力的构建，需要具备统一数据模型、统一数据处理、统一数据分析、数据编排、数据展示的能力。

针对这个问题，CNCF 推出了 OpenTelemetry 项目。该项目雄心勃勃，旨在统一 Metrics、Logs、Traces 三种数据，实现可观测性大一统。

OpenTelemetry 的诞生给云原生可观测性带来革命性的进步，包括：

• 统一协议：OpenTelemetry 带来了 Metrics、Traces、Logs（规划中）的统一标准，三者都有相同的元数据结构，可以轻松实现互相关联。
• 统一 Agent：使用一个 Agent 即可完成所有可观察性数据的采集和传输，不需要为每个系统都部署各种各样的 Agent，大大降低了系统的资源占用，使整体可观察性系统的架构也变的更加简单。
• 云原生友好：OpenTelemetry 诞生在 CNCF，对于各类的云原生下的系统支持更加友好，此外目前众多云厂商已经宣布支持 OpenTelemetry，未来云上的使用会更加便捷。
• 厂商无关：此项目完全中立，不倾向于任何一家厂商，让大家可以有充分的自由来选择、更换适合自己的服务提供商，而不需要收到某些厂商的垄断或者绑定。
• 兼容性：OpenTelemetry 得到了 CNCF 下各种可观察性方案的支持，未来对于 OpenTracing、OpenCensus、Prometheus、Fluntd 等都会有非常好的兼容性，可以方便大家无缝迁移到 OpenTelemetry 方案上。

OpenTelemetry 最核心的功能是产生、收集可观测性数据，并支持传输到各种的分析软件中。整体的架构如下图所示，其中：

• OTel API/SDK：用于产生统一格式的可观测性数据。
• OTel Collector：用来接收这些可观测性数据，并支持把数据传输到各种类型的后端系统。

OpenTelemetry 定位是作为可观测性的基础设施，解决数据产生、采集、传输的问题。但是目前数据的存储与分析还是依赖各个后端系统，导致无法对全部数据进行统一展示与关联分析。

最理想的情况是能有一个后端引擎同时存储所有的 Metrics、Logs、Traces 数据，并进行统一的分析、关联、可视化。现在已经有一些厂商开始相关的尝试。比如 Grafana Labs 推出的 Loki，其主要设计理念来源于 Prometheus。通过 Loki, 用户可以像分析 Prometheus 指标一样分析日志，也可以基于相同的 Labels 来关联 Metrics 和 Logs 数据。

如下图所示，在同一个 Grafana 面板中，左右分别展示了相关的 Metrics 和 Logs，用户可以方便的对数据进行关联分析。

可观测性系统的应用场景

1. 应用发布部署

2. 全景监测

3. 智能告警

4. 性能诊断

5. 等保 2.0 四级要求：尤其对应用可信提出了明确的动态验证需求，如何在不影响应用的功能、性能，保证用户体验的前提下，做到应用的动态可信验证成为重要的挑战。在云原生中，解决这个问题的核心在于准确地选择应用的可信度量对象，高性能地确定指标的度量值，以及收集和管理验证这些基准值，这些都是对云原生实现可观测的重要意义和应用价值。