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。关于这三种数据的特点、应用场景以及关系等,会在后面进行详细展开。
自动驾驶
电气工程的可观测由于有深厚的发展历史,可以在实践中给到我们非常多的支持,自动驾驶也是如此。自动驾驶从刚开始的定速巡航、自适应巡航开始,已经发展了几十年,目前对于自动驾驶也有一些可以在实际道路中应用的场景。电器领域的一个集大成者,就是自动驾驶。现在真正可能让自动驾驶落地的,也就是特斯拉最早开创的一套新的架构。
我们可以回过头来去看,特斯拉为什么和传统自动驾驶厂商不同,我觉得主要有以下几点:
自动驾驶与 AIOps 分级
我们团队从 2009 年做飞天 5K 项目起,就一直在负责监控、日志、分布式链路追踪等可观察性相关的工作,中间经历过小型机到分布式系统再到微服务、云化的一些架构变更,相关的可观察性方案也经历了很多演变。我们觉得整体上可观察性相关的发展和自动驾驶等级的设定非常吻合。
自动驾驶一共分为 6 级,其中 0-2 级主要还是靠人来进行决定,到了等级 3 之后就可以进行无意识驾驶,也就是手眼可以暂时性不用关注驾驶,到了等级 5 的话人就可以完全脱离驾驶这个枯燥的工作,在车上可以自由活动。
在 IT 系统的可观察性上,也可以类似划分为 6 级:
可观测性与智能运维落地
可观测性方案落地上,现阶段可能无法做出一个适用于各个行业属性的可观测引擎,更多是专注于 DevOps 和通用的公司商业方面。这里面的两个核心工作是:
从整个流程来看,我们可以将可观测性的工作划分为 4 个组成部分:
SLS 可观测与 AIOps 整体架构
基于上述我们的一些思考,回归到可观测这个问题的本质,我们目标的可观测性方案需要能够满足以下几点:
可观测数据引擎的整体架构如下图所示,从下到上的四层也基本符合方案落地的指导思想:传感器+数据+算力+算法。
可观测融合分析引擎
下面讲一下我们说的那个引擎,为什么 SLS 要做一个可观测的引擎呢?
如果把存储引擎比喻成新鲜的食材,那分析引擎就是处理这些食材的刀具,针对不同类型的食材,用不同种类的刀来处理才能得到最好的效果,例如蔬菜用切片刀、排骨用斩骨刀、水果用削皮刀等。同样,针对不同类型的可观测数据和场景,也有对应适合的分析方式:
上述的分析方式都有对应的适用场景,我们很难用一种语法/语言去实现所有的功能并且具有非常好的便捷性(虽然通过扩展 SQL 可以实现类似 PromQL、关键词查询的能力,但是写一个简单的 PromQL 算子可能要用一大串 SQL 才能实现),因此我们的分析引擎选择去兼容关键词查询、PromQL 的语法。同时为了便于将各类可观测数据进行关联起来,我们在 SQL 的基础上,实现了可以连接关键词查询、PromQL、外部的 DB、ML 模型的能力,让 SQL 成为顶层分析语言,实现可观测数据的融合分析能力。
融合分析能力示例
下面举几个我们查询/分析的应用示例,前面 3 个相对比较简单,可以用纯粹的关键词查询、PromQL,也可以结合 SQL 一起使用。最后1个展示了实际场景中进行融合分析的例子:
实现
上述的例子同时查询了 LogStore、MetricStore,而且关联 CMDB 以及 ML 模型,一个语句实现了非常复杂的分析效果,在实际的场景中还是经常出现的,尤其是分析一些比较复杂的应用和异常。
数据编排-价值挖掘
可观测性相比传统监控,更多还是在于数据价值的发掘能力更强,能够仅通过输出来推断系统的运行状态,和数据挖掘这个工作比较像,收集各类繁杂的数据、格式化、预处理、分析、检验,最后根据得到的结论去“讲故事”。
因此,在可观测性引擎的建设上,我们非常关注数据编排的能力,能够让数据流转起来,从茫茫的原始日志中不断地提取出价值更高的数据,最终告诉我们系统是否在工作以及为什么不工作。为了让数据能够“流转”起来,我们开发了几个功能:
基于编排的故障自动定位
可观测性的前期阶段,很多工作都需要人工来完成,我们最希望的还是能有一套自动化的系统,在出现问题的时候能够基于这些观测的数据自动进行异常诊断,得到一个可靠的根因并能够根据根因进行自动的 Fix。现阶段,自动异常恢复很难做到,但根因的定位通过一定的算法和编排手段还是可以实施的。
上图是一个典型的 IT 系统架构的观测抽象,每个 APP 都会有自己的黄金指标、业务的访问日志/错误日志、基础监控指标、调用中间件的指标、关联的中间件自身指标/日志,同时通过 Trace 还可以得到上下游 APP/服务的依赖关系。通过这些数据再结合一些算法和编排手段就可以进行一定程度的自动化根因分析了。这里核心依赖的几点如下:
时序、日志的异常分析能够帮我们确定某个组件是否存在问题,而关联关系能够让我们“顺藤摸瓜”,通过这三个核心功能的组合就可以编排出一个异常的根因分析系统。基于上文中的图做一个简单的示例:首先从告警开始分析入口的黄金指标,随后分析服务本身的数据、依赖的中间件指标、应用 Pod/虚拟机指标,通过 Trace Dependency 可以递归分析下游依赖是否出现问题,其中还可以关联一些变更信息,以便快速定位是否由于变更引起的异常。最终发现的异常事件集中到时间轴上进行推导,也可以由运维/开发来最终确定根因。
目前,SLS 智能运维体系主要包括两个部分,一个是基础的算法能力,帮助我们找到一些异常事件,还有就是根因分析能力,能够基于 CMDB、Config 以及一些异常事件,找出问题的根因。
基础能力
基础的算法能力就不过多介绍,在 SLS 的官网文档以及平时的技术分享中都有一些介绍,感兴趣的可以移步详细查看:算法概述、异常检测算法、流式异常检测、日志聚类分析、模式分析。
根因分析
之所以把根因分析单独提出来,主要是因为根因分析和普通算法相比,需要依赖更多的数据,相应的复杂度会高很多,尤其是想要开发一个通用的根因算法。目前,根因分析我们一直在跟进中,争取早日发布一款能够适用于多数场景中的根因算法。
可观测性这一概念并不是直接发明的“黑科技”,而是我们从监控、问题排查、预防等工作中逐渐“演化”出来的词。同样我们一开始只是做日志引擎(阿里云上的产品-日志服务),随后才逐渐优化、升级为可观测性的引擎。对于“可观测性”我们要抛开概念/名词本身来发现它的本质,而这个本质往往是和商业(Business)相关,例如:
而我们对于可观测性引擎的研发,主要关注的也是如何服务更多的部门/公司进行可观测性方案的快速、有效实施,包括引擎中的传感器、数据、计算、算法等工作一直在不断进行演进和迭代,例如更加便捷的 eBPF 采集、更高压缩率的数据压缩算法、性能更高的并行计算、召回率更低的根因分析算法等。我们会持续为大家输出可观测性引擎相关的工作内容,敬请期待。(正文完)
阿里云技术专家张城:SLS可观测与AIOps的整体架构