简介： SLS在2015年发布了日志（Logs）方案、2020年发布了监控（Metrics），在今年2021年发布了分布式链路追踪（Traces）方案，已经正式具备了可观察性数据的统一存储、分析、可视化能力。后续除了在每个细分数据场景做深外，还会提供更加完善的数据关联方案以及AIOps的异常检测和根因分析能力。

背景

IT系统演进

为了更好的适应商业模式的快速演进，IT核心能力，包括开发模式、系统架构、部署模式、基础设施等在逐步进行升级，让整个IT系统能够保持快速发展的情况下也能具备稳定、高性能、大规模、低成本等特点。但随之也带来了诸多挑战需要我们去面对：

• 效率要求更高：随着DevOps模式的普及，规划、开发、测试、交付..的效率要求越来越高，而与之带来的问题是需要更加实时的知道此次的发布是否成功，出现了什么问题，问题在哪里，如何快速去解决。
• 系统更加复杂：架构从最开始的一体化发展到分层模式，到现在的微服务模式，架构的升级带来了开发效率、发布效率、系统灵活性、鲁棒性等优势，但随之而来系统的复杂度将更高，问题的定位将更加难。
• 环境动态性增强：无论是微服务的架构还是容器化的部署模式，带来的一个特性是环境的动态性会增强，每个实例的生命周期会更短，出现问题后往往现场已经被破坏，登录机器排查问题的方式已经不复存在。
• 上下游依赖更多：问题的定位最终都会从上下游来排查，在微服务、云、K8s的环境中，上下游将更加多，包括各类其他业务应用、云上使用的各类产品、各种中间件、K8s自身、容器运行时、虚拟机等等。

从监控到可观察性

为了保证DevOps开发方式、微服务架构、容器化部署环境、云化环境模式下系统依然具备高可靠性，传统的监控方案正在朝着可观察性方案快速演进，可观察性并不是一个很新的概念，之前Google的《SRE》这本书也介绍了一些相关的内容。

相比而言监控更多的是为了去监控服务的性能、可用性等，能够尽早的发现系统问题，然后问题的定位和解决并不是核心关注点，因此更多的还是采用Metrics这种指标方式定义一些Golden Metric，在出现问题的时候及时通知到对应的负责人去处理。

可观察性在DevOps方式流行起来后开始逐渐被大家接受，对于IT系统而言，稳定性不是及时的发现问题而是及时的解决问题或者说在问题发生之前就能够预防。因此可观察性在传统监控发现问题的基础上，还关注如何定位问题甚至预防问题上，利用白盒化的手段去掌控系统中每个组件的运行状况，包括使用Logs、Traces、Metrics等手段，在发生问题的时候，能够快速去定位到底是哪个模块出问题、报错信息是什么，甚至是定位到代码块。更有甚者，如果有系统的知识经验，还可以给出问题的恢复方案甚至修复方案。

Logs、Traces、Metrics

以Grafana的文章中介绍中的一个典型问题排查过程来看：

1. 最开始我们通过各式各样的预设报警发现异常（通常是Metrics/Logs）
2. 发现异常后，打开监控大盘查找异常的曲线，并通过各种查询/统计找到异常的模块（Metrics）
3. 对这个模块以及关联的日志进行查询/统计分析，找到核心的报错信息（Logs）
4. 最后通过详细的调用链数据定位到引起问题的代码（Traces）

上述例子介绍了如何使用Metric、Traces、Logs去联合排查问题，当然根据不同的场景可以有不同的结合方案，例如简单的系统可以直接通过日志的错误信息去告警并直接定位问题，也可以根据调用链提取的基础指标（Latency、ErrorCode）触发告警。但整体而言，一个具有良好可观察性的系统必须具备上述三种数据。

SLS的目标：可观察性统一平台

对于SLS而言，我们的一大目标就是让DevOps可以更加专注于创造价值，而不是花很多精力在采集数据、监控系统、调查问题等琐碎的事情上。因此我们不仅需要支持Logs、Metrics、Traces的统一存储和分析，还必须具备可以把这些数据有效关联的能力，比如基于标准化的关联规则、基于机器学习的AIOps等能力。

SLS在2015年发布了日志（Logs）方案、2020年发布了监控（Metrics），在今年2021年发布了分布式链路追踪（Traces）方案，已经正式具备了可观察性数据的统一存储、分析、可视化能力。后续除了在每个细分数据场景做深外，还会提供更加完善的数据关联方案以及AIOps的异常检测和根因分析能力。

SLS的Trace服务

