straiforos.tngl.sh straiforos.tngl.sh Hiya!
I received some good feedback that my PR #324 is too specific to emailing. I started with email.rs and did not expand it beyond my needs at the time I added it and leveraged it to debug an issue I had. What would be the right approach? Ensuring tracing across all comms? All HTTP requests?
I think the crate itself tranquil-otel was the right move, I'd like feedback on how this could be useful for all operators and improve logging in-general.
Thanks,
~ Triforce
Awesome thank you.
In my past lives, tracing has been blanketed via correlation ids, and where you want spans is where you tag it allowing groupings across all requests. This works really well when there is a "saga" in micro-service orchestration terms which I suspect a PDS would be subject too, or at least within my applications use-cases it could be helpful. To the point of comms I think a single span for notify would probably do, allowing a trace/coorlation id would be helpful for persisting a lexicon record and something go bump, or probably more realistically a CAR Export. I added a span for notifying a PDS user they had a lapsed subscription, in hindsight it was misguided and not the right tool for the job, yet the span made it possible for me to see that sending a notification to a bsky user failed in the noise of the logs.
I think just all comms would be good, hopefully just injected in such a way that is generic and also supports more future comms methods but doesn't go so far as all http requests, but I'm willing to hear out why we should do for all http. I think that all http is the job of an actual second telemetry tool dedicated for that instead of tracking just comms, though, they could both be subsets of the same whole. not sure!