2022 年 1 月 14 日，第六期阿里云用户组 AUG 活动在北京举行。现场，阿里云技术专家张城详细阐述了什么是可观测，并讲解了 SLS 可观测与 AIOps 的整体架构。本文根据演讲内容整理而成。

云原生可观测融合分析

电器工程的可观测性

首先，什么叫做可观测，可观测性这个概念最早出现于 20 世纪 70 年代的电气工程，核心的定义是：

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.

相比传统的告警、监控，可观测性能够以更加“白盒”的方式看透整个复杂的系统，帮助我们更好地观察系统的运行状况，快速定位和解决问题。就像发动机而言，告警只是告诉你发动机是否有问题，而一些包含转速、温度、压力的仪表盘能够帮我们大致确定是哪个部分可能有问题，而真正定位细节问题还需要观察每个部件的传感器数据才行。

电器化时代可观测发展背景
电气化时代起源于19 世纪70年代的第二次工业革命（Second Industrial Revolution），主要的标志是电力、内燃机的广泛应用。而可观测性这一概念为何在近 100 年后才会被提出？难道在此之前就不需要依赖各类传感器的输出定位和排查故障？显然不是，排查故障的方式一直都在，只是整个系统和情况更加复杂，所以才需要更加体系化、系统化的方式来支持这一过程，因此演化出来可观测性这个概念。所以核心点在于：

• 系统更加的复杂：以前的汽车只需要一个发动机、传送带、车辆、刹车就可以跑起来，现在汽车上至少有上百个部件和系统，故障的定位难度变得更大。
• 开发涉及更多的人：随着全球化时代的到来，公司的分工也越来越细，意味着系统的开发和维护需要更多的部门和人来共同完成，协调的代价越来越大。
• 运行环境多种多样：不同运行环境下，每个系统的工作情况是变化的，我们需要在任何阶段都能有效记录好系统的状态，便于我们分析问题、优化产品。

IT系统的可观测性

IT 系统经过几十年的飞速发展，整个开发模式、系统架构、部署模式、基础设施等也都经过了好几轮的优化，优化带来了更快的开发、部署效率，但随之而来整个系统也变得更加复杂、开发需要依赖更多的人和部门、部署模式和运行环境也更加动态和不确定，因此 IT 行业已经到了需要更加系统化、体系化进行观测的这一阶段。

IT 系统的可观测性实施起来其实和电气工程比较类似，核心还是观察我们各个系统、应用的输出，通过数据来判断整体的工作状态。通常我们会把这些输出进行分类，总结为 Traces、Metrics、Logs。关于这三种数据的特点、应用场景以及关系等，会在后面进行详细展开。

自动驾驶

电气工程的可观测由于有深厚的发展历史，可以在实践中给到我们非常多的支持，自动驾驶也是如此。自动驾驶从刚开始的定速巡航、自适应巡航开始，已经发展了几十年，目前对于自动驾驶也有一些可以在实际道路中应用的场景。电器领域的一个集大成者，就是自动驾驶。现在真正可能让自动驾驶落地的，也就是特斯拉最早开创的一套新的架构。

我们可以回过头来去看，特斯拉为什么和传统自动驾驶厂商不同，我觉得主要有以下几点：

1. 丰富的数据源：汽车外围遍布多个激光/图像雷达，能够实现高帧率、360°实时观测周围的物体及其状态；内部则能够实时知道当前的车速、车轮角度、胎压等信息，做到知彼知己。
2. 数据集中化：相对辅助驾驶能力，自动驾驶的一个核心突破是能够将车内外的所有数据集中到一起去处理，真正发挥出数据的价值，而不是每个模块的数据作为孤岛进行独立运作。
3. 强大算力：集中化的数据也意味着数据量的急剧膨胀，无论哪家自动驾驶背后都有强大的芯片支撑，只有足够的算力才能保证在最短的时间内可以进行足够的计算。
4. 软件迭代：算力+算法构成了智能化的最终目标，然而算法不可能完美无瑕，会根据逐渐积累的自动驾驶数据不断进行算法的升级，从而使软件系统能够不断升级以获得更佳的自动驾驶效果。

自动驾驶与 AIOps 分级

我们团队从 2009 年做飞天 5K 项目起，就一直在负责监控、日志、分布式链路追踪等可观察性相关的工作，中间经历过小型机到分布式系统再到微服务、云化的一些架构变更，相关的可观察性方案也经历了很多演变。我们觉得整体上可观察性相关的发展和自动驾驶等级的设定非常吻合。

