Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use tracing crate for logging #315

Open
simonsan opened this issue Oct 5, 2024 · 0 comments · May be fixed by #316
Open

use tracing crate for logging #315

simonsan opened this issue Oct 5, 2024 · 0 comments · May be fixed by #316
Labels
A-dx Area: Related to Developer Experience A-errors Area: error handling needs improvement A-instrumentation Area: Related to tracing, instrumentation, metrics C-enhancement Category: New feature or request

Comments

@simonsan
Copy link
Contributor

simonsan commented Oct 5, 2024

I think it would be nice to use the tracing crate throughout rustic_core, as we could make use of it also regarding the #[instrument] macro. Giving us an easy opportunity to track calls into methods/functions as seen here: https://github.com/tokio-rs/tracing?tab=readme-ov-file#in-libraries

the #[tracing::instrument] attribute creates and enters a span
every time the instrumented function is called. The span is named after
the function or method. Parameters passed to the function are recorded as fields.

This will make debugging much easier for downstream users e.g. in rustic, and we will also get much more information and thus insight into (future?) asynchronous code.

The nice thing about the migration: it uses the same log facade, so we can just start annotating methods with tracing::instrument and otherwise replace log:: with tracing::.

Structured logging

  • we can log key-value pairs along with the message and easily use json output
// Using tracing
tracing::info!(tree_id = ea56df32, "TreeArchiver bla");

// Using log
log::info!("TreeArchiver bla tree id ea56df32");

Span-based Logging and Context Propagation

  • spans can represent a unit of work, spans can nest, any event or log that occurs within a span inherits its context (nice for asynchronous code)
let span = tracing::info_span!("handle_pack", tree_id = ea56df32);
let _enter = span.enter(); // Enters the span, attaching context
tracing::info!("Processing Pack");

Log Filtering

  • fine-grained control over what is logged, attachable metadata to events and spans, and configurable filters based on span context, levels, or specific fields
tracing::info!(target: "index_queries", latency_ms = 11, "Querying Index");
// Can be filtered dynamically to only include logs from "index_queries" above a certain latency threshold

Instrumentation

  • spans and events can be useful for performance monitoring and profiling tasks

Extensibility with Subscribers

  • Custom subscribers control how spans and events are recorded. Subscribers can filter, format, and export logs in a custom way. That can be useful for integrating with external systems.
@simonsan simonsan added A-errors Area: error handling needs improvement C-enhancement Category: New feature or request A-dx Area: Related to Developer Experience labels Oct 5, 2024
@simonsan simonsan added the A-instrumentation Area: Related to tracing, instrumentation, metrics label Oct 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-dx Area: Related to Developer Experience A-errors Area: error handling needs improvement A-instrumentation Area: Related to tracing, instrumentation, metrics C-enhancement Category: New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant