Sadly anything that EX itself logs, since it's not using any OpenTelemetry compatible logging library, will be missing from the Jaeger view.
It would be neat if we could have EX create, not only the root span from #1447, but also have the same capability of creating spans for basically anything the client does.
For this to work we would need to expose over the FFI some of the methods from the tracing crate.
Rageshakes 2.0
One thing that would really nice to have is to have the rageshake functionality upload to Jaeger directly, on a on demand basis, just like our current rageshakes require user interaction.
I think it would make sense to build a tracing-subscriber Layer or Filter that sits between our traces and the OpenTelemetry exporter. The layer would cache the traces and only forward traces to the exporter when users explicitly demand them to be forwarded.
Since #1447 we create a root span for our
Client
object, and since https://github.com/matrix-org/matrix-rust-sdk/pull/1428 EX can push traces to an OpenTelemetry collector, aka Jaeger in this case.Structured logging for EX
Sadly anything that EX itself logs, since it's not using any OpenTelemetry compatible logging library, will be missing from the Jaeger view.
It would be neat if we could have EX create, not only the root span from #1447, but also have the same capability of creating spans for basically anything the client does.
For this to work we would need to expose over the FFI some of the methods from the
tracing
crate.Rageshakes 2.0
One thing that would really nice to have is to have the rageshake functionality upload to Jaeger directly, on a on demand basis, just like our current rageshakes require user interaction.
I think it would make sense to build a tracing-subscriber
Layer
orFilter
that sits between our traces and the OpenTelemetry exporter. The layer would cache the traces and only forward traces to the exporter when users explicitly demand them to be forwarded.Something like this: