我眼中的OpenTracing

简介: 我眼中的OpenTracing

一、OpenTracing 是什么?

分布式链路跟踪最先由 Google在 Dapper论文中提出的一套链路追踪的 API 规范,支持多种编程语言,与平台无关、与厂商无关,使得开发人员能够方便的添加(或更换)链路跟踪系统的实现,虽然OpenTracing不是一个标准规范,但现在大多数链路跟踪系统都在尽量兼容OpenTracing。目前符合这API标准的就有 SkyWalking,Jaeger,Zipkin,Open Telemetry,Pinpoint、CAT等等

Opentracing 核心接口

Tracer:调用链,追踪链路,一个trace是由若干span组成的有向无环图,Tracer 对象可以用来创建 Span 对象(记录分布式操作时间)、跨机器透传数据(Extract/Inject 方法),或设置当前 Span(activeSpan)。Tracer对象还配置了上报数据的网关地址、本机 IP、采样率、服务名等数据。您可以通过调整采样率来减少因上报数据产生的开销

Span Tracer 中的基本单元,一个span代表应用中的一个逻辑操作,

span属性

Operation name:操作名
Start timestamp:开始时间
Finish timestamp:完成时间
Span Tag:标签集合,一组键值对,键必须为字符串,值为字符串/数字或布尔
Span Log: 日志集合,没条日志包含一个键值对和一个时间错。
SpanContext:上下文
Baggage items:trace的随行数据,是一组键值对,也需要跨进程传输。

SpanContext : Span 上下文,用于跨进程传递 Span,以及数据共享

ScopeManager:用于获取当前上下文中 Span,或者将 Span 设置到当前上下文

Scope:与 ScopeManager 配合使用,

Span 之间的关系分父子关系ChildOf和跟随关系FollowsFrom。

OpenTracing API 介绍

包含三个相互关联的类型 Tracer/span/spanContext

Tracer API

用于创建span,以及处理跨进程传递中的序列化。

tracer.buildSpan

参数:

Operation name:必填,操作名,span的具体工作,如getUserInfo

SpanContext:关联关系,包括关系类型

Start timestamp:默认为当前时间

Tag:0或多个

返回值:返回一个已启动且未结束的span。

将SpanContext注入inject到Carrier中

参数:

SpanContext实例

Format:格式化描述,一般就是字符串

Carrier:将format的后的数据序列化到carrier中

将SpanContext从Carrier中提取extract

参数:

Format:格式化描述

Carrier:从carrier中根据format反序列化出SpanContext。

返回值:SpanContext

Format结构:

Text Map:字符串Map

HTTP Headers:header信息,基于字符串Map

Binary:二进制大对象,SpanContext信息。

Span API

当Span结束span.finish后,除了获取span的SpanContext,其他操作都不被允许。

获取SpanContext

修改operation name

参数:new operation name,新的操作名词。

结束span finsh

参数:finish timestamp,完成时间

设置tag

参数:

tag key

tag value

设置结构化Log数据

参数

一个或多个log键值对,必填

时间戳,选填

设置Baggage随行数据

键值对集合,存入spancontext进行传递,会对io和cpu带来额外开销,谨慎使用。

参数:

Baggage key:字符串

Baggage value:字符串

获取Baggage元素

参数:baggage key

返回值:Baggage value

参考:

https://github.com/opentracing-contrib/opentracing-specification-zh

目录
相关文章
|
存储 Prometheus Kubernetes
OpenTelemetry 简析
OpenTelemetry 是 CNCF 的一个可观测性项目,旨在提供可观测性领域的标准化方案,解决观测数据的数据模型、采集、处理、导出等的标准化问题,提供与三方 vendor 无关的服务。 2021.02.10,OpenTelemetry 的 tracing spec 达到 1.0 版本 (link),基于这个里程碑,笔者对 OpenTelemetry 进行了探索,判断在可观测性领域带来的价值和发展前景。 下面给出笔者对 OpenTelemetry 的理解,抛砖引玉。由于笔者能力有限,理解不当的地方请大家指正。
OpenTelemetry 简析
|
1月前
|
Cloud Native 测试技术 Go
开源之夏经验分享|MOSN 社区韦鑫:做自己认为很酷的事
韦鑫是南京航空航天大学计算机科学与技术学院研三学生,研究方向为分布式系统。作为HTNN社区贡献者,他参与了开源之夏2024 MOSN社区项目,负责将Sentinel-golang流量控制能力集成到MOSN on Envoy(MoE)生态中。通过该项目,韦鑫不仅提升了对服务网格和云原生网关的理解,还学会了如何开发HTNN插件,并深刻体会到严格的单元测试、集成测试及CI/CD对项目的重要性。他的经历展示了积极参与开源项目的价值,鼓励更多人勇敢尝试并投身于开源社区。
开源之夏经验分享|MOSN 社区韦鑫:做自己认为很酷的事
|
8月前
|
监控 负载均衡 Dubbo
《Dubbo架构设计大揭秘:八大层次,带你领略微服务之美!》
【8月更文挑战第24天】Dubbo是一款广泛应用于微服务架构中的高性能Java RPC框架。其设计强调可扩展性和可维护性。整体架构分为八个层次:接口层定义服务API;代理层处理RPC请求;服务层实现接口;注册中心层管理服务注册与发现;路由层实现服务寻址;监控层收集调用数据;集群层提供负载均衡及容错;远程调用层负责网络通信。各层职责分明,便于应对多变的业务需求。
71 1
|
10月前
|
监控 Java API
Java日志框架的纷争演进与传奇故事
Java日志框架的纷争演进与传奇故事
|
11月前
|
Kubernetes Dubbo Cloud Native
【Dubbo3技术专题】总体技术体系介绍及技术指南(序章)
【Dubbo3技术专题】总体技术体系介绍及技术指南(序章)
92 1
|
11月前
|
前端开发 算法 JavaScript
IT圈的技术争论与合作:揭秘鄙视链的背后
IT圈的技术争论与合作:揭秘鄙视链的背后
|
Kubernetes 负载均衡 Dubbo
【Dubbo3.0技术专题】总体技术体系介绍及技术指南(序章)
【Dubbo3.0技术专题】总体技术体系介绍及技术指南(序章)
436 0
【Dubbo3.0技术专题】总体技术体系介绍及技术指南(序章)
|
设计模式 监控 IDE
探析Java日志框架
        目前,几乎所有的应用程序中,都会用到日志框架来记录程序的运行信息。日志虽然不影响应用程序的运行结果,但是没有日志的应用程序是不健全,不完整的。良好的日志系统可以帮助我们快速的定位到程序问题,包括近几年火起来的日志分析系统,比如ELK,日志在我们系统中被重视起来,也起到了举足轻重的作用
155 0
|
设计模式 数据处理
【参与评论有奖】把书读薄 | 《设计模式之美》总结篇(下)
从六月开始,断断续续,算是把王争的《设计模式之美》看得差不多了,实战部分没来得及看,不过也是获益良多,思维方式上的一些变化。肚子里的墨水不多,不知道如何描述这种感觉,说两个实际的应用场景,读者自行意会哈,顺便带出总结思维导图~
242 0
|
设计模式
【参与评论有奖】把书读薄 | 《设计模式之美》总结篇(上)
从六月开始,断断续续,算是把王争的《设计模式之美》看得差不多了,实战部分没来得及看,不过也是获益良多,思维方式上的一些变化。肚子里的墨水不多,不知道如何描述这种感觉,说两个实际的应用场景,读者自行意会哈,顺便带出总结思维导图~
256 0
下一篇
oss创建bucket