释放Trace的价值-SLS OpenTelemetry新功能直击痛点-阿里云开发者社区

开发者社区> 阿里云存储服务> 正文
登录阅读全文

释放Trace的价值-SLS OpenTelemetry新功能直击痛点

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

前言

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

Trace的价值所在

image

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

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

深入OpenTelemetry规范

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

image

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

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

  1. What:调用执行中具体的操作和相关属性信息,在OpenTelemetry叫做“attribute semantic conventions”,目前协议本身已经定义了包括HTTP、RPC、数据库、消息队列、FAAS、Exception等信息。例如最典型的数据库调用,规定了数据库的类型、连接地址、DB名、Table名、用户名、执行Statement等,如果在调用数据库时,Trace中记录了这些信息,那Trace系统就可以自动理解出你是调用了某个数据库。
  2. 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标准协议去提供服务。

image


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

SLS针对OpenTelemetry协议的可视化做了非常多的工作,就拿其中Trace详情展示的功能而言,其中详细展示了Span中When、Where、What信息,而且尽可能在一个页面上展示更多有效的信息。

image

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

  1. 哪些Span是数据库、消息队列的调用
  2. 哪个Span执行出现错误
  3. 哪个Span执行时间长,尤其需要关注本身执行时间(实线部分)很长的Span

image

SLS OpenTelemetry Trace新功能

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

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

Trace分类

image

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

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

image

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

image

image


Trace拓扑优化

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

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

image

Trace质量分析

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

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

image

image

日志关联跳转Trace

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

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

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

image

总结

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

对我们工作感兴趣的,可以通过如下方式了解更多,谢谢关注:)

参考

  1. https://developer.aliyun.com/article/783270
  2. https://zhuanlan.zhihu.com/p/366270515
  3. https://developer.aliyun.com/article/766070
  4. https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/README.md
  5. https://github.com/open-telemetry/opentelemetry-specification/tree/main/specification/resource/semantic_conventions

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

阿里云存储基于飞天盘古2.0分布式存储系统,产品多种多样,充分满足用户数据存储和迁移上云需求。

官方博客
最新文章
相关文章
存储产品
客户案例