前言

SLS在2021年4月份正式发布了对OpenTelemetry Trace 1.0版本的支持，完全兼容OpenTelemetry Trace1.0版本的所有字段，提供了Trace显示、分析、拓扑展示等功能（相关文章可以参考SLS Trace介绍）。在功能发布后，众多客户开始接入SLS Trace并深度使用，其中对我们也提出来非常多的建议和需求。从中我们提取出了呼声最高的一些功能和优化点，加入到了SLS的Trace方案1.1版本中。

相关Demo可以登录 https://sls.aliyun.com 直接来玩，免登哦~

Trace的价值所在

在《10个特性：这才是你需要的Trace方案》中，我们详细介绍了为什么需要Trace，以及Trace的功能。Trace的第一诉求是解决分布式/复杂系统（尤其是微服务系统）的问题排查，通过跨系统的调用追踪，找到具体是哪个请求/模块导致了错误/延迟上升。围绕着这点来展开，其实有非常多的工作，不仅仅是能够根据某个TraceID把链路串起来那么简单。这里还包括：

详细的记录When、Where、What信息，否则最多只能知道某个调用出现了问题，而不知道是因为执行了什么操作导致的问题；
作为DevOps工程师、SRE、后端负责人、TL，最先关注的是系统整体的概况，因此Trace的依赖拓扑功能至关重要，需要能够在依赖中尽可能多的计算并展示出系统的概要信息；
具备快速分析的能力，通过过滤、排序、统计等方式，缩小排查范围，然后再根据TraceID信息去聚焦到某个调用上；
TraceID通常都记录在日志中，在日志中找到错误后，查看Trace详情需要跳转到另一个系统中，日志和Trace尽可能需要更好的结合以避免体验的割裂

深入OpenTelemetry规范

在涉及到分布式系统开发的时候，互相之间的调用规范极其重要，大家都要遵循统一的调用协议，例如HTTP、GRPC、Dubbo等。同样Trace也需要统一的规范才能够保证在不同的系统中都可以正常的传播。Trace规范最开始的代表以OpenTracing和OpenCensus为主，后来为了全球化的统一，OpenTracing和OpenCensus已经合并成为了OpenTelemetry，目前也成为了Trace全球事实上的标准规范。

而OpenTelemetry标准带来的好处不仅仅是解决各个系统之间的Trace互通问题，还有统一的SDK、自动化埋点方案、数据采集、Traces/Metrics/Logs互通等等好处。感兴趣的同学可以移步：OpenTelemetry介绍。

相比OpenTracing而言，OpenTelemetry协议在When、What、Where的定义上更加完备，尤其是What和Where。

What：调用执行中具体的操作和相关属性信息，在OpenTelemetry叫做“attribute semantic conventions”，目前协议本身已经定义了包括HTTP、RPC、数据库、消息队列、FAAS、Exception等信息。例如最典型的数据库调用，规定了数据库的类型、连接地址、DB名、Table名、用户名、执行Statement等，如果在调用数据库时，Trace中记录了这些信息，那Trace系统就可以自动理解出你是调用了某个数据库。
Where：调用产生时所在的实例信息，在OpenTelemetry中叫做“resource semantic conventions”，目前协议定义了包括实例的服务名、调用名、主机名、IP等基础信息，也包括K8s Pod、Namespace、Service等云原生信息，还包括部署的环境、软件版本号、进程、Runtime（语言）、OS、Container、云环境等。有这些信息后，就能够使用分析、统计的方式，来对比到底是哪个部署环境、软件版本号、OS版本、主机、运营商的集合出现了问题，快速缩小排查范围。

SLS专为OpenTelemetry定制的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针对OpenTelemetry协议的可视化做了非常多的工作，就拿其中Trace详情展示的功能而言，其中详细展示了Span中When、Where、What信息，而且尽可能在一个页面上展示更多有效的信息。

例如详情信息中，除了展示执行时间跨度、Span所属服务、调用外，还包括Span的调用类型、Span下面的子Span、用颜色区分Service、图标化的方式显示Span的类型信息等。通过这种方式，我们可以很容易看到：

