【学习笔记】分布式追踪Tracing

最新推荐文章于 2024-08-23 03:02:36 发布

云树在路上

最新推荐文章于 2024-08-23 03:02:36 发布

阅读量3.7k

点赞数 1

文章标签： java 分布式监控类 apm

本文链接：https://blog.csdn.net/hiwatershed/article/details/111591675

版权

本文介绍了分布式追踪的重要性及其与Logging和Metrics的区别。重点讲解了OpenTracing作为标准化层的角色，Jaeger作为分布式追踪系统的实现，以及dd-trace-java作为Datadog的APM客户端。OpenTracing提供了跨平台的API，Jaeger包含了数据采集、持久化和展示，而dd-trace-java依赖Jaeger并采用字节码注入技术进行埋点。

摘要由CSDN通过智能技术生成

在软件工程中，Tracing指使用特定的日志记录程序的执行信息，与之相近的还有两个概念，它们分别是Logging和Metrics。

Logging：用于记录离散的事件，包含程序执行到某一点或某一阶段的详细信息，比如，应用程序的调试（debug）信息或错误（error）信息。它是我们诊断问题的依据。
Metrics：用于记录可聚合的数据，且通常是固定类型的时序数据，每个都是一个逻辑计量单元，或者一个时间段内的柱状图，比如，队列的当前深度可以被定义为一个计量单元，在写入或读取时被更新统计；输入HTTP请求的数量可以被定义为一个计数器，用于简单累加；请求的执行时间可以被定义为一个柱状图，在指定时间片上更新和统计汇总。
Tracing：用于记录单次请求范围内的处理信息，其中包括服务调用和处理时长等，比如，一次调用远程服务的RPC执行过程；一次实际的SQL查询语句；一次HTTP请求的业务性ID。它是我们排查系统性能问题的利器。

系统架构从单体转变为微服务以后，一次请求往往涉及到多个服务之间的调用。随着服务数量的增多和内部调用链的复杂化，仅凭借日志和性能监控很难做到 “See the Whole Picture”，在进行问题排查或是性能分析的时候，无异于盲人摸象。

分布式追踪系统（Tracing）旨在分析请求背后调用了哪些服务，服务的调用顺序、耗时、错误原因等，帮助开发者直观分析请求链路，快速定位性能瓶颈，逐渐优化服务间依赖，也有助于开发者从更宏观的角度更好地理解整个分布式系统。

早在 2005 年，Google 就在内部部署了一套分布式追踪系统 Dapper，并发表了一篇论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，阐述了该分布式追踪系统的设计和实现，可以视为分布式追踪领域的鼻祖。随后各大厂商纷纷落地了一些优秀的分布式追踪系统，比如Jaeger（Uber）、Zipkin（twitter）、X-ray（AWS）、SkyWalking等，但各家的分布式追踪方案很可能是互不兼容的，于是诞生了OpenTracing。

1. OpenTracing

OpenTracing是一个轻量级的标准化层，它位于<应用程序/类库>和<追踪或日志分析程序>之间，通过提供平台无关、厂商无关的API，使得开发人员能够方便的添加（或更换）追踪系统的实现，解决不同的分布式追踪系统API不兼容的问题，也使得在通用代码库增加对分布式追踪的支持成为可能。

后台无关的一套接口，被跟踪的服务只需要调用这套接口，就可以被任何实现这套接口的跟踪后台（比如Zipkin, Jaeger等等）支持，而作为一个跟踪后台，只要实现了个这套接口，就可以跟踪到任何调用这套接口的服务。
标准化了对跟踪最小单位Span的管理：定义了开始Span，结束Span和记录Span耗时的API。
标准化了进程间跟踪数据传递的方式：定义了一套API方便跟踪数据的传递。
标准化了进程内当前Span的管理：定义了存储和获取当前Span的API。
不对编码定标准：不对进程间传递的跟踪数据的编码定标准，不对向后台发送的跟踪数据的编码定标准，让跟踪后台自己决定最适合他们的编码方式。

OpenTracing已进入 CNCF，正在为全球的分布式追踪，提供统一的概念和数据标准，支持多种语言：https://github.com/opentracin