简介：相对于传统的告警和监控，可观察性能够以更加“白盒”的方式看穿整个复杂系统，帮助我们更好的观察系统的运行状态，快速定位和监控解决问题。就像发动机一样，警报只是告诉你发动机是否有问题，而一些仪表盘包括转速、温度、压力等可以帮助我们粗略判断哪个部分可能有问题，但要真正定位细节，我们需要观察各个组件的状态。传感器数据。作者|元一出处|阿里科技公众号前言可观测性的概念最早出现在1970年代的电气工程中。核心定义是：如果对于状态和控制向量的任何可能演化，可以仅使用来自输出的信息来估计当前状态，则称系统是可观察的。相较于传统的告警和监控，可观察性能够以更加“白盒”的方式看透整个复杂系统，帮助我们更好的观察系统运行状态，快速定位和解决问题。就像发动机一样，警报只是告诉你发动机是否有问题，而一些仪表盘包括转速、温度、压力等可以帮助我们粗略判断哪个部分可能有问题，但要真正定位细节，我们需要观察各个组件的状态。传感器数据。2IT系统的可观测性电气化时代起源于第二次工业革命（SecondIndustrialRevolution），始于1870年代。主要标志是：电力和内燃机的广泛应用。为什么可观察性的概念直到将近100年后才出现？在此之前不需要依靠各种传感器的输出来定位和排查故障和问题吗？显然不是，排错的方法一直都有，只是整个系统、情况更复杂，所以需要更系统、更系统的方式来支撑这个过程，所以演化出了可观察性的概念。所以核心点是：系统更复杂了：以前一辆汽车只需要发动机、传送带、车辆、刹车就能跑，而现在任何一辆汽车至少有上百个部件和系统，更难定位故障。开发涉及更多人：随着全球化时代的到来，公司和部门之间的分工越来越细，这意味着需要更多的部门和人员共同开发和维护系统，而协调成本也更高。越来越大。运行环境多种多样：在不同的运行环境下，各个系统的工作状态都会发生变化。我们需要能够有效地记录系统在任何阶段的状态，以便分析问题和优化产品。IT系统经过几十年的快速发展，整个开发模式、系统架构、部署模式、基础设施也经历了多轮优化。优化带来了更快的开发和部署效率。整个系统也更加复杂，开发依赖的人和部门更多，部署模型和运行环境更加动态和不确定。因此，IT行业也走到了一个更需要系统、系统观察的过程。IT系统的可观测性的实现其实和电气工程类似。核心是观察我们各个系统和应用的输出，通过数据来判断整体的工作状态。通常我们对这些输出进行分类，并总结为Traces、Metrics和Logs。关于这三类数据的特点、应用场景和关系，我们后面会详细展开。3.IT可观察性演进IT可观察性技术一直在不断发展。从广义上讲，与可观测性相关的技术不仅可以应用于IT运维场景，还可以应用于公司相关的通用和特殊场景。IT运维场景：从IT运维场景的横向和纵向角度，观察目标从最基础的机房和网络发展到用户端；观察场景也是从纯粹的错误和缓慢的请求发展到用户实际的产品体验。一般场景：观察本质上是一种一般行为。除了运维场景，适用于公司安全、用户行为、运营增长、交易等，我们可以针对这些场景构建攻击检测、攻击溯源、ABTest、广告等。效果分析等申请表。特殊场景：除了公司内部的通用场景外，还可以针对不同的行业属性，衍生出行业特定的观察场景和应用。通过控制不同红绿灯的时间和出行规划，降低城市整体拥堵率。4.PragmaticObservability是如何实现的回到可观察性解决方案的实现上，我们现阶段可能无法做出适合各种行业属性的可观察引擎，更多关注DevOps和一般企业业务方面。这里的两个核心任务是：数据覆盖足够全面：可以包括各种场景不同类型的数据，除了狭义的日志、监控、trace之外，还需要包括我们的CMDB、变更数据、客户信息、订单/交易信息、网络流量、API调用等数据关联和统一分析：数据价值的发现不是简单地通过一种数据来实现的，更多的时候我们需要通过多种数据关联来达到目的，比如作为结合用户，我们可以分析不同年龄段、不同性别用户的行为特征，有针对性地进行推荐；通过登录日志、CMDB等，结合规则引擎，实现安全攻击检测。从整个过程来看，我们可以将可观测性的工作分为四个部分：传感器：获取数据的前提是要有足够多的传感器来产生数据。这些传感器在IT领域的表现形式包括：SDK、埋点、外置探头等。数据：传感器产生数据后，我们需要有足够的能力获取和收集各种类型的数据，并对这些数据进行分类和分析.计算能力：可观察场景的核心需要覆盖足够的数据。数据一定是海量的，所以系统需要有足够的计算能力来计算和分析这些数据。算法：可观察场景的最终应用是数据的价值发现，所以需要用到各种算法，包括一些基本的数值算法，各种AIOps相关的算法，以及这些算法的组合。五再谈可观测性数据分类Log、Traces、Metrics作为IT可观测性数据的三把利剑，基本可以满足监控、告警、分析、故障等各种需求。但是在实际场景中，我们往往会混淆每种数据的适用形式，这里大致罗列一下这三类数据的特点、转换方式和适用场景：日志：我们对日志的定义比较广：记录的载体things/thingschanges，对于常见的访问日志、事务日志和内核日志等文本类型，以及包括GPS、音频和视频等在内的通用数据也包括在内。调用链场景结构化后，log其实可以转化为trace，经过聚合和降采样操作后成为metric。Metrics：是聚合值，比较离散，一般由name、labels、time、values组成。Metrics的数据量一般较小，相对成本较低，查询速度较快。痕迹：是最标准的通话记录。除了定义调用的父子关系（一般通过TraceID、SpanID、ParentSpanID）外，一般还会定义操作的服务、方法、属性、状态、耗时等详细信息。通过Trace，你可以代替Logs的一些功能，还可以通过Trace的聚合得到各个服务和方法的Metrics指标。六大“碎片化”的可观察性解决方案业界也针对这种情况推出了各种与可观察性相关的产品，其中包括很多开源和商业项目。例如：Metrics：Zabbix、Nagios、Prometheus、InfluxDB、OpenFalcon、OpenCensusTraces：Jaeger、Zipkin、SkyWalking、OpenTracing、OpenCensusLogs：ELK、Splunk、SumoLogic、Loki、Loggly这些项目的组合或多或少可以解决一个有针对性的问题或者几类问题，但是实际应用的时候会发现各种各样的问题：多套方案交织在一起：你可能至少需要用到Metrics、Logging、Tracing3种方案，维护成本巨大。数据不互通：虽然是同一个业务组件，但同一个系统产生的数据，在不同的解决方案中很难相互沟通，数据的价值无法得到充分发挥。在这种多方案组合的场景下，故障处理需要处理多个系统。如果这些系统属于不同的团队，仍然需要与多个团队交互才能解决问题，整体的维护和使用成本非常高。因此，我们希望通过一个系统来解决各类可观测数据的采集、存储、分析功能。七可观测数据引擎架构基于我们上面的一些思考，回归到可观测问题的本质，我们的目标可观测解决方案需要能够满足以下几点：数据的全面覆盖：包括各种类型的可观测数据和支持统一系统，收集各种终端和系统的数据：拒绝碎片化，支持Traces、Metrics、Log在一个系统统一存储和分析数据可关联：各类数据内部可关联，并且还支持跨数据类型关联，可以使用一套分析语言对各种数据进行整合分析计算能力充足：分布式，可扩展，面向PB级数据，也有足够的计算能力分析灵活智能的算法：除了基础算法之外，还应该包括AIOps相关的异常检测和预测算法，并支持这些算法的编排。Observable数据引擎的整体架构如下图所示。从下到上的四层也基本符合方案实施的指导思想：传感器+数据+算力+算法：传感器：数据源基于OpenTelemetry，支持各种数据形式、设备/终端的采集和数据格式，具有足够的覆盖面。数据+算力：采集到的数据会先进入我们的管道系统（类似Kafka），根据不同的数据类型建立不同的索引。目前，每天有数十PB的新数据被写入和存储在我们的平台上。保存。除了常见的查询分析能力，我们还内置了ETL功能，负责数据的清洗和格式化，同时支持对接外部流计算和离线计算系统。算法：除了基本的数值算法，我们目前支持十余种异常检测/预测算法，也支持流式异常检测；同时我们也支持使用ScheduledSQL进行数据整理，帮助我们产生更多的新数据。价值发现：价值发现过程主要通过可视化、告警、交互分析等人机交互实现。同时，它也提供了OpenAPI来连接外部系统或供用户实现一些自定义功能。8、兼容数据源和协议在阿里全面拥抱云原生的同时，我们也开始逐步兼容开源和云原生的可观察协议和方案。相较于自身协议的封闭模式，兼容开源和标准协议，极大地扩展了我们平台可以支持的数据采集范围，减少了不必要的造轮环节。上图展示了我们在兼容外部协议和Agents方面的整体进展情况：Traces：除了内部的飞天Trace和HawkeyeTrace，开源的还有Jaeger、OpenTracing、Zipkin、SkyWalking、OpenTelemetry、OpenCensus等。日志：日志协议较少，但设计了更多的日志收集代理。除了自研的Logtail，我们的平台还兼容Logstash、Beats（FileBeat、AuditBeat）、Fluentd、Fluentbits。它还提供系统日志协议和路由器。交换机等可以直接使用syslog协议向服务器上报数据。Metrics：时序引擎在新版本设计之初就兼容Prometheus，支持Telegraf、OpenFalcon、OpenTelemetryMetrics、Zabbix等数据接入。九统一的存储引擎对于存储引擎，我们设计目标的第一个要素是统一，可以用一套引擎来存储各种可观察的数据；第二个要素是快，包括写和查询，可以应用在阿里内外超大规模场景（每天写几十PB）。对于Logs、Traces和Metrics，Logs和Traces的格式和查询特性非常相似。我们把它们放在一起分析。推导过程如下：Logs/Traces：查询方式主要是通过keywords/TraceID，另外还根据某些标签进行Filtering，比如hostname，region，app等，每次查询的命中数比较少，尤其是TraceID的查询方式，命中的数据很可能是离散的。通常这类数据最适合存储在搜索引擎中，核心技术是倒排索引Metrics：通常是范围查询，每次查询单个metric/timeline，或者聚合一组timeline，比如作为统一一个应用中所有机器的平均CPU时序查询一般QPS高（主要是告警规则多）。为了适应高QPS查询，需要做好数据聚合。对于这类数据，会有专门的时序引擎来支持。目前主流的时序引擎基本上都是用类似LSMTree的思想实现的，以适应高吞吐量的写入和查询（很少有Update和Delete操作）。同时，可观测数据也有一些共性，比如高吞吐写入（high-traffic，QPS，还会有Burst），超大规模查询特性，时间访问特性（冷热特性，访问位置等）。基于以上特点的分析，我们设计了一套统一的可观察数据存储引擎。整体结构如下：接入层支持各种协议的写入，写入的数据会先进入一个FIFO管道，类似于KafkaMQ模型，支持数据消费，用于对接各类下游。pipeline上有两组索引结构，倒排索引和SortedTable，为Traces/Logs和Metrics提供快速查询能力。两组索引除了结构不同外，其他机制都是共享的，比如存储引擎、FailOver逻辑、缓存策略、冷热数据分层策略等。以上数据都是在同一个进程中实现的，大大降低了整个存储引擎的运维和部署成本基于纯分布式框架实现，支持水平扩展。单个Store最多支持PB级数据写入十个统一分析引擎。对于食材，使用不同类型的刀具以获得最佳效果，例如蔬菜切片刀、排骨切骨刀和水果削皮刀。针对不同类型的可观察数据和场景也有相应的分析方法：Metrics：通常用于告警和图形化展示，一般直接获取或者辅以简单的计算，如PromQL、TSQL等。Traces/Logs：最简单的和直接的方式是关键字查询，包括TraceID查询，只是关键字查询的一个特例数据分析（一般针对Traces和Logs）：通常Traces和Logs也用于数据分析和挖掘，所以图灵完备语言，应用最广泛为一般程序员所接受的是，上述SQL的分析方法都有对应的适用场景。我们很难用一种语法/语言来实现所有的功能，具有很好的便利性（虽然可以通过扩展SQL来实现）类似于PromQL和关键字查询的能力，但是可能需要写很多SQL一个简单的PromQL运算符），因此我们的分析引擎选择兼容关键字查询和PromQL的语法。同时，为了方便各种可观察数据的关联，在SQL的基础上，我们实现了关键字查询、PromQL、外部DB、ML模型的连接能力，使SQL成为顶级分析语言和实现可观测数据融合分析能力。以下是我们查询/分析的几个应用示例。前三个比较简单，可以纯关键字查询，PromQL，或者结合SQL使用。最后一个是实际场景中融合分析的例子：背景：网上发现支付失败错误，需要分析支付失败错误机器的CPU指标是否有问题。首先查询机器的CPU指标和关联机器的Region。信息（需要查看某个Region是否有问题），在日志中加入支付失败的机器。你只关心这些机器，最后应用时序异常检测算法快速分析这些机器的CPU指标。最终结果用折线图可视化。结果显示更直观。上面的例子同时查询LogStore和MetricStore，关联CMDB和ML模型。一条语句实现了非常复杂的分析效果，这种情况在实际场景中经常出现，尤其是在分析一些比较复杂的应用和异常时。11、与传统监控相比，数据编排的可观察性更多在于能够发现数据的价值。仅通过输出就可以推断出系统的运行状态。因此，它类似于数据挖掘的工作，收集各种复杂的数据，格式化、预处理、分析、检查，最后根据得到的结论“讲故事”。因此，在可观察性引擎的建设中，我们非常注重数据编排的能力，它可以让数据流动起来，不断地从浩如烟海的原始日志中提取更有价值的数据，最终告诉我们系统是否在工作，为什么不工作。为了让数据“流动起来”，我们开发了几个功能：数据处理：即大数据ETL中T的功能（提取、转换、加载），可以帮助我们对非结构化、半结构化数据进行处理转化为结构化数据，更易于分析。ScheduledSQL：顾名思义，就是定时运行的SQL。其核心思想是将庞大的数据进行简化，使其更易于查询。比如通过AccessLog，每分钟计算一次网站的访问请求，按照APP和Region粒度聚合CPU和内存指标，定时计算。Tracetopology等AIOps巡检：基于专门针对时序数据开发的时序异常算法的巡检能力，利用机器和算力帮助我们排查哪个指标哪个维度有问题。12可观察引擎应用实践目前，我们平台已积累10万内外部用户，每天写入数据40PB+。许多团队正在基于我们的引擎构建他们自己的公司/部门的可观察性。全栈可观察性和业务创新平台。下面将介绍一些使用我们引擎的常见场景：1全链路可观测全链路可观测一直是DevOps流程中的重要一步。除了通常的监控、告警、排查外，还承担用户行为回放/分析、版本发布验证、A/BTest等功能，下图为阿里某产品全链路可观察架构图：数据源包括移动端、Web端、后台的各种数据。同时还包括一些监控系统数据和第三方数据的采集等。通过SLS的Logtail和TLog，实现基于离线混合的数据处理方式，对数据进行标记、过滤、相关、分布式等预处理。存储各种数据。在SLS可观察数据引擎中，主要利用SLS提供的索引、查询和聚合分析能力，在上层构建基于SLS接口的全链路数据展示和监控系统。利润，我们都知道利润=收入-成本，而IT部门的成本通常占据很大一部分，尤其是互联网型的公司。现在阿里全面云化，包括阿里内部团队，也会关心自己的IT支出，尽可能的降低成本。以下示例是阿里云上某客户的监控系统架构。除了监控IT基础设施和业务，该系统还负责分析和优化整个公司的IT成本。收集的主要数据有：产品（虚拟机、网络、存储、数据库、SaaS等）成本，包括详细的计费信息收集每个产品的监控信息，包括使用情况、利用率等构建目录/CMDB，包括每个resource/instance所属的业务部门、团队、用途等，可以通过Catalog+产品账单信息计算出各部门的IT支出；结合每个实例的使用情况和利用率信息，可以计算出每个部门的IT支出资源利用率，比如每个ECS的CPU和内存使用率。最后，计算各部门/团队对IT资源整体使用的合理性，将这些信息汇总成运营报表，促进资源利用率低的部门/团队的优化。3Trace是可观察的随着云原生和微服务逐渐在各行业落地，分布式链路追踪（Trace）也开始被越来越多的企业采用。对于Trace来说，最基本的能力就是能够记录请求在多个服务之间的传播和依赖关系，并可视化。就Trace本身的数据特性而言，它是一种规范化、标准化、依赖性的访问日志，因此可以基于Trace计算和挖掘更多的价值。下面是SLSOpenTelemetryTrace的实现架构。核心是对Trace原始数据进行计算，通过数据整理得到聚合数据，并基于SLS提供的接口实现Trace的各种附加功能。例如：Dependency：这是大多数Trace系统自带的功能。基于Trace中的父子关系，聚合计算得到TraceDependency服务/接口黄金指标：Trace记录服务/接口调用延迟和状态码，根据这些数据得出QPS、延迟、错误率等黄金指标可以计算出来。上下游分析：根据计算出的依赖信息，按照某个Service进行聚合，统一Service所依赖的上下游指标。中间件分析：Trace中对中间件（数据库/MQ等）的调用一般记录为Spans。根据这些span的统计，可以得到中间件的QPS、时延、错误率。告警相关：监控和告警通常是根据服务/接口的黄金指标设置的，或者可以只关心整体服务入口的告警（一般父Span为空的Span被认为是服务入口调用).4基于编排的根本原因分析在可观测性的早期阶段，需要人工完成大量工作。我们最希望的是有一个自动化的系统，当出现问题的时候，可以根据这些观察到的数据，自动检测出异常。诊断、获取可靠的根本原因并根据诊断出的根本原因执行自动修复。在这个阶段，自动异常恢复是很难实现的，但是仍然可以通过一定的算法和编排方式来定位rootcause。下图是一个典型的IT系统架构的观察抽象。每个APP都会有自己的黄金指标，业务访问日志/错误日志，基础监控指标，调用中间件指标，关联中间件指标/日志。同时也可以通过Trace获取上下游APP/服务的依赖关系。通过将这些数据与一些算法和编排方法相结合，可以进行一定程度的自动化根本原因分析。这里的核心依赖如下：关联关系：通过Trace可以计算出APP/service之间的依赖关系；APP、PaaS、IaaS之间的依赖关系可以通过CMDB信息获取。通过关系，可以“顺藤摸瓜”找到问题的原因。时序异常检测算法：自动检测某条曲线或某组曲线是否异常，包括ARMA、KSigma、Time2Graph等，详细算法可参考：异常检测算法、流式异常检测。