哪些Span是数据库、消息队列的调用
哪个Span执行出现错误
哪个Span执行时间长，尤其需要关注本身执行时间（实线部分）很长的Span

SLS OpenTelemetry Trace新功能

此次带来的Trace新功能，主要也是基于OpenTelemetry标准以及用户呼声，包括：

Trace分类功能：基于OpenTelemetry标准，自动对Trace进行分类
链路拓扑优化：更加直观的拓扑显示，支持切换不同布局、显示PXX延迟
Trace质量分析：通过多种检查项来检测Trace数据是否符合规范，指导如何提高Trace质量
日志关联跳转Trace：从日志查询的结果，可以直接跳转到Trace详情

Trace分类

上图是一个非常典型的应用架构，客户端通过HTTP请求后端，后端部分有一个Frontend来接收客户端的请求，然后根据不同的请求类型执行对应的逻辑，调用其他的系统来完成类似下单、登录、交易等功能。整个系统可能会涉及非常多的团队/小组进行配合，而Trace也需要满足各类不同的需求，例如：

TL、SRE、客户端等同学，更加关注的是Trace入口的各类指标（成功率、QPS、延迟），针对Trace入口排查问题
DBA同学主要关注各个服务调用数据库相关的Span
模块的开发同学在排查问题的时候，首先通过Server类型的数据找到出现问题的接口，然后再通过Client类型排查是不是因为调用下游的服务/DB出现了问题
在进行版本发布的时候，通过过滤不同的版本号来查看新老版本在错误、延迟等核心指标上是否存在变化

为了更好的通过各种分类快速定位各类不同人员需要关心的Trace，SLS基于OpenTelemetry标准内置了多种分类信息，包括Trace入口、Trace类型、版本号、部署环境、调用类型等，可以在Trace概览页和Trace分析的查询框中直接使用。例如下述是Trace概览页中，只关注类型为Server，版本为1.0.0的调用信息。

Trace拓扑优化

拓扑是Trace中非常重要的部分，通过拓扑可以快速了解系统整体的质量、定位有问题的服务。在此次优化中，我们着重优化了Trace拓扑，包括：

显示优化，默认展示QPS、延迟、调用次数等信息，对于出现错误的调用标红并显示错误率
优化拓扑布局，在服务很多的情况也能保持较好的布局效果，且支持两种布局切换
调用关系中的指标增加了PXX延迟，便于监控用户体验相关的延迟指标

Trace质量分析

Trace能够实现的效果和Trace埋点的质量息息相关，例如当排查到是下游问题时发现下游没有记录Trace、当排查到某个Span时发现Span没有记录详细的属性信息。因此为了提高问题排查和定位的效率，我们添加了一个Trace质量分析模块，协助大家分析Trace的质量并给出一些高质量Trace埋点的建议。

目前内置了6大类12小类的检查项（未来的检查项还会逐渐丰富），每个检查会给出检查内容以及通过率，最终给出一个整体得分，相对而言得分如果能在70以上就已经非常优秀了。

日志关联跳转Trace

在实际问题排查中，通常都要结合使用日志、监控、Trace多种数据。如果多种数据存储在不同系统中，互相关联很难做到。目前SLS已经能够原生支持日志（日志库）、监控（Metrics，时序库）、Trace（OpenTelemetry Trace服务）所有数据的存储和分析。

这次的更新中，已经支持配置日志跳转到Trace系统。如果日志中有TraceID、SpanID字段，且Trace已经保存到SLS的Trace服务中，可以通过日志跳转的高级配置选择跳转到指定的Trace实例，直接查看Trace详情。

注：Trace反查日志、Trace与监控指标关联等可观察性数据关联的功能正在开发中，很快就会和大家见面^_^。

总结

SLS的Trace功能核心还是去和OpenTelemetry标准（包括OpenTracing、OpenCensus、SkyWalking等）一起配合使用，SLS提供更加快捷接入、使用简单、无需运维的附加功能。本次方案的更新还是在做深Trace的核心功能，满足各种不同场景的诉求。后续也会根据大家的反馈逐步更新，可联系微信：davidzhang-zc。