In complex systems, such as distributed software and cloud infrastructures, understanding how the system is behaving can be a challenge. Observability allows us to understand a system from the outside, allowing us to ask questions about that system without knowing its inner workings. Furthermore, it allows us to easily solve and deal with new problems (ie. “unknown unknowns”) and helps us answer the question: “Why is this happening?” A lack of observability means there are certain states or behaviors that cannot be discerned or predicted just by looking at its outputs.

Even though the benefits of having Observability are apparent, many organizations do not prioritize its implementation. The issue lies in outdated assumptions about how systems function. Your application is no longer a single entity residing within your control but a vast, ever-changing ecosystem of services, often dependent on elements you don’t own. Failures are always present at all stages of the project and it is impossible to predict all possible failures that may occur.

Observability is based on three fundamental elements: logs, metrics and tracing, known as the three pillars of Observability.

One amazing crate who provides APIs necessary for instrumenting libraries and applications to emit trace data is tracing. Developed by the Tokio team, it’s fully built up from the ground for async which is perfect for web applications with Rust logs. It uses the concept of “spans” which are used to record the flow of execution through a program.

You can use tracing to ¹:

• Emit distributed traces to an Open Telemetry collector.
• Debug your application with Tokio Console.
• Log to stdout, log file or journalId.
• profile where your application is spending time.

You can get started installing the crate into your project.

cargo add tracing

If your program copiles to a binary (not a library), you need to install a logging subscriber.

cargo add tracing-subscriber

And now we need to implement it in our project

use tracing;
use tracing_subscriber;

fn main() {
    tracing::subscriber::set_global_default(
        tracing_subscriber::FmtSubscriber::new()
    ).expect("setting default subscriber failed");

    let result = compute(5);
    tracing::info!("The result is {}", result);
}

#[tracing::instrument(ret)]
fn compute(n: i32) -> i32 {
    if n > 10 {
        tracing::warn!("The number is greater than 10");
    } else if n < 1 {
        tracing::error!("The number is less than 1");
    }
    n * 2
}

In the above code, we first set a default subscriber for the tracing events. Then, we use the info! macro to record an event at the info level. In the compute function, we use the trace!, warn!, and error! macros to record events at different levels based on the value of n. We also use instrument macro to record the return and the params of the compute function, it can be used to record errors or other fields in Span increasing even more observability.

This simple example show the power of tracing crate and how we can use it to improve observability in Rust repositories, in more complex systems we can add tracing-futures and tracing-serde to improve serializing and provides instrumenting for Futures, but I will cover this topics in another post.

Thanks for reading!