Where is structured logging appropriate (with `tracing`)

[DanGould]

re:

I noticed that we initialize a tracing subscriber in a every test but don't really seem to be using tracing much, instead using log::debug in most places. Is there a reason to keep using tracing in tests or should we just remove that dependency too and use log instead?

— @spacebear21

We can easily convert log::x to tracing::x to take advantage of tracing's additional context. There's also the tracing-log crate to have dependency log::x handled as tracing::x calls.

I feel like tracing calls would be especially useful for payment processors depending on payjoin, like bria, since they depend heavily on structured logging, but I have to admit I'm green to the ins-and-outs of a well maintained system of structured logging.

I thought we should take advantage of tracing's structured logs in payjoin-directory, ohttp-relay, and payjoin-cli to provide structured logging for downstream users. It gives way more context across closure boundaries and with async, and the logs can be filtered dynamically. I figured this would be good for debugging and uptime monitoring in particular, but I do wonder if it's at odds with our goals for privacy. We're certainly not taking advantage of it yet. tracing lets us provide the kind of polish I'd like our actual kit to have post-1.0. If we figure out how to do that I reckon it makes sense to do in tests too.

Is it overly complex in tests? We're definitely not using it to leverage what we print in CI vs local. hard to say. @0xBEEFCAF3 @nothingmuch any comment on where we should be using structured logs

Originally posted by @DanGould in https://github.com/payjoin/rust-payjoin/issues/507#issuecomment-2614027138

[nothingmuch]

I'm personally very much in favor of tracing-maxxing, not just for downstream users but al

unpopular opinion: i don't think structured logging is complex at all, rather it's simpler than traditional logging when you consider things more broadly (code and operational complexity) and especially the cognitive load of writing useful log events. coming up with good log messages (contrasted with ad-hoc print debugging), auditing them for leaks of sensitive data, making sure they are easily filterable and searchable, and don't lose too much information (especially of data structures that can be helpful if debugging but are rarely relevant for humans trying to follow at a high level), that they aren't drowned in detail... all of that is more effort IMO and IME.

OTOH, structured logs can just be captured and formatted/analyzed later if it's worth it. all the data is there, making it pretty can be deferred until its justified and with the benefit of hindsight. for example, github CI captured terminal outputs are pretty painful to read, especially with umatrix since they randomly change the hostname of whatever azure instance the data comes all the time so whitelisting 3rd party XHR... serializing structured logs and exporting them as CI job artifacts (like coverage data) is nice and future proof, and with opentracing compatible log events there's good tooling available to view and search such logs should we ever need it

[spacebear21]

Closed by #1020

[nothingmuch]

I don't think this can be considered closed yet, we have plenty of log events that currently just format strings but which could use structured logging instead