#diesel #logging #tracing #opentelemetry


Connection telemetry middleware for diesel and tracing

8 releases

0.2.0 Jun 22, 2023
0.1.6 Jun 13, 2022
0.1.5 Jun 18, 2021
0.1.4 Mar 16, 2021
0.1.3 Aug 17, 2020

#423 in Database interfaces

Download history 21/week @ 2023-06-09 75/week @ 2023-06-16 68/week @ 2023-06-23 52/week @ 2023-06-30 41/week @ 2023-07-07 20/week @ 2023-07-14 50/week @ 2023-07-21 33/week @ 2023-07-28 30/week @ 2023-08-04 39/week @ 2023-08-11 28/week @ 2023-08-18 40/week @ 2023-08-25 35/week @ 2023-09-01 51/week @ 2023-09-08 24/week @ 2023-09-15 13/week @ 2023-09-22

135 downloads per month

MIT license

468 lines



diesel-tracing provides connection structures that can be used as drop in replacements for diesel connections with extra tracing and logging.

Usage should be straightforward if you are already using dynamic trait objects or impl trait for your connections. For example a function such as:

fn use_connection(
    conn: &impl diesel::Connection<Backend = diesel::pg::Pg>,
) -> () {}

Will accept both diesel::PgConnection and the InstrumentedPgConnection provided by this crate and this works similarly for other implementations of Connection if you change the parametized Backend marker in the function signature.

Unfortunately there are some methods specific to backends which are not encapsulated by the diesel::Connection trait, so in those places it is likely that you will just need to replace your connection type with the Instrumented version.


Just like diesel this crate relies on some feature flags to specify which database driver to support. Just as in diesel configure this in your Cargo.toml

diesel-tracing = { version = "<version>", features = ["<postgres|mysql|sqlite>"] }



Currently the few fields that are recorded are a subset of the OpenTelemetry semantic conventions for databases. This was chosen for compatibility with the tracing-opentelemetry crate, but if it makes sense for other standards to be available this could be set by feature flag later.

It would be quite useful to be able to parse connection strings to be able to provide more information, but this may be difficult if it requires use of diesel feature flags by default to access the underlying C bindings.


All logged traces are currently set to DEBUG level, potentially this could be changed to a different default or set to be configured by feature flags. At them moment this crate is quite new and it's unclear what a sensible default would be.


Errors in Result objects returned by methods on the connection should be automatically logged through the err directive in the instrument macro.

Sensitive Information

As statements may contain sensitive information they are currently not recorded explicitly, pending finding a way to filter things intelligently.

Similarly connection strings are not recorded in spans as they may contain passwords


  • Record and log connection information (filtering out sensitive fields)
  • Provide a way of filtering statements, maybe based on regex?

License: MIT


~121K SLoC