资讯详情

阿里可观测性数据引擎的技术实践

一 前言

可观测性这个概念最早出现于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.

与传统的报警和监控相比,可观察性可以更白盒地看透整个复杂的系统,帮助我们更好地观察系统的运行状态,快速定位和解决问题。就像发动机一样,报警只是告诉你发动机是否有问题,一些包含速度、温度和压力的仪表板可以帮助我们大致确定哪个部分可能有问题,真正的定位细节也需要观察每个部件的传感器数据。

二 IT系统的可观测性

电气化时代起源于第二次工业革命(Second Industrial Revolution)起于20世纪70年代,主要标志是电力和内燃机的广泛应用。为什么近100年后才提出可观测性的概念?不需要依靠各种传感器的输出定位和故障排除和问题吗?显然不是。故障排除的方法一直存在,但整个系统和情况更加复杂,因此需要更系统、更系统的方法来支持这一过程。因此,可观测性的概念已经演变。所以核心点是:

  • 系统更复杂:过去,汽车只需要一个发动机、传送带、车辆和刹车就可以运行。现在任何汽车至少有数百个部件和系统,故障定位变得更加困难。
  • 开发涉及到更多的人:随着全球化时代的到来,公司和部分分工越来越详细,这意味着系统的开发和维护需要更多的部门和人员共同完成,协调成本越来越高。
  • 各种操作环境:在不同的操作环境下,各系统的工作状态发生了变化。我们需要在任何阶段有效地记录系统的状态,以便我们分析问题并优化产品。

而IT经过几十年的快速发展,整个开发模式、系统架构、部署模式、基础设施也经过了几轮优化,优化带来了更快的开发、部署效率,但整个系统更加复杂,开发依赖于更多的人和部门、部署模式和运行环境更加动态和不确定,因此IT这个行业已经到了需要更系统、更系统地观察的过程。

IT事实上,该系统的可观测性与电气工程相似。核心是观察每个系统和应用程序的输出,并通过数据判断整体工作状态。通常,我们将对这些输出进行分类并总结Traces、Metrics、Logs。我们将详细介绍这三种数据的特点、应用场景和关系。

三 IT可观测性进化

IT可观测性技术一直在不断发展。从广义上讲,可观测性相关技术除了应用于可观测性相关技术外IT除运维场景外,还可应用于与公司相关的一般场景和特殊场景。

  1. IT运维场景:IT运维场景从横向、纵向来看,观察的目标从最基础的机房、网络等开始向用户的端上发展;观察的场景也从纯粹的错误、慢请求等发展为用户的实际产品体验。
  2. 一般场景:观测本质上是一种一般的行为。除了操作和维护场景外,它还适用于公司的安全、用户行为、操作增长和交易。我们可以构建这些场景,如攻击检测场景ABTest、广告效果分析等应用形式。
  3. 特殊场景:除公司场景外,根据不同的行业属性,也可以衍生出特定行业的观测场景和应用,如阿里云城市大脑,通过观察道路拥堵、信号灯、交通事故等信息,通过控制不同的交通灯时间、旅游规划等手段降低城市整体拥堵率。

四 Pragmatic可观测性如何落地

回到可观测性方案的实施,我们现阶段可能无法制作出适合各行业属性的可观测引擎,更注重DevOps和一般公司商业方面。这两个核心工作是:

  1. 除了狭义的日志、监控、Trace还需要包括我们的CMDB、变更数据、客户信息、订单/交易信息、网络流、API调用等
  2. 数据关联和统一分析:数据价值的探索不仅仅是通过一个数据来实现的。更多的时候,我们需要使用各种数据关联来实现目标,如结合用户信息表和访问日志,我们可以分析不同年龄和性别用户的行为特征,并有针对性地推荐它们;登录日志CMDB等,结合规则引擎,实现安全攻击检测。