自动驾驶一共分为 6 级，其中 0-2 级主要还是靠人来进行决定，到了等级 3 之后就可以进行无意识驾驶，也就是手眼可以暂时性不用关注驾驶，到了等级 5 的话人就可以完全脱离驾驶这个枯燥的工作，在车上可以自由活动。

在 IT 系统的可观察性上，也可以类似划分为 6 级：

• 等级0：手工分析，依靠基础的 Dashboard、告警、日志查询、分布式链路追踪等方式进行手动告警、分析，也是目前绝大部分公司使用的场景。
• 等级1：智能告警，能够自动去扫描所有的可观察性数据，利用机器学习的方式去识别一些异常并进行自动告警，免去人工设置/调整各种基线告警的工作。
• 等级2：异常关联+统一视图，对于自动识别的异常，能够进行上下文的关联，形成一个统一的业务视图，便于快速地定位问题。
• 等级3：根因分析+问题自愈，自动根据异常以及系统的 CMDB 信息直接定位问题的根因，根因定位准确后可以去做问题的自愈。这一阶段相当于是一次质的飞跃，在某些场景下可以在人不用参与的情况下实现问题的自愈。
• 等级4：故障预测，故障发生总会有损失，所以最好的情况是避免故障的发生，因此故障预测技术可以更好地保证系统的可靠性，利用之前积累的一些故障先兆信息做到“未卜先知”。
• 等级5：变更影响预测，我们知道绝大部分的故障都是由变更引起的，因此如果能够模拟出每个变更对系统带来的影响以及可能产生的问题，我们就能够提前评估出是否能够允许此次变更。
  

可观测性与智能运维落地

可观测性方案落地上，现阶段可能无法做出一个适用于各个行业属性的可观测引擎，更多是专注于 DevOps 和通用的公司商业方面。这里面的两个核心工作是：

• 数据覆盖面足够全：能够包括各类不同场景、不同类型的数据，除了狭义的日志、监控、Trace 外，还需要包括我们的 CMDB、变更数据、客户信息、订单/交易信息、网络流、API 调用等；
• 数据关联与统一分析：数据价值的发掘不是简单通过一种数据来实现，更多时候我们需要利用多种数据关联来达到目的，例如结合用户的信息表以及访问日志，我们可以分析不同年龄段、性别的用户的行为特点，针对性地进行推荐；通过登录日志、CMDB 等，结合规则引擎，来实现安全类的攻击检测。
  

从整个流程来看，我们可以将可观测性的工作划分为 4 个组成部分：

1. 传感器：获取数据的前提是要有足够的传感器来产生数据，这些传感器在 IT 领域的形态有：SDK、埋点、外部探针等。
2. 数据：传感器产生数据后，我们需要有足够的能力去获取、收集各种类型的数据，并把这些数据归类分析。
3. 算力：可观测场景的核心是需要覆盖足够多的数据，数据一定是海量的，因此系统需要有足够的算力来计算和分析这些数据。
4. 算法：可观测场景的终极应用是数据的价值发掘，因此需要使用到各类算法，包括一些基础的数值类算法、各种 AIOps
   相关的算法以及这些算法的组合。

SLS 可观测与 AIOps 整体架构

基于上述我们的一些思考，回归到可观测这个问题的本质，我们目标的可观测性方案需要能够满足以下几点：

• 数据全面覆盖：包括各类的可观测数据以及支持从各个端、系统中采集数据；
• 统一的系统：拒绝割裂，能够在一个系统中支持 Traces、Metrics、Logs 的统一存储与分析；
• 数据可关联：每种数据内部可以互相关联，也支持跨数据类型的关联，能够用一套分析语言把各类数据进行融合分析；
• 足够的算力：分布式、可扩展，面对 PB 级的数据，也能有足够的算力去分析；
• 灵活智能的算法：除了基础的算法外，还应包括 AIOps 相关的异常检测、预测类的算法，并且支持对这些算法进行编排。

可观测数据引擎的整体架构如下图所示，从下到上的四层也基本符合方案落地的指导思想：传感器+数据+算力+算法。

