palantir / rust-zipkin

A library for logging and propagating Zipkin trace information in Rust

rust-zipkin

A collection of crates to support the Zipkin distributed tracing system.

zipkin-types

Documentation

The zipkin-types crate defines Rust types corresponding to Zipkin's object schema.

zipkin

Documentation

The zipkin crate defines a Tracer object which handles the heavy lifting of creating and recording Zipkin spans.

http-zipkin

Documentation

The http-zipkin crate provides functions to serialize and deserialize zipkin TraceContext and SamplingFlags values into and out of http HeaderMap collections to propagate traces across HTTP requests.

License

This repository is made available under the Apache 2.0 License.

rust-zipkin's Issues

Support inference of the local IP address for Endpoint

This is a kind of sketchy operation, but it's not all that common to know what your IP is via other means. We basically enumerate all local addresses and look for the first one that "looks right". This can be done with getifaddrs(3) on Unix and GetAdaptersAddresses on Windows.

Brave's logic for reference: https://github.com/openzipkin/brave/blob/c83d32531170de2d9e848026e43d5e2020922ee0/brave/src/main/java/brave/internal/Platform.java#L56

Add a Futures-compatible version of Tracer

We'd be using task locals rather than thread locals.

Upgrade to Zipkin V2

provide examples

I'm reading the structure of this crate to understand the pieces but I feel like I'm missing parts. It may be helpful to provide some cargo /examples application to demonstrate how these pieces fit together

Support propagation of partial contexts

There are three sets of trace information that can be communicated to a server: a full TraceContext, debug/sample flags, or a TraceId and debug/sample. We currently only support the first case, but we should handle all three.

Brave has a TraceContextOrSamplingFlags which is just an enum over those three cases. We should have something similar.

Async functions tagged with #[zipkin::spanned] aren't Send

We need to split the creation of the detached OpenSpan into a separate statement or the attached (and non Send) OpenSpan is considered to be alive across the await and prevents the future from being Send.

implement "b3 single" header format

As discussed on openzipkin/b3-propagation#21 and first implemented here: https://github.com/openzipkin/brave/blob/master/brave/src/main/java/brave/propagation/B3SingleFormat.java https://github.com/openzipkin/brave/blob/master/brave/src/test/java/brave/propagation/B3SingleFormatTest.java

Let's support at least reading "b3" header from a single string, most commonly traceid-spanid-1
It would also be nice to support optionally writing this, especially in message providers or others with constrained environments.

Brave currently has a property like this, but its name could change with feedback:

    /**
     * When true, only writes a single {@link B3SingleFormat b3 header} for outbound propagation.
     *
     * <p>Use this to reduce overhead. Note: normal {@link Tracing#propagation()} is used to parse
     * incoming headers. The implementation must be able to read "b3" headers.
     */
    public Builder b3SingleFormat(boolean b3SingleFormat) {
      this.b3SingleFormat = b3SingleFormat;
      return this;
}