从整个过程来看,我们可以将可观测性工作分为四个部分:

  1. 传感器:获取数据的前提是有足够的传感器来生成数据,这些传感器在IT该领域的形式包括:SDK、埋点、外部探针等。
  2. 数据:传感器生成数据后,我们需要有足够的能力获取和收集各种类型的数据,并对其进行分类分析。
  3. 计算能力:可观测场景的核心是覆盖足够的数据,数据必须是大量的,因此系统需要足够的计算能力来计算和分析这些数据。
  4. 算法:可观测场景的最终应用是数据的价值探索,因此需要使用一些基本的数值算法和各种算法AIOps这些算法的这些算法的组合。

五 可观测性数据分类

  • Logs、Traces、Metrics作为IT可观测数据的三剑客基本上可以满足各种监控、报警、分析、问题调查等需求。然而,在实际场景中,我们经常混淆每个数据的应用形式,然后大致列出这三种数据的特征、转换模式和应用场景:
  • Logs:我们对于Logs它是一个更广泛的定义:记录事物/事物变化的载体,包括常见的访问日志、交易日志、核心日志等文本类型,包括GPS、还包括音视频等泛型数据。调用链场景结构化后,日志实际上可以转换为Trace,聚合降采样操作后会变成Metrics。
  • Metrics:是聚合后的值,相对离散,一般有name、labels、time、values组成,Metrics数据量一般很小,相对成本较低,查询速度较快。
  • Traces:除了定义调用的父子关系外,它是最标准的调用日志(通常通过TraceID、SpanID、ParentSpanID),通过定义服务、方法、属性、状态、耗时等详细信息Trace可替代部分Logs通过的功能Trace聚合也可以获得每种服务和方法Metrics指标。

六 可观测的分裂方案

针对这种情况,业界还推出了各种可观察相关产品,包括开源、商业化等多个项目。

  1. Metrics:Zabbix、Nagios、Prometheus、InfluxDB、OpenFalcon、OpenCensus
  2. Traces:Jaeger、Zipkin、SkyWalking、OpenTracing、OpenCensus
  3. Logs:ELK、Splunk、SumoLogic、Loki、Loggly

使用这些项目的组合或多或少可以解决有针对性的一类或几类问题,但如果际应用中,您会发现各种问题:

  • 多套方案交织:至少可以使用Metrics、Logging、Tracing维护成本巨大的三种方案
  • 数据不交换:虽然它是相同的业务组件和系统,但由于数据难以在不同的解决方案中交换,因此无法充分发挥数据的价值

在这种多方案组合的情况下,问题调查需要处理多个系统。如果这些系统属于不同的团队,它们还需要与多个团队互动来解决问题,整体维护和使用成本非常巨大。因此,我们希望使用一个系统来解决收集、存储和分析所有类型的可观测数据的功能。

七 可观测性数据引擎架构

基于以上一些思考,回归可观测问题的本质,我们的目标可观测方案需要满足以下几点:

  1. 全面覆盖数据:包括各种可观测数据,并支持从各个端和系统收集数据
  2. 统一系统:拒绝分裂,可以支持系统Traces、Metrics、Logs统一的存储和分析
  3. 数据可以关联:每个数据可以相互关联,并支持跨数据类型的关联。它可以用一套分析语言整合和分析各种数据
  4. 足够的计算能力:分布式,可扩展,面对PB分析等级数据也可以有足够的计算能力
  5. 灵活智能算法:除基本算法外,还应包括AIOps相关的异常检测和预测算法,并支持这些算法的安排

可观测数据引擎的整体结构如下图所示,从底到上的四层基本符合方案着陆的指导思想:传感器 数据 算力 算法:

  • 传感器:数据源以OpenTelemetry为核心,支持各种数据形式、设备/端、数据格式的采集,覆盖面足够广。
  • 数据 计算能力:收集到的数据将首先进入我们的管道系统(类似于Kafka),根据不同的数据类型构建不同的索引。目前,我们的平台每天都有几十个PB写入并存储新数据。除了常见的查询和分析能力外,我们还内置了它ETL该功能负责清洁和格式化数据,并支持对接外部流量计算和离线计算系统。
  • 算法:除基本数值算法外,我们还支持十多种异常检测/预测算法和流式异常检测;同时也支持使用Scheduled SQL安排数据,帮助我们生成更多的新数据。
  • 价值挖掘:价值挖掘过程主要通过视觉、报警、交互分析等人机交互实现,也提供OpenAPI对接外部系统或供用户实现一些自定义功能。

