glommio
glommio copied to clipboard
DataDog
provide a specialized logging macro set
Rust has the very helpful macros from log : info!, warn!, etc.
It would be helpful to have our own, that would include the executor name or ID on it. That's because often times executors are all performing the same tasks, only in different parts of the dataset. It is helpful to know where exactly the issues are coming from.
The challenge in this issue is not to implement the macros, but to do it in an ergonomic way that existing applications can adapt without too much trouble.
Hi @glommer . Are you aware about tracing crate https://lib.rs/crates/tracing . Probably would be good to use it and provided concepts alongside with macro wrappers with useful information about executors and so on. IMHO unlikely plain logging will be too much handy taking into account nature of async apps.
I would be curious to take this issue and issue #179. But before I need to be more acknowledged with code and probably will provide more PRs during the investigations. Also, I am very curious about your opinion of using a tracing crate. IMHO structural approach which they use is useful for glommio too.
Although obviously familiar with tracing systems in general, I was not familiar with the tracing crate. I would have to spend more time on it. In particular from an admittedly very shallow first reading on their website their examples focus too much on how to generate the traces, but I would like to have a better idea of the output too and also the cost of generating and keeping the traces until we are done with them.
Traces are definitely useful at some point in the application (like request paths), but usually not so much for events.
But I wouldn't mind seeing a proof of concept of an event system based on tracing if you think it can fit the requirements
In particular from an admittedly very shallow first reading on their website their examples focus too much on how to generate the traces, but I would like to have a better idea of the output too and also the cost of generating and keeping the traces until we are done with them.
FWIW, tracing has pluggable backends, and is intended to be a fairly lightweight facade to promote interop and support diverse applications. How data is recorded and emitted is up to you, though a number of options like the fmt subscriber are available off the shelf.
I would really love a solution for this.. I think it's valuable to have some instrumentation we can tap into akin to the logging/tracing facades. So how can we move this forward? Is it worth trying tracing, or starting from scratch..? Should we look into using ebpf to trace/log/metrics? Not 100% sure what that would end up looking like.. To be fair to the tracing library, there are nonblocking subscribers I've used to ensure it isn't too costly in the fast paths (haven't measured impact, though). Or do we just build something similar to tracing, the way we'd want it built? Or is logging/tracing just too costly for a system like this?
The main blocker for this has been lack of time on my end, as I am focusing on other issues right now. If someone wants to move it forward, that'd be great.
The solution proposed, of using the tracing crate with a default simple facade seems like a good starting point to me
Yeah cause I'm willing to do the leg work, but I did want some input on what we end up using/creating.. To clarify that I'm intending on working on this, just wanna gain consensus on method. Cause there's pretty divergent paths we could go down. I'll look a little deeper into the tracing library and see if anyone else has strong feelings about it.