fastrace

Fastrace

Fastrace is a tracing library 100x faster than others:

Features:

• Extremely fast
• Rich features for logging
• Compatible with OpenTelemetry

Resources

• Docs
• Examples
• FAQ
• Migrating from tracing

Getting Started

In Libraries

Libraries should include fastrace as a dependency without enabling any extra features.

[dependencies]
fastrace = "0.7"

Add a trace attribute to the function you want to trace. In this example, a SpanRecord will be collected every time the function is called, if the caller sets up a tracing context.

#[fastrace::trace]
pub fn send_request(req: HttpRequest) -> Result {
    // ...
}

Libraries can set up an individual tracing context, regardless of whether the caller has already set up a tracing context or not. This can be achieved by using Span::root() to start a new trace and Span::set_local_parent() to set up a local context for the current thread.

The func_path!() macro can detect the function's full name, which is used as the name of the root span.

use fastrace::prelude::*;

pub fn send_request(req: HttpRequest) -> Result {
    let root = Span::root(func_path!(), SpanContext::random());
    let _guard = root.set_local_parent();

    // ...
}

In Applications

Applications should include fastrace as a dependency with the enable feature set. To disable fastrace statically, remove the enable feature.

[dependencies]
fastrace = { version = "0.7", features = ["enable"] }

Applications should initialize a Reporter implementation early in the program's runtime. Span records generated before the reporter is initialized will be ignored. Before terminating, flush() should be called to ensure all collected span records are reported.

When the root span is dropped, all of its children spans and itself will be reported at once. Since then, it's recommended to create root spans for short tasks, such as handling a request, as shown in the example below. Otherwise, an endless trace will never be reported.

use fastrace::collector::Config;
use fastrace::collector::ConsoleReporter;
use fastrace::prelude::*;

fn main() {
    fastrace::set_reporter(ConsoleReporter, Config::default());

    loop {
        let root = Span::root("worker-loop", SpanContext::random());
        let _guard = root.set_local_parent();

        handle_request();
    }

    fastrace::flush();
}

Supported Rust Versions (MSRV 1.91.0)

Fastrace is built against the latest stable release. The minimum supported version is 1.91.0. The current Fastrace version is not guaranteed to build on Rust versions earlier than the minimum supported version.

Reporters

Fastrace supports multiple out-of-box reporters to export spans:

• fastrace-opentelemetry: Export spans to OpenTelemetry

Integrations

Fastrace provides integrations with popular libraries to handle context propagation automatically:

• fastrace-futures: Trace Stream from futures
• fastrace-axum: Trace axum HTTP services
• fastrace-poem: Trace poem HTTP services
• fastrace-reqwest: Trace reqwest HTTP requests
• fastrace-tonic: Trace tonic client and server requests
• fastrace-tower: Trace tower client and server requests
• fastrace-tracing: Compatibility layer for tracing

Projects using fastrace

Feel free to open a PR and add your projects here:

• Conductor: Open-source GraphQL Gateway
• Apache OpenDAL: A data access layer for various storage
• Databend: Cost-Effective alternative to Snowflake
• foyer: Hybrid in-memory and disk cache in Rust
• Sail: Unifying stream, batch, and AI workloads with Apache Spark compatibility

Migrating from tokio-tracing

If you're using the tokio-tracing ecosystem and want to switch to fastrace for better performance, you can use fastrace-tracing to make the transition easier.

The fastrace-tracing crate provides a compatibility layer that lets you capture spans from libraries instrumented with tokio-tracing in two lines of code:

let subscriber = tracing_subscriber::Registry::default().with(fastrace_tracing::FastraceCompatLayer::new());
tracing::subscriber::set_global_default(subscriber).unwrap();

For more details, refer to the fastrace-tracing documentation.

FAQ

Why is Fastrace so fast?

The maintainer of fastrace posts articles describing the details:

• The Design of A High-performance Tracing Library in Rust (Chinese)
• How We Trace a KV Database with Less than 5% Performance Impact

What is library-level tracing?

Library-level tracing refers to the capability of incorporating tracing capabilities directly within libraries, as opposed to restricting them to application-level or system-level tracing.

Tracing can introduce overhead to a program's execution. While this is generally acceptable at the application level, where the added overhead is often insignificant compared to the overall execution time, it can be more problematic at the library level. Here, functions may be invoked frequently or performance may be critical, and the overhead from tracing can become substantial. As a result, tracing libraries not designed with speed and efficiency in mind may not be suitable for library-level tracing.

In the realm of the Fastrace library, library-level tracing is engineered to be fast and lightweight, resulting in zero overhead when it's not activated. This makes fastrace an excellent choice for use in performance-sensitive applications, and it can be seamlessly integrated into libraries in a similar fashion to the log crate, something other tracing libraries may not offer.

How does Fastrace differ from other tracing libraries?

While many tracing libraries aim for extensive features, Fastrace prioritizes performance and simplicity.

For example, fastrace doesn't introduce new logging macros, e.g., info!() or error!(), but seamlessly integrates with the log crate. This allows you to use existing logging macros and dependencies, with logs automatically attached to the current tracing span.

Will fastrace incorporate 'level' for spans?

The concept of 'level' may not be an optimal feature for tracing systems. While tokio-tracing incorporates this feature, the underlying motivation for having levels in a span primarily revolves around performance. More specifically, it relates to the performance implications of tracing elements that are not of interest. However, tracing differs from logging in two key aspects:

1. Disregarding a low-level span might inadvertently discard a high-level child span.
2. The process of filtering, or 'level' as it's often called, in a tracing system should be applied to a trace as a whole rather than individual spans within a trace.

In this context, Fastrace offers a more efficient solution by filtering out entire traces that are not of interest through its unique tail-sampling design. Therefore, the concept of 'level', borrowed directly from logging systems, may not be suitable for Fastrace.

Benchmarks

By different architectures:

By creating a different number of spans:

Detailed results are available in benches/results.

License

This project is licensed under the Apache-2.0 license.

Originally, this project is a fork of minitrace. See this thread for more information:

• Running minitrace as a standalone project?