Go Tracing Roadmap

This is a creation in Article, where the information may have evolved or changed.

Go Tracing Roadmap Golang distributed Tracking Roadshow, in the future may directly from the language level to support these features, Golang is really great, the original document on Google Doc, there may be some students network is not too, so turn a copy here.

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 (a paper on distributed tracking system architecture published by Google in 2010) paper before reading this document to understand th e Higher level concepts and terminology in distributed tracing.

Dapper, a large-scale distributed Systems tracing Infrastructure

Background

Go ecosystem provides a large set of solutions for distributed tracing such as x/net/trace , OpenTracing tracing backend-specific Clie NTS, 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 the 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 have to depend on a specific tracing BA Ckend.

It soon became clear that there is the critical barriers to achieve a common API:

• Tracing is a multi language problem. Our design decisions needs to being 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 is 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 and several 1:1s we made with some of the Go user s, our conclusion was that language ecosystems be suffering from the lack of a common data model and wire format rather th An the lack of a common tracing library.

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

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

• allow users to propagate traces among Go and non-go services regardless of the backend.
• allow users to is able to propagate traces within ecosystem libraries. Currently, trace contexts was dropped during medium/transport changes, e.g. when an HTTP request/response was wrapped by a Go API or a GRPC request is the followed by an HTTP request. Provide a minimal Go building block to represent a trace context and enable the ecosystem propagating traces using that BU Ilding block.
• allow users to is able to discover the current trace context from a context. Context.
• Start discussion about the 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.

Roadmap

Our roadmap are currently primarily blocked by the the the emerging Standards group because we are priority are to align well with The tracing community and adopting their solutions rather than inventing anything go-specific. Our next steps can summarized as:

• Work with the standards group to represent Go user ' s concerns. IF standards is not achieved or widely adopted, a backend-agnostic generic go-specific solution would be considered.
• Implement A trace package with the standard trace context representation and propagation primitives (e.g. propagating in C Ontext. 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 would give more details on the specifics of the work required for some items.

Trace context

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

Each tracing system have a trace context format and a spec how it should is 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 is often incompatible with all other; A context generated from a tracing backend cannot is parsed by another one. Compatibility issues restrict users to depend in a single backend end-to-end and use backend-specific instrumentation Libr Aries to utilize the trace context.

Until A standard establishes, the trace context can is only being represented by an identifier and a labels byte slice that both Can later is 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.typeinterface{    ID() []byte    Labels() []byte}

This overly generic representation of trace context was not very useful, especially for the library ecosystem that wants to Instrument code (e.g creating new child spans, attaching additional labels) without all dependencies to specific backend S.

At the "This", we propose to contribute to the establishment of the "Industry-wide" and draft our design Accor Ding to the standard rather than inventing a go-specific representation. The outcome of this work would be:

• A span Context encoding format standard This is the 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-to access trace context, we is enabling different libraries cooperate on the same trace.

packagecontextcontext.Contextcontext.Contextincontextorcontext.Context) Span

Standard library Support

If The proposed trace package gets into the standard library, with the first-class availability, we are 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'll open discussions and follow up with proposals once there are a trace package.

Caveats

• We cannot foresee when a open context trace standard would be mature and finalized. Before such is finalized, we be blocked on designing the trace context type.
• There is already several custom trace context types contributed by the community, e.g. opentracing ' s spancontext. Unifying the APIs around the new type would 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
Li>if The tracing community cannot achieve an open standard, our generic trace context type ([]byte, []byte] is not very u Seful.