八 数据源与协议兼容

随着阿里全面拥抱云原生后,我们也开始逐渐去兼容开源以及云原生的可观测领域的协议和方案。相比自有协议的封闭模式,兼容开源、标准协议大大扩充了们平台能够支持的数据采集范围,而且减少了不必要的造轮子环节。上图展示了我们兼容外部协议、Agent的整体进度:

  • Traces:除了内部的飞天Trace、鹰眼Trace外,开源的包括Jaeger、OpenTracing、Zipkin、SkyWalking、OpenTelemetry、OpenCensus等。
  • Logs:Logs的协议较少,但是设计比较多的日志采集Agent,我们平台除了自研的Logtail外,还兼容包括Logstash、Beats(FileBeat、AuditBeat)、Fluentd、Fluent bits,同时还提供syslog协议,路由器交换机等可以直接用syslog协议上报数据到服务端。
  • Metrics:时序引擎我们在新版本设计之初就兼容了Prometheus,并且支持Telegraf、OpenFalcon、OpenTelemetry Metrics、Zabbix等数据接入。

九 统一存储引擎

对于存储引擎,我们的设计目标的第一要素是统一,能够用一套引擎存储各类可观测的数据;第二要素是快,包括写入、查询,能够适用于阿里内外部超大规模的场景(日写入几十PB)。

 对于Logs、Traces、Metrics,其中Logs和Traces的格式和查询特点非常相似,我们放到一起来分析,推导的过程如下:

  • Logs/Traces:
  • 查询的方式主要是通过关键词/TraceID进行查询,另外会根据某些Tag进行过滤,例如hostname、region、app等
  • 每次查询的命中数相对较少,尤其是TraceID的查询方式,而且命中的数据极有可能是离散的
  • 通常这类数据最适合存储在搜索引擎中,其中最核心的技术是倒排索引
  • Metrics:
  • 通常都是range查询,每次查询某一个单一的指标/时间线,或者一组时间线进行聚合,例如统一某个应用所有机器的平均CPU
  • 时序类的查询一般QPS都较高(主要有很多告警规则),为了适应高QPS查询,需要把数据的聚合性做好
  • 对于这类数据都会有专门的时序引擎来支撑,目前主流的时序引擎基本上都是用类似于LSM Tree的思想来实现,以适应高吞吐的写入和查询(Update、Delete操作很少)

同时可观测性数据还有一些共性的特点,例如高吞吐写入(高流量、QPS,而且会有Burst)、超大规模查询特点、时间访问特性(冷热特性、访问局部性等)。

 针对上述的特性分析,我们设计了一套统一的可观测数据存储引擎,整体架构如下:

  1. 接入层支持各类协议写入,写入的数据首先会进入到一个FIFO的管道中,类似于Kafka的MQ模型,并且支持数据消费,用来对接各类下游
  2. 在管道之上有两套索引结构,分别是倒排索引以及SortedTable,分别为Traces/Logs和Metrics提供快速的查询能力
  3. 两套索引除了结构不同外,其他各类机制都是共用的,例如存储引擎、FailOver逻辑、缓存策略、冷热数据分层策略等
  4. 上述这些数据都在同一个进程内实现,大大降低运维、部署代价
  5. 整个存储引擎基于纯分布式框架实现,支持横向扩展,单个Store最多支持日PB级的数据写入

十 统一分析引擎

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

  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一起使用。最后一个展示了实际场景中进行融合分析的例子:

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

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

十一 数据编排

 可观测性相比传统监控,更多的还是在于数据价值的发掘能力更强,能够仅通过输出来推断系统的运行状态,因此和数据挖掘这个工作比较像,收集各类繁杂的数据、格式化、预处理、分析、检验,最后根据得到的结论去“讲故事”。因此在可观测性引擎的建设上,我们非常关注数据编排的能力,能够让数据流转起来,从茫茫的原始日志中不断的去提取出价值更高的数据,最终告诉我们系统是否在工作以及为什么不工作。为了让数据能够“流转”起来,我们开发了几个功能:

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

十二 可观测性引擎应用实践