• 传感器：数据源以 OpenTelemetry 为核心，并且支持各类数据形态、设备/端、数据格式的采集，覆盖面足够的“广”；
• 数据+算力：采集上来的数据，首先会进入到我们的管道系统（类似于Kafka），根据不同的数据类型构建不同的索引，目前每天我们的平台会有几十 PB 的新数据写入并存储。除了常见的查询和分析能力外，我们还内置了 ETL 的功能，负责对数据进行清洗和格式化，同时支持对接外部的流计算和离线计算系统；
• 算法：除了基础的数值算法外，目前我们支持了十多种的异常检测/预测算法，并且还支持流式异常检测；同时也支持使用 Scheduled SQL 进行数据的编排，帮助我们产生更多新的数据；
• 价值发掘：价值发掘过程主要通过可视化、告警、交互式分析等人机交互来实现，同时也提供了 OpenAPI 来对接外部系统或者供用户来实现一些自定义的功能。

可观测融合分析引擎

下面讲一下我们说的那个引擎，为什么 SLS 要做一个可观测的引擎呢？

如果把存储引擎比喻成新鲜的食材，那分析引擎就是处理这些食材的刀具，针对不同类型的食材，用不同种类的刀来处理才能得到最好的效果，例如蔬菜用切片刀、排骨用斩骨刀、水果用削皮刀等。同样，针对不同类型的可观测数据和场景，也有对应适合的分析方式：

1. Metrics：通常用于告警和图形化展示，一般直接获取或者辅以简单的计算，例如 PromQL、TSQL 等。
2. Traces/Logs：最简单直接的方式是关键词的查询，包括 TraceID 查询也只是关键词查询的特例。
3. 数据分析(一般针对 Traces、Logs)：通常 Traces、Logs
   还会用于数据分析和挖掘，所以要使用图灵完备的语言，一般程序员接受最广的是 SQL。
   

上述的分析方式都有对应的适用场景，我们很难用一种语法/语言去实现所有的功能并且具有非常好的便捷性（虽然通过扩展 SQL 可以实现类似 PromQL、关键词查询的能力，但是写一个简单的 PromQL 算子可能要用一大串 SQL 才能实现），因此我们的分析引擎选择去兼容关键词查询、PromQL 的语法。同时为了便于将各类可观测数据进行关联起来，我们在 SQL 的基础上，实现了可以连接关键词查询、PromQL、外部的 DB、ML 模型的能力，让 SQL 成为顶层分析语言，实现可观测数据的融合分析能力。

融合分析能力示例

下面举几个我们查询/分析的应用示例，前面 3 个相对比较简单，可以用纯粹的关键词查询、PromQL，也可以结合 SQL 一起使用。最后1个展示了实际场景中进行融合分析的例子：

• 背景：线上发现有支付失败的错误，需要分析这些出现支付失败错误的机器 CPU 指标有没有问题

实现

• 首先查询机器的 CPU 指标
• 关联机器的 Region 信息（需要排查是否某个 Region 出现问题）
• 和日志中出现支付失败的机器进行 Join，只关心这些机器
• 最后应用时序异常检测算法来快速分析这些机器的 CPU 指标
• 最后的结果使用线图进行可视化，结果展示更加直观

上述的例子同时查询了 LogStore、MetricStore，而且关联 CMDB 以及 ML 模型，一个语句实现了非常复杂的分析效果，在实际的场景中还是经常出现的，尤其是分析一些比较复杂的应用和异常。

数据编排-价值挖掘

可观测性相比传统监控，更多还是在于数据价值的发掘能力更强，能够仅通过输出来推断系统的运行状态，和数据挖掘这个工作比较像，收集各类繁杂的数据、格式化、预处理、分析、检验，最后根据得到的结论去“讲故事”。

因此，在可观测性引擎的建设上，我们非常关注数据编排的能力，能够让数据流转起来，从茫茫的原始日志中不断地提取出价值更高的数据，最终告诉我们系统是否在工作以及为什么不工作。为了让数据能够“流转”起来，我们开发了几个功能：

• 数据加工：也就是大数据 ETL（extract, transform, and load）中T的功能，能够帮我们把非结构化、半结构化的数据处理成结构化的数据，更加容易分析。
• Scheduled SQL：顾名思义，就是定期运行的 SQL，核心思想是把庞大的数据精简化，更加利于查询，例如通过 AccessLog 每分钟定期计算网站的访问请求、按 APP、Region 粒度聚合 CPU、内存指标、定期计算 Trace 拓扑等。
• AIOps 巡检：针对时序数据特别开发的基于时序异常算法的巡检能力，用机器和算力帮我们去检查到底是哪个指标的哪个维度出现问题。