SLS的Trace服务并不是自己从头到尾造轮子，上篇文章《10个特性：这才是你需要的Trace方案》中我们也讲到，Trace必须要遵循统一的规范，OpenTelemetry是目前全球公认的Trace标准化方案，而且OpenTelemetry本身也兼容了Jaeger、Zipkin等OpenTracing协议、OpenCensus等方案，所以我们并不会独立再造一个协议，而是直接以OpenTelemetry为SLS的Trace标准协议去提供服务。

所以可以说SLS的Trace服务更像是对OpenTelemetry的补充，OpenTelemetry定义了Traces规范、各种SDK实现以及数据的采集Agent，而SLS则支持OpenTelemetry Traces数据的存储、分析、可视化、告警以及后续的AIOps等能力。

SLS Trace1.0 功能

OpenTelemetry标准

目前也有一些公司开始支持了OpenTelemetry数据的接入，但都是把OpenTelemetry数据转换成公司自己内部的标准，因此无论如何都会有一定的数据损失，无法达到100%兼容。而SLS Trace服务是直接基于OpenTelemetry数据格式来开发的，所有的存储格式定义完全兼容OpenTelemetry标准（详情可参考《SLS Trace格式定义》），因此可以做到：

1. Trace数据传播支持OpenTelemetry各种的传播协议，Trace可以打通到各种开源的组件内部，保证整个链路的覆盖度足够的高
2. 各类属性信息的语义可以完美支持，包括Resource/Attribute等，例如Resouce标识了Trace的来源信息，包括主机名、服务名、版本号、发布环境、K8sPod/Deploy等信息，能够更好的适应现代化的IT环境
3. 后续可以更好的支持Metrics、Logs，目前OpenTelemetry只有Trace方案的定义到1.0的稳定版，未来等Metrics、Logs定义完善后，SLS会第一时间支持，做到OpenTelemetry可观察性数据的统一平台

Trace数据接入

作为服务型的产品，SLS的Trace服务只需要在页面上点击几下即可开通，不需要自己去部署、运维Trace的后端，因此对于使用者来讲，只需要能够把Trace接入基本上已经完成了绝大部分的工作量。而SLS在接入这个步骤也尽可能提供更加便捷和多种的方式来适应不同技术栈、架构或者已有的Trace方案。

1. SLS服务端直接内置了多种Trace协议的接入点，只需要在Trace客户端SDK中配置接入点信息即可以完成接入，目前内置的协议有：OpenTelemetry、Jaeger、Zipkin、OpenCensus
2. SLS在2020年已经正式支持OpenTelemetry Collector写入到SLS，因此OpenTelemetry Collector支持的各类Receiver都能够以OpenTelemetry协议写入到SLS，例如AWS的X-Ray、SignalFx等商业软件也可以
3. 如果使用的是SkyWalking方案，也可以接入到SLS，只需要部署SLS的最新版本Logtail即可
4. 对于其他的或者自建的Trace协议，比如阿里的鹰眼Trace，只需要把数据写入到SLS后用ETL进行格式转换即可使用。

当然，如果是新建设的Trace方案，还是建议大家尽可能使用OpenTelemetry的方案，毕竟其他的协议都是转换到OpenTelemetry格式，而且其他协议的定义都没有OpenTelemetry规范和严谨，相对更加能发挥Trace的优势。

关于接入的详细介绍可以参考：《SLS Trace数据接入概览》。

指标计算

借助于SLS强大的计算能力，我们会将Trace数据按照不同的服务、调用实时进行预计算，提取出包括延迟、错误率、QPS等Trace的黄金指标。并且对于延迟还支持PXX的分位数计算，能够更加真实的反应出用户的实际使用体验。

Trace展示

Trace展示是最基本的需求，因此这里不多做介绍。借助于OpenTelemetry的规范，我们能够非常清晰的知道数据来自于哪个语言、调用的是什么协议、调用类型、调用结果、错误信息等，以图形化的方式把这些数据展示在一张图上，并且所有的属性和信息都支持关联跳转到Trace分析。

Trace分析能力

Trace数据的丰富度极强，如果仅仅用来根据TraceID展示就大大浪费了其价值，因此自定义、多维度的分析能力才能更加充分发挥Trace价值。SLS内置了Trace的分析能力，并支持Query Builder辅助大家更好的过滤出想要关注的Trace数据，只需要用界面中的各类条件组合即可完成，而且每个组合的可选值都会自动提示出来。