目前我们这套平台上已经积累了10万级的内外部用户,每天写入的数据40PB+,非常多的团队在基于我们的引擎在构建自己公司/部门的可观测平台,进行全栈的可观测和业务创新。下面将介绍一些常见的使用我们引擎的场景:

全链路的可观测性一直都是DevOps环节中的重要步骤,除了通常的监控、告警、问题排查外,还承担用户行为回放/分析、版本发布验证、A/B Test等功能,下图展示的是阿里内部某个产品内部的全链路可观测架构图:

  1. 数据源包括移动端、Web端、后端的各类数据,同时还包括一些监控系统的数据、第三方的数据等
  2. 采集通过SLS的Logtail和TLog实现
  3. 基于离在线混合的数据处理方式,对数据进行打标、过滤、关联、分发等预处理
  4. 各类数据全部存储在SLS可观测数据引擎中,主要利用SLS提供的索引、查询和聚合分析能力
  5. 上层基于SLS的接口构建全链路的数据展示和监控系统

 

商业公司的第一要务永远是营收、盈利,我们都知道盈利=营收-成本,IT部门的成本通常也会占据很大一个部分,尤其是互联网类型的公司。现在阿里全面云化后,包括阿里内部的团队也会在乎自己的IT支出,尽可能的压缩成本。下面的示例是我们阿里云上一家客户的监控系统架构,系统除了负责IT基础设施和业务的监控外,还会负责分析和优化整个公司的IT成本,主要收集的数据有:

  1. 收集云上每个产品(虚拟机、网络、存储、数据库、SaaS类等)的费用,包括详细的计费信息
  2. 收集每个产品的监控信息,包括用量、利用率等
  3. 建立起Catalog/CMDB,包括每个资源/实例所属的业务部门、团队、用途等

利用Catalog + 产品计费信息,就可以计算出每个部门的IT支出费用;再结合每个实例的用量、利用率信息,就可以计算出每个部门的IT资源利用率,例如每台ECS的CPU、内存使用率。最终计算出每个部门/团队整体上使用IT资源的合理度,将这些信息总结成运营报表,推动资源使用合理度低的部门/团队去优化。

 

随着云原生、微服务逐渐在各个行业落地,分布式链路追踪(Trace)也开始被越来越多的公司采用。对于Trace而言,最基础的能力是能够记录请求在多个服务之间调用的传播、依赖关系并进行可视化。而从Trace本身的数据特点而言,它是规则化、标准化且带有依赖关系的访问日志,因此可以基于Trace去计算并挖掘更多的价值。

下面是SLS OpenTelemetry Trace的实现架构,核心是通过数据编排计算Trace原始数据并得到聚合数据,并基于SLS提供的接口实现各类Trace的附加功能。例如:

  1. 依赖关系:这是绝大部分的Trace系统都会附带的功能,基于Trace中的父子关系进行聚合计算,得到Trace Dependency
  2. 服务/接口黄金指标:Trace中记录了服务/接口的调用延迟、状态码等信息,基于这些数据可以计算出QPS、延迟、错误率等黄金指标。
  3. 上下游分析:基于计算的Dependency信息,按照某个Service进行聚合,统一Service依赖的上下游的指标
  4. 中间件分析:Trace中对于中间件(数据库/MQ等)的调用一般都会记录成一个个Span,基于这些Span的统计可以得到中间件的QPS、延迟、错误率。
  5. 告警相关:通常基于服务/接口的黄金指标设置监控和告警,也可以只关心整体服务入口的告警(一般对父Span为空的Span认为是服务入口调用)。

 

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

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

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

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

十三 写在最后

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

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

而我们对于可观测性引擎的研发,主要关注的也是如何服务更多的部门/公司进行可观测性方案的快速、有效实施。包括引擎中的传感器、数据、计算、算法等工作一直在不断进行演进和迭代,例如更加便捷的eBPF采集、更高压缩率的数据压缩算法、性能更高的并行计算、召回率更低的根因分析算法等。

作者 | 元乙

标签: 低型面温度传感器探针

锐单商城拥有海量元器件数据手册IC替代型号,打造 电子元器件IC百科大全!

锐单商城 - 一站式电子元器件采购平台