基于编排的故障自动定位

可观测性的前期阶段，很多工作都需要人工来完成，我们最希望的还是能有一套自动化的系统，在出现问题的时候能够基于这些观测的数据自动进行异常诊断，得到一个可靠的根因并能够根据根因进行自动的 Fix。现阶段，自动异常恢复很难做到，但根因的定位通过一定的算法和编排手段还是可以实施的。

上图是一个典型的 IT 系统架构的观测抽象，每个 APP 都会有自己的黄金指标、业务的访问日志/错误日志、基础监控指标、调用中间件的指标、关联的中间件自身指标/日志，同时通过 Trace 还可以得到上下游 APP/服务的依赖关系。通过这些数据再结合一些算法和编排手段就可以进行一定程度的自动化根因分析了。这里核心依赖的几点如下：

• 关联关系：通过 Trace 可以计算出 APP/服务之间的依赖关系；通过 CMDB 信息可以得到 APP 和 PaaS、IaaS 之间的依赖关系。通过关联关系就可以“顺藤摸瓜”，找到出现问题的原因。
• 时序异常检测算法：自动检测某一条、某组曲线是否有异常，包括 ARMA、KSigma、Time2Graph 等，详细的算法可以参考：异常检测算法、流式异常检测。
• 日志聚类分析：将相似度高的日志聚合，提取共同的日志模式（Pattern），快速掌握日志全貌，同时利用 Pattern 的对比功能，对比正常/异常时间段的 Pattern，快速找到日志中的异常。

时序、日志的异常分析能够帮我们确定某个组件是否存在问题，而关联关系能够让我们“顺藤摸瓜”，通过这三个核心功能的组合就可以编排出一个异常的根因分析系统。基于上文中的图做一个简单的示例：首先从告警开始分析入口的黄金指标，随后分析服务本身的数据、依赖的中间件指标、应用 Pod/虚拟机指标，通过 Trace Dependency 可以递归分析下游依赖是否出现问题，其中还可以关联一些变更信息，以便快速定位是否由于变更引起的异常。最终发现的异常事件集中到时间轴上进行推导，也可以由运维/开发来最终确定根因。

智能运维体系构建

目前，SLS 智能运维体系主要包括两个部分，一个是基础的算法能力，帮助我们找到一些异常事件，还有就是根因分析能力，能够基于 CMDB、Config 以及一些异常事件，找出问题的根因。

基础能力

基础的算法能力就不过多介绍，在 SLS 的官网文档以及平时的技术分享中都有一些介绍，感兴趣的可以移步详细查看：算法概述、异常检测算法、流式异常检测、日志聚类分析、模式分析。

根因分析

之所以把根因分析单独提出来，主要是因为根因分析和普通算法相比，需要依赖更多的数据，相应的复杂度会高很多，尤其是想要开发一个通用的根因算法。目前，根因分析我们一直在跟进中，争取早日发布一款能够适用于多数场景中的根因算法。

总结

可观测性这一概念并不是直接发明的“黑科技”，而是我们从监控、问题排查、预防等工作中逐渐“演化”出来的词。同样我们一开始只是做日志引擎（阿里云上的产品-日志服务），随后才逐渐优化、升级为可观测性的引擎。对于“可观测性”我们要抛开概念/名词本身来发现它的本质，而这个本质往往是和商业（Business）相关，例如：

1. 让系统更加稳定，用户体验更好
2. 观察 IT 支出，消除不合理的使用，节省更多的成本
3. 观察交易行为，找到刷单/作弊，及时止损
4. 利用 AIOps 等自动化手段发现问题，节省更多的人力，运维提效

而我们对于可观测性引擎的研发，主要关注的也是如何服务更多的部门/公司进行可观测性方案的快速、有效实施，包括引擎中的传感器、数据、计算、算法等工作一直在不断进行演进和迭代，例如更加便捷的 eBPF 采集、更高压缩率的数据压缩算法、性能更高的并行计算、召回率更低的根因分析算法等。我们会持续为大家输出可观测性引擎相关的工作内容，敬请期待。（正文完）

阿里云技术专家张城：SLS可观测与AIOps的整体架构