-
Can someone explain to me why the There are a few shortcomings I see with the current API:
See https://docs.rs/tracing-subscriber/0.3.1/src/tracing_subscriber/fmt/fmt_layer.rs.html#561 for examples. I think maybe the reasoning for all this comes from the fact that the core tracing API only outputs a flat stream of span events, and has no notion of hierarchy and attached data at all? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
This is correct. Depending on the use-case, it may be desirable to not store span data in the program at all, and simply write that data out to a file or network IO immediately. Therefore, we chose not to make in-memory storage of any span data a core part of For example, I've seen Similar designs are possible in use-cases other than embedded systems, any time some external component is responsible for processing or viewing trace data. In Another motivation for decoupling these components is to allow span data storage to be modular, so that the So, yes, there is some additional overhead for implementing span data storage at a higher level than in Hope that answers your main question! Regarding this point:
I've considered the possibility of changing the |
Beta Was this translation helpful? Give feedback.
-
Yes, the first part is a very good explanation! And the Also, changing IMO, a way to compose/chain different low-level So from my point of view as maintainer of |
Beta Was this translation helpful? Give feedback.
This is correct. Depending on the use-case, it may be desirable to not store span data in the program at all, and simply write that data out to a file or network IO immediately. Therefore, we chose not to make in-memory storage of any span data a core part of
tracing
, and instead, made it opt-in when required.For example, I've seen
tracing
use…