OpenTracing:开放式分布式追踪规范

前言

想实现一个简单的追踪系统似乎是容易的，需要必要的调用链id,时间戳等；想实现一款易用不侵入代码的追踪系统就很麻烦了，需要接触CLR和IL相关知识；即使你费劲心力做出了那些，如果性能不够好，也没有人使用的。
追踪系统主要可以分两部分实现，客户端和服务端。大软件厂商基于各自的需求已经开发了APM，从头迈入这个圈子的个人拿什么去竞争？最后的结果基本都是凉凉了。合作共赢才是最好的。

从我学习分布式调用链开始，就打算了解客户端和服务端的通信规范，我选择了zipkin入门，基本了解了一些zipkin的模型。我打算多接触几个其他调用链，看看其他的通信模型有什么区别，然后写一个能适应不同模型的第三方规范。这只是最开始的想法，生态繁杂，如果写的东西不能共用，那费力写的东西并没有意义。

当我进一步学习，看到了OpenTracing的介绍，我仿佛找到了道友，云开得见月明。

当我看到了支持opentracing的追踪系统包含SkyWalking时，更坚定了我的信心。

OpenTracing介绍[译]

为什么追踪？

当代分布式跟踪系统（例如，Zipkin，Dapper，HTrace，X-Trace等）旨在解决这些问题，但它们通过使用不兼容API的应用程序级检测来实现。开发人员对将其多语言系统与任何特定的分布式跟踪实现紧密耦合感到不安，但这些许多不同跟踪系统的应用程序级检测API具有非常相似的语义。

为什么选择OpenTracing？

进入OpenTracing：通过为流行的平台提供一致的，富有表现力的，供应商中立的API，OpenTracing使开发人员可以轻松地通过O（1）配置更改添加（或切换）跟踪实现。OpenTracing还为OSS检测和特定于平台的跟踪帮助程序库提供了通用语言。请参阅语义规范。

什么是追踪?

在最高级别，跟踪讲述了事务或工作流在通过（可能分布式）系统传播时的故事。在OpenTracing中，跟踪是“跨度”的有向非循环图（DAG）：命名的定时操作，表示该跟踪中的连续工作段。

image

分布式跟踪中的每个组件都将贡献自己的跨度或跨度。例如，在简单的RPC的情况下，OpenTracing要求客户端和服务器将它们各自在工作流中的角色表示为至少一个跨度。

image

父跨度可以显式地以串行或并行方式启动其他跨度。在OpenTracing中，甚至可以用多个父模型建模子跨度（例如，缓冲区刷新可以从填充所述缓冲区的多个写入中下降）。

一个基本的痕迹

image

通过分布式系统跟踪工作流或事务通常看起来如上所述。虽然这种类型的可视化对于查看各种组件如何组合在一起是有用的，但是它不传达任何持续时间，不能很好地扩展，并且在涉及并行性时是麻烦的。另一个限制是无法轻易显示延迟或时序的其他方面。甚至基本跟踪可视化的更有用的方法通常如下所示：

image

这种类型的可视化添加了时间上下文，所涉及服务的层次结构以及进程/任务执行的串行或并行特性。此视图有助于突出显示系统的关键路径。通过关注关键路径，注意力可以集中在可以进行最有价值改进的代码区域。例如，您可能希望将API请求中的资源分配范围跟踪到底层阻塞调用。

内容来自官网，详情查看opentracing

OpenTracing语言支持

• Go - opentracing-go
• Python - opentracing-python
• Javascript - opentracing-javascript
• Java - opentracing-java
• C# - opentracing-csharp
• Objective-C - opentracing-objc
• C++ - opentracing-cpp
• Ruby - opentracing-ruby
• PHP - opentracing-php
  我们重点关注下opentracing-csharp

opentracing-csharp

适用于.NET的OpenTracing API

必读

为了理解.NET平台API，首先必须更熟悉 OpenTracing项目和 术语。