Go Tracing Roadmap

转载 2017年05月27日 10:04:54

Go Tracing Roadmap golang 分布式追踪的路演, 今后可能直接从语言层面支持这些特性,golang真是太棒了, 原始文档在 google doc 上,可能有些同学网络不太方面,所以转一份在这里。

Jaana B. Dogan (jbd@golang.org), May 15, 2017

This document summarizes the state of the distributed tracing related work for the Go ecosystem. It is recommended to read the Dapper (google 2010年发表的一个关于分布式追踪系统架构的论文) paper before reading this document to understand the higher level concepts and terminology in distributed tracing.
Dapper, a Large-Scale Distributed Systems Tracing Infrastructure


Go ecosystem provides a large set of solutions for distributed tracing such as x/net/trace, OpenTracing, tracing backend-specific clients, etc. Few months ago, we wanted to see if we can unify the existing solutions and use a single set of unified API and utilities to back the current tracing providers. Our main goals were to:

  • Defrag the ecosystem and make instrumentation portable regardless of which tracing backend users depend on.
  • Enable the library ecosystem to utilize the current trace context if any without having to depend on a specific tracing backend.

It soon became clear that there are two critical barriers to achieve a common API:

  • Tracing is a multi language problem. Our design decisions needs to be reflected in other language ecosystems to provide a proper end-to-end tracing solution. As the Go authors, it is beyond our scope.
  • Tracing backends and their data models are still widely different and achieving a common API that covers 80-90% of the use-cases is hard.

Additional to these critical barriers, depending on the initial research and several 1:1s we made with some of the Go users, our conclusion is that language ecosystems are suffering from the lack of a common data model and wire format rather than the lack of a common tracing library.

As we were having the initial conversation on tracing, there has been an ongoing effort in the tracing community to establish a trace context standard and a common encoding/decoding algorithm for span identifiers and the propagated labels.

As a result, our focus has shifted from achieving a common API to supporting open standard initiatives and making sure Go is well presented. We are currently collaborating to the broader tracing standardization effort. The ideal outcome of our collaboration will:

  • Allow users to propagate traces among Go and non-Go services regardless of the backend.
  • Allow users to be able to propagate traces within ecosystem libraries. Currently, trace contexts are dropped during medium/transport changes, e.g. when an HTTP request/response is wrapped by a Go API or a gRPC request is followed by an HTTP request. Provide a minimal Go building block to represent a trace context and enable the ecosystem propagating traces using that building block.
  • Allow users to be able to discover the current trace context from a context.Context.
  • Start discussion about where standard library can benefit from out-of-the-box tracing support.
  • Establish utility libraries to make it easier to enable tracing out-of-the-box without manual instrumentation: Tracing-enabled handlers, http.Client, and similar.
  • Enable a solution that scales both small- and large-scale in terms of performance characteristics.


Our roadmap is currently primarily blocked by the the emerging standards group because our priority is to align well with the tracing community and adopting their solutions rather than inventing anything Go-specific. Our next steps can be summarized as:

  • Work with the standards group to represent Go user’s concerns. If standards are not achieved or widely adopted, a backend-agnostic generic Go-specific solution will be considered.
  • Implement a trace package with the standard trace context representation and propagation primitives (e.g. propagating in context.Context and as an HTTP header) .
  • Open a discussion in the community to utilize the trace propagation package, help current tracing libraries to adopt these types where possible. Open discussion for the standard library tracing support.

The following sections will give more details about the specifics of the work required for some items.

Trace context

In a tracing system, trace context is the smallest state carrying object. It identifies a unit of work and carries labels that represent additional metrics/data in the scope of a the work.

Each tracing system has a trace context format and a spec how it should be carried in wire (e.g. via an HTTP request). An example of a trace context propagated via an HTTP header:

    GET /service HTTP/1.1
    Trace-Id: 4bf92f3577b34da6a3ce929d0e0e4736/e1;o=0

Today, trace context formats are often incompatible with each other; a context generated from a tracing backend cannot be parsed by another one. Compatibility issues restrict users to depend on a single backend end-to-end and use backend-specific instrumentation libraries to utilize the trace context.

Until a standard establishes, the trace context can only be represented by an identifier and a labels byte slice that both can later be parsed by the backend specific instrumentation libraries; given backend-specific library is the only layer knows about the encoding/decoding algorithm.

package trace

