1. 电气工程下的可观测
可观测性这个概念最早出现于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.
相比传统的告警、监控，可观测性能够以更加“白盒”的方式看透整个复杂的系统，帮助我们更好的观察系统的运行状况，快速定位和解决问题。就像发动机而言，告警只是告诉你发动机是否有问题，而一些包含转速、温度、压力的仪表盘能够帮我们大致确定是哪个部分可能有问题，而真正定位细节问题还需要观察每个部件的传感器数据才行。
2. IT 系统的可观测技术
电气工程在 20 世纪初就已经存在，可观测概念相比要晚几十年才被提出，回顾其中的发展过程，我们可以得到一个基本的逻辑：当技术发展的越来越成熟，形成一个巨大的产品矩阵、提供丰富的功能、勾勒出宏伟的商业版图时，其背后一定会出现一些现象：
- 系统更加复杂：从单一产品到多种产品，从单一技术到多种技术，如何保证复杂系统稳定工作
- 开发协同成本：从单人到多人，从单一企业到全球化产业链，如何快速评估模块质量并确定问题边界
- 运行环境多样：从固定场景到多用途，从受控环境到多环境，如何收集这些环境的运行数据并反哺产品
对应着这些问题和挑战的产生，催生了电气化可观测技术的出现。同样，IT 领域经过几十年的高速发展，也开始遇见类似的问题，随之提出了 IT 可观测的概念并开始衍生出一系列产品。
电气领域的可观测和IT系统中的可观测本质上是为了解决同类的问题：让问题更早的被发现、处理问题的速度会更快、辅助我们的系统设计的更加稳定，而这一切的根本目的，是为了用更低的成本（可观测建设支出）去实现更高的价值（产品稳定、用户体验好，带来更大商业价值）。
3. 可观测系统的挑战
IT 系统在多年来发展中，出现了众多的技术、产品、商业化公司来从不同方面提高可观测能力，涵盖基础设施监控、网络监控、分布式链路追踪、日志、告警、可视化等各个方面。随着近些年的技术趋势来看，我们能够观察到一个现象：为了实现公司产品的快速迭代，以应对竞争日益激烈的市场，无论是技术依赖、计算节点数、发布速度、参与人员等都在呈线性/指数级的快速提升，而这些方面的组合提升叠加起来更是难以估计的量级，对可观测技术带来的挑战也越来越大，这里至少包括：
- 数据量级、数据种类提升下，对存储系统的性能、成本要求
- 敏捷开发、快速发布时，对数据实时性的要求
- 从狭义可观测到针对 DevSecBusOps 的广义可观测
- 微服务、云原生场景下的可观测能力
- 提升数据接入便捷性、工具的统一性，降低实施成本
4. 什么是成熟的可观测方案
为了更好的梳理可观测的技术和产品思路，我们尝试从多个方面思考，对于一个成熟的可观测方案需要具备的基本能力，这里主要总结如下：
- 自动化的能力：当整个技术栈、服务、节点规模越来越大时，自动化能力就越发的重要，核心目标是减少实施代价
- 全栈的数据：全栈包括多个方面，从调用场景看是客户端到服务端，从技术栈看是从基础设施到应用，从应用场景看是从 ITOps 到安全、运营...
- 一套工具：无论从上手的难度、体验的一致性，使用一套工具解决所有问题一定是最优解，相比多个工具结合使用，可以大大减少工具间跳转的上下文确实
- 统一的观测数据存储：能够兼容 Log、Trace、Metric、Profiling 等各类可观测数据存储，并且能够在数据规模逐渐增长的情况下，具备足够的弹性并且保持成本友好
- 数据关联分析：针对各类可观测数据，能够提供跨多种数据种类、多种数据源的联合分析能力，且分析需要具有足够的完备性、大规模数据量下的交互式分析能力
- 数据的上下文：即一条数据中需要关联足够的上下文信息，例如 TraceID 信息、服务、主机、Pod、用户 ID、设备 ID 等，便于和其他观测数据关联
- 数据实时性：尽可能把数据的产生到可查询控制在秒级，同时查询的性能也需要足够的高，保证在问题排查时可以快速交互
- 高基数的数据：通常应对数据量大可能使用降维、降采样等，但这种方式也会损失细节数据，可能会将异常掩盖，因此更推荐能够采集并存储原始的高基数/多维度数据
- 部分的智能化：随着大模型、AIOps 等技术的快速发展，智能化已经开始逐渐应用在可观测的各个场景，可以在生产上逐渐采用智能算法来实现告警收敛、异常检测和根因分析，但需注意现阶段 AIOps 并不能取代人工
5. 可观测方案的实施痛点
电气工程的可观测主要由传感器、数据总线、数据存储/整合、可视化/通知等组成，本质上是对数据生命周期的管理。IT 系统的可观测从实施路径上与之基本一致。对标成熟的可观测方案能力，其中的过程和难点总结如下：
- 数据采集：保证全栈的数据覆盖度、低资源消耗、采集稳定性，对应用的影响需要足够的低
- 数据富化：让数据附加更多高价值信息，富化能力需要足够的强、具备足够的弹性以及速度
- 数据存储：如何实现一个统一的存储基座，适配各类可观测存储，同时具备稳定、高性能、弹性、成本友好
- 数据分析：如何快速把存储的数据价值发挥出来，分析需要具备易用性、高性能、多源 Join 等能力
- 问题发现：告警、可视化等基础功能需要具备足够的灵活性，此外需要结合一定的算法和编排能力来加速
- 预测：可观测的终极目标是能够在异常发生前发现问题，因此故障预测也是一个非常重要的环节
6. SLS 可观测技术发展策略
SLS 十年前从日志、监控做起，逐渐从阿里云的飞天神农监控、简单日志发展成阿里集团的基础设施，并在阿里云上吸引了数十万企业用户。面对可观测的技术浪潮、成熟可观测的痛点诉求，我们首先从数据引擎的角度出发，尝试把可观测数据生命周期中的采集、存储、计算、分析做深做精，并基于这些基础技术提供一些简单的封装，为客户提供单一场景的开箱即用的可观测方案，例如监控、Trace、成本管家、日志审计等
7. 可观测采集技术-iLogtail
作为和应用一起部署的可观测数据采集器，核心诉求是高可靠、高性能、低资源消耗，而开源 Agent 重点在快速迭代、增加功能上，在上述的核心诉求上表现并不好，因此我们从 13 年开始一直自研采集 Agent iLogtail（目前已经开源），不断逐渐优化和改进iLogtail来解决性能、稳定性、可管控等问题，并经历了阿里多次双十一、双十二、春晚红包等项目的考验。目前iLogtail支持包括Log、Trace、Metric、Profile 多种类型数据的统一收集，核心的特点主要如下：
- 支持多种Log、Trace、Metric、Profile数据采集，尤其对容器、Kubernetes环境支持非常友好
- 数据采集资源消耗极低，单核采集能力100M/s，相比同类可观测数据采集的Agent性能好5-20倍
- 高稳定性，在阿里巴巴以及数万阿里云客户生产中使用验证，部署量近千万，每天采集数十PB可观测数据
- 支持插件化扩展，可任意扩充数据采集、处理、聚合、发送模块
- 支持配置远程管理，支持以图形化、SDK、K8s Operator等方式进行配置管理，可轻松管理百万台机器的数据采集
- 支持自监控、流量控制、资源控制、主动告警、采集统计等多种高级管控特性
8. 统一数据存储引擎
对于存储引擎，我们的设计目标的第一要素是统一，能够用一套引擎存储各类可观测的数据；第二要素是快，包括写入、查询，能够适用于阿里内外部超大规模的场景（日写入几十PB）。
8.1 对于Logs、Traces、Metrics，其中Logs和Traces的格式和查询特点非常相似，我们放到一起来分析，推导的过程如下
Logs/Traces：
- 查询的方式主要是通过关键词/TraceID进行查询，另外会根据某些Tag进行过滤，例如hostname、region、app等
- 每次查询的命中数相对较少，尤其是TraceID的查询方式，而且命中的数据极有可能是离散的
- 通常这类数据最适合存储在搜索引擎中，其中最核心的技术是倒排索引
Metrics：
- 通查都是range查询，每次查询某一个单一的指标/时间线，或者一组时间线进行聚合，例如统一某个应用所有机器的平均CPU
- 时序类的查询一般QPS都较高（主要有很多告警规则），为了适应高QPS查询，需要把数据的聚合性做好
- 对于这类数据都会有专门的时序引擎来支撑，目前主流的时序引擎基本上都是用类似于LSM Tree的思想来实现，以适应高吞吐的写入和查询（Update、Delete操作很少）
同时可观测性数据还有一些共性的特点，例如高吞吐写入（高流量、QPS，而且会有Burst）、超大规模查询特点、时间访问特性（冷热特性、访问局部性等）。
8.2 针对上述的特性分析，我们设计了一套统一的可观测数据存储引擎，整体架构如下
- 接入层支持各类协议写入，写入的数据首先会进入到一个FIFO的管道中，类似于Kafka的MQ模型，并且支持数据消费，用来对接各类下游
- 在管道之上有两套索引结构，同时复用倒排、列存、Compaction 等能力，分别为Traces/Logs和Metrics提供快速的查询能力
- 上述这些数据都在同一个进程内实现，大大降低运维、部署代价
- 整个存储引擎基于纯分布式框架实现，支持横向扩展，单个Store最多支持日PB级的数据写入
9. 数据计算与流转
如果把存储引擎比喻成新鲜的食材，那分析引擎就是处理这些食材的刀具，针对不同类型的食材，用不同种类的刀来处理才能得到最好的效果，例如蔬菜用切片刀、排骨用斩骨刀、水果用削皮刀等。同样针对不同类型的可观测数据和场景，也有对应的适合的分析方式：
- Metrics：通常用于告警和图形化展示，一般直接获取或者辅以简单的计算，例如PromQL、TSQL等
- Traces/Logs：最简单直接的方式是关键词的查询，包括TraceID查询也只是关键词查询的特例
- 数据分析（一般针对Traces、Logs）：通常Traces、Logs还会用于数据分析和挖掘，所以要使用图灵完备的语言，一般程序员接受最广的是SQL
上述的分析方式都有对应的适用场景，我们很难用一种语法/语言去实现所有的功能并且具有非常好的便捷性（虽然通过扩展SQL可以实现类似PromQL、关键词查询的能力，但是写起来一个简单的PromQL算子可能要用一大串SQL才能实现），因此我们的分析引擎选择去兼容关键词查询、PromQL的语法。同时为了便于将各类可观测数据进行关联起来，我们在SQL的基础上，实现了可以连接关键词查询、PromQL、外部的DB、ML模型的能力，让SQL成为顶层分析语言，实现可观测数据的融合分析能力。
可观测性相比传统监控，更多的还是在于数据价值的发掘能力更强，能够仅通过输出来推断系统的运行状态，因此和数据挖掘这个工作比较像，收集各类繁杂的数据、格式化、预处理、分析、检验，最后根据得到的结论去“讲故事”。因此在可观测性引擎的建设上，我们非常关注数据编排的能力，能够让数据流转起来，从茫茫的原始日志中不断的去提取出价值更高的数据，最终告诉我们系统是否在工作以及为什么不工作。为了让数据能够“流转”起来，我们开发了几个功能：
- 数据加工：也就是大数据ETL（extract, transform, and load）中T的功能，能够帮我们把非结构化、半结构化的数据处理成结构化的数据，更加容易分析。
- Scheduled SQL：顾名思义，就是定期运行的SQL，核心思想是把庞大的数据精简化，更加利于查询，例如通过AccessLog每分钟定期计算网站的访问请求、按APP、Region粒度聚合CPU、内存指标、定期计算Trace拓扑等。
- AIOps巡检：针对时序数据特别开发的基于时序异常算法的巡检能力，用机器和算力帮我们去检查到底是哪个指标的哪个维度出现问题，把指标计算成事件，进一步缩小数据量提高信息密度。
10. 可视化与算法
可视化与算法的本质是如何把数据的价值以更好的方式体现出来，作为对接数据与客户诉求的纽带，无论是可视化还是算法的应用场景都会特别多，因此我们更加强调灵活性，注重可编排能力：
- 只做几个基础数据的可视化，更多的大盘组合通过可视化图表的组合来实现
- 针对基础的文本、指标、Trace 数据，提供预置的模型用来快速应用异常检测、预测等功能
- 算法尽可能以框架的方式提供，用户可以基于算法框架接入自定义的数据、进行训练、打标等
11. 探索可观测的本质
在上述采集、存储、计算、可视化和算法的工作上，SLS 已经具备针对所有类型可观测数据的基本能力，用户可以基于 SLS 提供的基础套件构建出自己的可观测解决方案。但由于我们提供的是针对数据的基础能力，用户需要做的二次开发工作相对很多，例如数据格式的定义、数据采集实施、数据格式化、编排大盘、创建告警等，相比门槛还是较高。
因此我们再次从可观测的本质出发，思考如何快速的让数据提供出观测结果：
- 所有的可观测数据，无论是 Trace、Metric、Log 等，都是对某一个实体（也可称之为 Resource）的描述
- 同一实体的观测数据，可以通过实体进行关联，例如通过日志上记录的 IP 找到对应的监控指标
- IT 系统是各类实体结合起来完成某些特定功能，因此同一类型的实体、不同类型的实体之间或多或少存在着一些关系
- 可观测的本质是获得结果（发现问题、定位问题、优化性能...），而这个过程都可以通过这些关系来实现
最终我们期望的形态如上图所示，可观测的数据和实体能够像神经元一样连接起来，而故障的传播更像是神经元的电路传播，我们通过这些连接能够快速的定位问题。排查的示例如下：
- 监控发现某个 Pod 的调用出现错误率上升
- 排查 Trace 拓扑和调用链，发现是调用下游的 Pod1 出现了问题
- 从 Pod1 的更新记录中，查看到了镜像的变更
- 而对应的镜像是因为某个代码库的更新
- 对应代码库的更新记录上看到了某位开发的 Commit 记录
12. 让数据自连接-全栈可观测
基于数据的关联、实体的关联，可观测的问题可以大大简化，因此我们尝试把 SLS 的一些监控、Trace 等 APP 连接起来，形成一个统一的、全栈覆盖的可观测方案：
- 降低实施成本：联合 Trace、全栈监控、用户体验监控（前端/移动端）、性能监控，提供一站式的可观测数据接入方案
- 自动关联：自动计算系统的拓扑，并基于数据与实体关联关系实现所有数据和实体的互相关联
- 统一告警：提供内置的告警和指标巡检，实现统一的事件管理和告警通知
- 智能化：内置 AIOps 套件，实现对指标、Trace、日志的智能分析，同时提供根因分析、Copilot 等高级功能
13. 可观测数据融合
Trace、全栈监控、性能监控等完成了可观测场景中的数据采集，而全栈可观测基于实体关系把这些数据连接成一个大图，把整个可观测场景中涉及的主要实体进行建模：
- 应用服务：主要通过 Trace 的 Service 进行提取并计算相关的指标和拓扑
- 端侧数据：通过用户体验监控，采集移动端设备、Web 的访问、性能、事件等
- 基础设施、K8s、中间件、数据库等：相关数据通过全栈监控一键采集
目前全栈可观测还未做到真正意义的“全栈”，后续还会增加更多的观测数据和实体信息，例如 CodeRepo、变更事件、CICD 系统等。
下述是一个简单的服务与基础设施的关联：
- 每一个服务被抽象为一类实体，服务详情页包括该实体的状态概览，关于它的Trace 调用，相关调用列表，以及上下游拓扑结构
- 在实体详情中，存在一个“相关实例”按钮，点击会自动分析该实体的上下游关联关系
- 例如服务的相关实例就包括：服务包含的调用列表、服务运行于的主机、Pod、Deploy、服务调用的数据库等
- 点击这些相关实例，即可直接查看对应实例的详细信息，用于快速排查出现问题的相关实体是否有问题
14. OpenTelemetry Trace
随着云原生、微服务逐渐在各个行业落地，分布式链路追踪（Trace）也开始被越来越多的公司采用。OpenTelemetry 则是在业界多种 Trace 发展下提出的标准化方案。得益于 SLS 统一的存储计算引擎，我们完全支持 OpenTelemetry Trace、Metirc、Log 的统一方案，主要特性如下：
- 支持OpenTelemetry、SkyWalking、Jaeger等多种Trace协议
- 实时计算服务黄金指标、服务拓扑和依赖关系
- 基于SQL+PromQL的自定义分析
- PB级存储规模，百亿级Trace查询秒级延迟
15. 全栈监控
全栈监控作为基础设置、容器、数据库、中间件、云厂商的监控数据统一接入平台，提供的能力主要有：
- 支持数十种监控数据的一键接入，并提供数十个内置的仪表盘
- 支持IDC、跨云、多云、混合云等多种场景
- 支持Prometheus方式的服务发现，K8s监控友好
- 支持和Trace、日志等数据进行关联打通
- 支持接入自定义的监控数据
16. 前端监控
前端监控相比服务端监控，更加贴近用户的真实使用场景，但由于涉及的场景较多，实施难度相比服务端监控较大。因此我们提供了前端监控，便于快速接入各种前端的观测数据：
- 轻量级SDK，支持Web/H5、微信、钉钉、支付宝等多端
- 提供开箱即用的分析能力，包括用户访问行为、页面性能、API请求、资源加载、JS错误等
- 支持会话追踪功能，可以通过会话火焰图，了解详细的会话过程
- 提供会话回放功能，以可视化方式捕获和回放用户浏览行为
- 支持和Trace服务结合，分析前后端链路追踪数据
17. 移动端监控
移动互联网时代下，几乎每个 ToC 的企业都有自己的移动端 APP，和前端一样，移动端也是最接近用户实际体验的场景。因此我们也提供了移动端监控的能力：
- 统一采集：多形态的移动端 SDK 支持，全面采集端侧现场数据
- 数据整合、关联：云原生 trace 数据，全面拓扑和链路，丰富的流转能力，标准协议，开放接口
- 数据驱动、算法驱动、AI 辅助：智能巡检，自动发现异常，减少人肉运维；根因分析，快速找到 root case
18. 持续性能监控
性能监控用于定位和计算、内存、锁等相关的问题，同时持续性的性能监控对于定位由于版本变更、异常输入等性能退化有很大帮助。SLS 提供的持续性能监控主要有以下特性：
- 支持java、golang、python等多语言性能数据收集
- 低消耗持续性能采集和监控，相比出现问题时临时采集大大提升效率
- 支持多种语言、多种聚合/分析方式
- 内置的对比分析用于快速发现性能退化、瓶颈
- 支持通过Trace进行触发采集，大大提升精确度
19. 总结与展望
目前 SLS 全栈可观测已经正式对外开发，可以先访问 OnlineDemo 来体验相关的功能，后续会逐步增加更多的数据源和功能，充分发挥出数据融合的能力。
SLS 在可观测领域的核心宗旨，还是希望能够更简单的发挥出可观测数据价值，无论是数据采集、存储、分析、可视化、数据融合等，都希望能够在一个尽可能统一的架构下去解决尽可能多的可观测需求。未来我们也会在这个宗旨下持续发展，主要的方面包括
- 更全：支持更多的数据源接入，至少需要覆盖绝大部分的可观测场景。包括更多的数据种类，甚至是图片音视频等
- 更快：持续优化存储查询的性能，在面对数据的指数级膨胀时，依然能保持快速的查询的速度
- 更智能：基于可观测数据种类（Log/Trace/Metric/Profile..）特性，提供更加准确的异常检测；针对实体关联关系，提供一键式的根因定位能力