共计 9144 个字符，预计需要花费 23 分钟才能阅读完成。
简介：相比传统的告警、监控，可观测性可能以更加“白盒”的形式看透整个简单的零碎，帮忙咱们更好的察看零碎的运行状况，疾速定位和解决问题。就像发动机而言，告警只是通知你发动机是否有问题，而一些蕴含转速、温度、压力的仪表盘可能帮咱们大抵确定是哪个局部可能有问题，而真正定位细节问题还须要察看每个部件的传感器数据才行。
作者 | 元乙
起源 | 阿里技术公众号
一 前言
可观测性这个概念最早呈现于 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）起于 19 世纪七十年代，次要标记是：电力、内燃机的广泛应用。而可观测性这一概念为何在近 100 年后才会被提出？难道在此之前就不须要依赖各类传感器的输入定位和排查故障和问题？显然不是，排查故障的形式始终都在，只是整个零碎和状况更加简单，所以才须要更加体系化、系统化的形式来反对这一过程，因而演变进去可观测性这个概念。所以外围点在于：
- 零碎更加的简单：以前的汽车只须要一个发动机、传送带、车辆、刹车就能够跑起来，当初轻易一个汽车上至多有上百个部件和零碎，故障的定位难度变的更大。
- 开发波及更多的人：随着全球化时代的到来，公司、局部的分工也越来越细，也就意味着零碎的开发和保护须要更多的部门和人来共同完成，协调的代价也越来越大。
- 运行环境多种多样：不同的运行环境下，每个零碎的工作状况是变动的，咱们须要在任何阶段都能无效记录好零碎的状态，便于咱们剖析问题、优化产品。
而 IT 零碎通过几十年的飞速发展，整个开发模式、零碎架构、部署模式、基础设施等也都通过了好几轮的优化，优化带来了更快的开发、部署效率，但随之而来整个的零碎也更加的简单、开发依赖更多的人和部门、部署模式和运行环境也更加动静和不确定，因而 IT 行业也曾经到了须要更加系统化、体系化进行观测的这一过程。
IT 零碎的可观测性施行起来其实和电气工程还是比拟相似，外围还是察看咱们各个系统、利用的输入，通过数据来判断整体的工作状态。通常咱们会把这些输入进行分类，总结为 Traces、Metrics、Logs。对于这三种数据的特点、利用场景以及关系等，咱们会在前面进行具体开展。
三 IT 可观测性的演进
IT 的可观测性技术始终在一直的倒退中，从狭义的角度上讲，可观测性相干的技术除了利用在 IT 运维的场景外，还能够利用在和公司相干的通用场景以及非凡场景中。
- IT 运维场景：IT 运维场景从横向、纵向来看，察看的指标从最根底的机房、网络等开始向用户的端上倒退；察看的场景也从纯正的谬误、慢申请等倒退为用户的理论产品体验。
- 通用场景：观测实质上是一个通用的行为，除了运维场景外，对于公司的平安、用户行为、经营增长、交易等都实用，咱们能够针对这些场景构建例如攻打检测、攻打溯源、ABTest、广告成果剖析等利用模式。
- 非凡场景：除了场景的公司内通用场景外，针对不同的行业属性，也能够衍生出特定行业的观测场景与利用，例如阿里云的城市大脑，就是通过观测路线拥挤、信号灯、交通事故等信息，通过管制不同红绿灯工夫、出行布局等伎俩升高城市整体拥挤率。
四 Pragmatic 可观测性如何落地
回到可观测性计划落地上，咱们现阶段可能无奈做出一个实用于各个行业属性的可观测引擎，更多的还是专一于 DevOps 和通用的公司商业方面。这外面的两个外围工作是：
- 数据的覆盖面足够的全：可能包含各类不同场景的不同类型的数据，除了广义的日志、监控、Trace 外，还须要包含咱们的 CMDB、变更数据、客户信息、订单 / 交易信息、网络流、API 调用等
- 数据关联与对立剖析：数据价值的挖掘不是简略的通过一种数据来实现，更多的时候咱们须要利用多种数据关联来达到目标，例如联合用户的信息表以及拜访日志，咱们能够剖析不同年龄段、性别的用户的行为特点，针对性的进行举荐；通过登录日志、CMDB 等，联合规定引擎，来实现安全类的攻打检测。
从整个流程来看，咱们能够将可观测性的工作划分为 4 个组成部分：
- 传感器：获取数据的前提是要有足够传感器来产生数据，这些传感器在 IT 畛域的状态有：SDK、埋点、内部探针等。
- 数据：传感器产生数据后，咱们须要有足够的能力去获取、收集各种类型的数据，并把这些数据归类剖析。
- 算力：可观测场景的外围是须要笼罩足够多的数据，数据肯定是海量的，因而零碎须要有足够的算力来计算和剖析这些数据。
- 算法：可观测场景的终极利用是数据的价值挖掘，因而须要应用到各类算法，包含一些根底的数值类算法、各种 AIOps 相干的算法以及这些算法的组合。
五 再论可观测性数据分类
- Logs、Traces、Metrics 作为 IT 可观测性数据的三剑客，根本能够满足各类监控、告警、剖析、问题排查等需要，然而理论场景中，咱们常常会搞混每种数据的实用状态，这里再大抵列举一下这三类数据的特点、转化形式以及实用场景：
- Logs：咱们对于 Logs 是更加宽泛的定义：记录事 / 物变动的载体，对于常见的拜访日志、交易日志、内核日志等文本型以及包含 GPS、音视频等泛型数据也蕴含在其中。日志在调用链场景结构化后其实能够转变为 Trace，在进行聚合、降采样操作后会变成 Metrics。
- Metrics：是聚合后的数值，绝对比拟离散，个别有 name、labels、time、values 组成，Metrics 数据量个别很小，绝对老本更低，查问的速度比拟快。
- Traces：是最规范的调用日志，除了定义了调用的父子关系外（个别通过 TraceID、SpanID、ParentSpanID），个别还会定义操作的服务、办法、属性、状态、耗时等详细信息，通过 Trace 可能代替一部分 Logs 的性能，通过 Trace 的聚合也能失去每个服务、办法的 Metrics 指标。
六“割裂”的可观测性计划
业界也针对这种状况推出了各类可察看性相干的产品，包含开源、商业化的泛滥我的项目。例如：
- Metrics：Zabbix、Nagios、Prometheus、InfluxDB、OpenFalcon、OpenCensus
- Traces：Jaeger、Zipkin、SkyWalking、OpenTracing、OpenCensus
- Logs：ELK、Splunk、SumoLogic、Loki、Loggly
利用这些我的项目的组合或多或少能够解决针对性的一类或者几类问题，但真正利用起来你会发现各种问题：
- 多套计划交错：可能要应用至多 Metrics、Logging、Tracing3 种计划，保护代价微小
- 数据不互通：尽管是同一个业务组件，同一个零碎，产生的数据因为在不同的计划中，数据难以互通，无奈充分发挥数据价值
- 在这种多套计划组合的场景下，问题排查须要和多套零碎打交道，若这些零碎归属不同的团队，还须要和多个团队进行交互能力解决问题，整体的保护和应用代价十分微小。因而咱们心愿可能应用一套零碎去解决所有类型可观测性数据的采集、存储、剖析的性能。
七 可观测性数据引擎架构
基于上述咱们的一些思考，回归到可观测这个问题的实质，咱们指标的可观测性计划须要可能满足以下几点：
- 数据全面笼罩：包含各类的可观测数据以及反对从各个端、零碎中采集数据
- 对立的零碎：回绝割裂，可能在一个零碎中反对 Traces、Metrics、Logs 的对立存储与剖析
- 数据可关联：每种数据外部能够相互关联，也反对跨数据类型的关联，可能用一套剖析语言把各类数据进行交融剖析
- 足够的算力：分布式、可扩大，面对 PB 级的数据，也能有足够的算力去剖析
- 灵便智能的算法：除了根底的算法外，还应包含 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）、超大规模查问特点、工夫拜访个性（冷热个性、拜访局部性等）。
针对上述的个性剖析，咱们设计了一套对立的可观测数据存储引擎，整体架构如下：
- 接入层反对各类协定写入，写入的数据首先会进入到一个 FIFO 的管道中，相似于 Kafka 的 MQ 模型，并且反对数据生产，用来对接各类上游
- 在管道之上有两套索引构造，别离是倒排索引以及 SortedTable，别离为 Traces/Logs 和 Metrics 提供疾速的查问能力
- 两套索引除了构造不同外，其余各类机制都是共用的，例如存储引擎、FailOver 逻辑、缓存策略、冷热数据分层策略等
- 上述这些数据都在同一个过程内实现，大大降低运维、部署代价
- 整个存储引擎基于纯分布式框架实现，反对横向扩大，单个 Store 最多反对日 PB 级的数据写入
十 对立剖析引擎
如果把存储引擎比喻成陈腐的食材，那剖析引擎就是解决这些食材的刀具，针对不同类型的食材，用不同品种的刀来解决能力失去最好的成果，例如蔬菜用切片刀、排骨用斩骨刀、水果用削皮刀等。同样针对不同类型的可观测数据和场景，也有对应的适宜的剖析形式：
- Metrics：通常用于告警和图形化展现，个别间接获取或者辅以简略的计算，例如 PromQL、TSQL 等
- Traces/Logs：最简略间接的形式是关键词的查问，包含 TraceID 查问也只是关键词查问的特例
- 数据分析（个别针对 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 模型，一个语句实现了非常复杂的剖析成果，在理论的场景中还是经常出现的，尤其是剖析一些比较复杂的利用和异样。
十一 数据编排
可观测性相比传统监控，更多的还是在于数据价值的挖掘能力更强，可能仅通过输入来推断零碎的运行状态，因而和数据挖掘这个工作比拟像，收集各类繁冗的数据、格式化、预处理、剖析、测验，最初依据失去的论断去“讲故事”。因而在可观测性引擎的建设上，咱们十分关注数据编排的能力，可能让数据流转起来，从茫茫的原始日志中一直的去提取出价值更高的数据，最终通知咱们零碎是否在工作以及为什么不工作。为了让数据可能“流转”起来，咱们开发了几个性能：
- 数据加工：也就是大数据 ETL（extract, transform, and load）中 T 的性能，可能帮咱们把非结构化、半结构化的数据处理成结构化的数据，更加容易剖析。
- Scheduled SQL：顾名思义，就是定期运行的 SQL，核心思想是把宏大的数据精简化，更加利于查问，例如通过 AccessLog 每分钟定期计算网站的拜访申请、按 APP、Region 粒度聚合 CPU、内存指标、定期计算 Trace 拓扑等。
- AIOps 巡检：针对时序数据特地开发的基于时序异样算法的巡检能力，用机器和算力帮咱们去查看到底是哪个指标的哪个维度呈现问题。
十二 可观测性引擎利用实际
目前咱们这套平台上曾经积攒了 10 万级的内外部用户，每天写入的数据 40PB+，十分多的团队在基于咱们的引擎在构建本人公司 / 部门的可观测平台，进行全栈的可观测和业务翻新。上面将介绍一些常见的应用咱们引擎的场景：
1 全链路可观测
全链路的可观测性始终都是 DevOps 环节中的重要步骤，除了通常的监控、告警、问题排查外，还承当用户行为回放 / 剖析、版本公布验证、A/B Test 等性能，下图展现的是阿里外部某个产品外部的全链路可观测架构图：
- 数据源包含挪动端、Web 端、后端的各类数据，同时还包含一些监控零碎的数据、第三方的数据等
- 采集通过 SLS 的 Logtail 和 TLog 实现
- 基于离在线混合的数据处理形式，对数据进行打标、过滤、关联、散发等预处理
- 各类数据全副存储在 SLS 可观测数据引擎中，次要利用 SLS 提供的索引、查问和聚合剖析能力
- 下层基于 SLS 的接口构建全链路的数据展现和监控零碎
2 老本可观测
商业公司的第一要务永远是营收、盈利，咱们都晓得盈利 = 营收 - 老本，IT 部门的老本通常也会占据很大一个局部，尤其是互联网类型的公司。当初阿里全面云化后，包含阿里外部的团队也会在乎本人的 IT 收入，尽可能的压缩老本。上面的示例是咱们阿里云上一家客户的监控零碎架构，零碎除了负责 IT 基础设施和业务的监控外，还会负责剖析和优化整个公司的 IT 老本，次要收集的数据有：
- 收集云上每个产品（虚拟机、网络、存储、数据库、SaaS 类等）的费用，包含具体的计费信息
- 收集每个产品的监控信息，包含用量、利用率等
- 建设起 Catalog/CMDB，包含每个资源 / 实例所属的业务部门、团队、用处等
利用 Catalog + 产品计费信息，就能够计算出每个部门的 IT 支出费用；再联合每个实例的用量、利用率信息，就能够计算出每个部门的 IT 资源利用率，例如每台 ECS 的 CPU、内存使用率。最终计算出每个部门 / 团队整体上应用 IT 资源的正当度，将这些信息总结成经营报表，推动资源应用正当度低的部门 / 团队去优化。
3 Trace 可观测
随着云原生、微服务逐步在各个行业落地，分布式链路追踪（Trace）也开始被越来越多的公司采纳。对于 Trace 而言，最根底的能力是可能记录申请在多个服务之间调用的流传、依赖关系并进行可视化。而从 Trace 自身的数据特点而言，它是规则化、标准化且带有依赖关系的拜访日志，因而能够基于 Trace 去计算并开掘更多的价值。
上面是 SLS OpenTelemetry Trace 的实现架构，外围是通过数据编排计算 Trace 原始数据并失去聚合数据，并基于 SLS 提供的接口实现各类 Trace 的附加性能。例如：
- 依赖关系：这是绝大部分的 Trace 零碎都会附带的性能，基于 Trace 中的父子关系进行聚合计算，失去 Trace Dependency
- 服务 / 接口黄金指标：Trace 中记录了服务 / 接口的调用提早、状态码等信息，基于这些数据能够计算出 QPS、提早、错误率等黄金指标。
- 上下游剖析：基于计算的 Dependency 信息，依照某个 Service 进行聚合，对立 Service 依赖的上下游的指标
- 中间件剖析：Trace 中对于中间件（数据库 /MQ 等）的调用个别都会记录成一个个 Span，基于这些 Span 的统计能够失去中间件的 QPS、提早、错误率。
- 告警相干：通常基于服务 / 接口的黄金指标设置监控和告警，也能够只关怀整体服务入口的告警（个别对父 Span 为空的 Span 认为是服务入口调用）。
4 基于编排的根因剖析
可观测性的后期阶段，很多工作都是须要人工来实现，咱们最心愿的还是能有一套自动化的零碎，在呈现问题的时候可能基于这些观测的数据主动进行异样的诊断、失去一个牢靠的根因并可能依据诊断的根因进行主动的 Fix。现阶段，主动异样复原很难做到，但根因的定位通过肯定的算法和编排伎俩还是能够施行的。
下图是一个典型的 IT 零碎架构的观测形象，每个 APP 都会有本人的黄金指标、业务的拜访日志 / 谬误日志、根底监控指标、调用中间件的指标、关联的中间件本身指标 / 日志，同时通过 Trace 还能够失去上下游 APP/ 服务的依赖关系。通过这些数据再联合一些算法和编排伎俩就能够进行肯定水平的自动化根因剖析了。这里外围依赖的几点如下：
- 关联关系：通过 Trace 能够计算出 APP/ 服务之间的依赖关系；通过 CMDB 信息能够失去 APP 和 PaaS、IaaS 之间的依赖关系。通过关联关系就能够“顺藤摸瓜”，找到呈现问题的起因。
- 时序异样检测算法：自动检测某一条、某组曲线是否有异样，包含 ARMA、KSigma、Time2Graph 等，具体的算法能够参考：异样检测算法、流式异样检测。
- 日志聚类分析：将类似度高的日志聚合，提取独特的日志模式（Pattern），疾速把握日志全貌，同时利用 Pattern 的比照性能，比照失常 / 异样时间段的 Pattern，疾速找到日志中的异样。
时序、日志的异样剖析可能帮咱们确定某个组件是否存在问题，而关联关系可能让咱们进行“顺藤摸瓜”。通过这三个外围性能的组合就能够编排出一个异样的根因剖析零碎。下图就是一个简略的示例：首先从告警开始剖析入口的黄金指标，随后剖析服务自身的数据、依赖的中间件指标、利用 Pod/ 虚拟机指标，通过 Trace Dependency 能够递归剖析上游依赖是否呈现问题，其中还能够关联一些变更信息，以便疾速定位是否因为变更引起的异样。最终发现的异样事件集中到时间轴上进行推导，也能够由运维 / 开发来最终确定根因。
十三 写在最初
可观测性这一概念并不是间接创造的“黑科技”，而是咱们从监控、问题排查、预防等工作中逐步“演变”进去的词。同样咱们一开始只是做日志引擎（阿里云上的产品：日志服务），在随后才逐步优化、降级为可观测性的引擎。对于“可观测性”咱们要抛开概念 / 名词自身来发现它的实质，而这个实质往往是和商业（Business）相干，例如：
- 让零碎更加稳固，用户体验更好
- 察看 IT 收入，打消不合理的应用，节俭更多的老本
- 察看交易行为，找到刷单 / 舞弊，即便止损
- 利用 AIOps 等自动化伎俩发现问题，节俭更多的人力，运维提效
而咱们对于可观测性引擎的研发，次要关注的也是如何服务更多的部门 / 公司进行可观测性计划的疾速、无效施行。包含引擎中的传感器、数据、计算、算法等工作始终在一直进行演进和迭代，例如更加便捷的 eBPF 采集、更高压缩率的数据压缩算法、性能更高的并行计算、召回率更低的根因剖析算法等。
原文链接
本文为阿里云原创内容，未经容许不得转载。