// Span represents a unit of work.
// ID identifies a span globally in a tracing system.
// Annotations return the labels propagated with the span.
// Encoding algorithm might be tracing-backend specific.
type Span interface{
    ID() []byte
    Labels() []byte

This overly generic representation of trace context is not very useful, especially for the library ecosystem that wants to instrument code (e.g. creating new child spans, attaching additional labels) without any dependencies to specific backends.

At this point, we propose to contribute to the establishment of the industry-wide wire standard and draft our design according to this standard rather than inventing a Go-specific representation. The outcome of this work will be:

  • A span context encoding format standard that is well accepted by top tracing backends.
  • A concrete span context type, and encoders/decoders in Go.

Propagation via context.Context

Being able to discover the trace contexts from the current context also is widely required. By blessing a canonical way to access trace context, we are enabling different libraries cooperate on the same trace.

package trace

// NewContext returns a derived span from the current context.
func NewContext(ctx context.Context, s Span) context.Context

// FromContext returns the span contained in the context or nil.
func FromContext(ctx context.Context) Span

Standard library support

If the proposed trace package gets into the standard library, with the first-class availability, we may be able to enable tracing support for some of the existing packages.

For example, net/http package can automatically extract the trace context from incoming HTTP request’s headers and put it in the request context. Similarly, it can inject trace context header if the request context contains a trace context.

We will open discussions and follow up with proposals once there is a trace package.


  • We cannot foresee when an open context trace standard will be mature and finalized. Before such standard is finalized, we are blocked on designing the trace context type.
  • There are already several custom trace context types contributed by the community, e.g. OpenTracing’s SpanContext. Unifying the APIs around the new type will require a lot of consensus and work.
  • Propagation primitives only provide a building block. Without a fully featured solution, it is hard to pitch the building block’s itself. We need to work closely with the current tracing libraries and make sure the building block is utilized before we
  • If the tracing community cannot achieve an open standard, our generic trace context type ([]byte, []byte) is not very useful.


为什么需要Tracing? 开发和工程团队因为系统组件水平扩展、开发团队小型化、敏捷开发、CD(持续集成)、解耦等各种需求,正在使用现代的微服务架构替换老旧的单片机系统。也就是说,当一个生产系统面对...
  • u011537073
  • u011537073
  • 2017年10月20日 21:01
  • 330

Go Tracing Roadmap

Go Tracing Roadmap golang 分布式追踪的路演, 直接从语言层面支持这些特性,golang真是太棒了, 原始文档在 google doc 上,可能有些同学网络不太方面,所以转一...
  • lzz957748332
  • lzz957748332
  • 2017年05月27日 10:04
  • 686


欢迎转载,但请务必在明确位置注明出处!http://stormzhang.com/android/2014/07/07/learn-android-from-rookie/ QQ交流群:入群理由请正...
  • u011613321
  • u011613321
  • 2015年04月16日 21:50
  • 512

怎么做 Product Roadmap

怎么做Roadmap? 1、拆分不同类型的工作 2、制定工作框架 3、根据目标做计划 Roadmap有的人翻译成路线图,有的人翻译成蓝图,无论怎么翻译,其所要表达的本质是一样的,就...
  • hellofeiya
  • hellofeiya
  • 2015年02月11日 10:06
  • 1249


http://www.tuicool.com/articles/za6F7zE 译自 tylerchr 的 What's Coming in Go 1.8 。 随着Go 1.8 新特性的开发工作...
  • kenkao
  • kenkao
  • 2017年01月20日 16:00
  • 4091


1.为什么使用信道(channel)而不使用TCP连接发送AMQP命令? 对操作系统来说频繁的建立和销毁TCP连接开销非常昂贵,而操作系统每秒建立的连接是有上限的,性能瓶颈不可避免,而只建立一条TCP...
  • fyxichen
  • fyxichen
  • 2016年09月26日 17:45
  • 2026


那么就向大家介绍一些Java学习的RoadMap吧基础的呢:sun的java培训教材,最好是英文的 免费有的下进一步:Effective Java,design patterns exploring,...
  • zheng_nan
  • zheng_nan
  • 2006年07月12日 16:26
  • 521

mtk roadmap 2017 2016 2015

  • pan0755
  • pan0755
  • 2017年02月27日 14:59
  • 3205

Golang 微服务框架 Go kit 介绍

go-kit 入门 1. microservice Go-Kit go kit 是一个分布式的开发工具集,在大型的组织(业务)中可以用来构建微服务。其解决了分布式系统中的大多数常见问...
  • warrior_0319
  • warrior_0319
  • 2017年08月25日 09:19
  • 3181


1,关于豌豆荚开源的CodisCodis是豌豆荚使用Go和C语言开发、以代理的方式实现的一个Redis分布式集群解决方案,且完全兼容Twemproxy。Twemproxy对于上一层的应用来说, 连接C...
  • freewebsys
  • freewebsys
  • 2015年03月06日 17:04
  • 13399
您举报文章:Go Tracing Roadmap