点击查询按钮会自动过滤出符合条件的Trace数据，概览框中会显示查询范围内的Trace分布、错误率、延迟等信息，分析框中会显示这些Span的详细信息。同时还支持按照各种自定义的维度进行统计分析，例如下述示例会查找出user服务延迟超过1ms的Span，并按照调用为分组来分析这些Span的分布。

可扩展性

SLS Trace服务的可扩展性极强，主要包括OpenTelemetry Trace协议本身的可扩展性以及SLS自身能力的扩展上：

1. OpenTelemetry协议中Traces的规范相对非常完整，后续的Resource、Attribute字段可以任意扩展；此外后续Logs、Metrics规范Release 1.0版本后，SLS目前的Trace服务也会直接升级到SLS OpenTelemetry服务，目前默认的Trace实例中已经创建出了Logs、Metrics的相关资源，而且部分场景中Metrics已经在使用中，例如Java Agent、SkyWalking、Golang SDK等。
2. SLS本身提供了SQL92分析语法，数据加工、可视化仪表盘、告警等功能，Trace服务可以直接基于这些功能去定义一些自定义的场景，此外支持数据队列（类Kafka）的功能，可以对接各类下游的流计算、离线计算。

特性总结

SLS Trace方案定位是SLS可观察性解决方案中的一环，从Trace服务本身出发，SLS主要想为大家带来具备几大特性的方案：

1. Trace数据全覆盖：除了OpenTelemetry的原生支持外，能够覆盖市面上主流的各类Trace方案，尤其是开源场景，保证数据接入的能力足够全面。
2. 和其他数据关联：SLS自身已经可以支持Traces、Metrics、Logs所有可观察性数据的统一存储分析，因此更容易为大家构造出一个可以快速关联其他数据的平台，让问题排查能够在一个系统中完成，减少复杂度。
3. 云原生的Trace服务：作为云上的服务，SLS的Trace方案依旧是按量计费的模式，无需自己去部署、运维Trace系统本身，并且支持弹性扩容、高可靠性等高级能力。
4. 简单易用：无论从数据接入还是使用上，SLS Trace服务都尽力为大家提供简单易用的方案，例如各类Trace协议直写SLS后端、内置Trace指标计算、图形化Trace分析等，后续还会提供更多简单的Trace分析功能。
5. 智能化：虽然目前SLS Trace1.0的版本还没有内置集成SLS的各类AIOps算法，但马上1.1版本中我们就会发布非常多的自动Trace分析功能，让AIOps都能普惠到各个云上的用户。

后续SLS Trace的规划

SLS Trace的方案基本上是按照上篇文章《10个特性：这才是你需要的Trace方案》中定义的路线来发展，目前我们发布的1.0版本已经具备了1-6的特性，因此后面的主要精力除了让Trace服务更加简单易用外，还会逐步具备6-10的能力，目前在规划和进展的功能/优化有：

1. 接入体验优化：我们会提供更多的接入示例，方便大家快速去接入不同语言不同平台的Trace数据，同时还会提供一个微服务示例，让大家能够快速体验Trace服务的优势
2. Trace使用的最佳实践系列：Trace无论是产生还是使用都有一定的门槛，因此我们会大家提供一个最佳实践系列，让绝大部分的人都可以用好Trace，充分发挥Trace价值
3. 一键告警配置功能：目前告警配置还只能用SLS的通用告警功能，相对工作量比较大，后面会提供按照Trace服务、调用来一键配置、快速配置Trace告警的功能
4. Trace自动分析：利用AIOps中的模式分析算法，自动去分析引起Trace错误率提升或者延迟上升的模式组合，快速找到具体是哪个服务、哪个调用、哪台机器、哪种接口引起的问题
5. Trace Compare功能：支持和历史某个时间段或者某个服务版本进行对比分析，快速找到服务发布后主要由哪些部分导致了问题的发生
6. 关联Logs、Metrics功能：目前Trace服务自身的数据关联还只是Trace内部自循环，后续会提供各类跳转的能力，便于去关联到与Trace相关的日志、监控信息
7. 关联内置Metrics功能：目前Java Agent、SkyWalking、Golang SDK等都内置了一些指标，例如GC信息、主机指标、进程指标等，后续Trace服务会支持在显示的过程中直接关联这些内置指标，方便定位问题
8. Trace自定义Dashboard：Trace的查询分析能力目前只能在Trace服务自身进行使用，后续会支持将分析能力提取成Dashboard中的Chart，支持和日志、监控一起编排到一张Dashboard进行查看。

https://developer.aliyun.com/article/783621?utm_content=g_1000264832

本文为阿里云原创内容，未经允许不得转载。