rustracing_jaeger
rustracing_jaeger copied to clipboard
sile
reporter: support for async futures-based report()
I'm still learning/experimenting with this crate, so sorry if this is already covered somehow and I missed it.
I'd like to integrate span-tracing and report-sending logic into an existing futures-based asynchronous application, however it looks like all existing reporters here only have a synchronous/blocking report() method. Would you consider expanding this library to be easily pluggable into futures-based chains? Also having a simple example on how to to plug together tracing, asynchronous tasks and jaeger reporting would help.
Last but not least, thanks for writing this library!
It seems interesting to support futures. But currently, rustracing_jaeger (and rustracing) heavily depends on std::sync::mpsc, so it is difficalt to integrated with futures smoothly.
If your are not annoying to spawn a thread dedicated for the reporting, it will be easiest way to use the thread as follows:
let (tracer, span_rx) = Tracer::new(rustracing::sampler::AllSampler);
// Spawns a reporting thread at the initialization phase in your application
std::thread::spawn(move || {
let mut reporter = track_try_unwrap!(JaegerCompactReporter::new("example"));
while let Ok(span) = span_rx.recv() {
if reporter.report(&[span][..]).is_err() {
break;
}
}
});
// The operations of `tracer` are not blocked, so it can be used in asynchronous code.
@sile Any update on this? Rust has had async/await for a while now and you could use Tokio's mpsc instead of std's.
@andrewbanchich
I think that it's somewhat dangerous to depend on tokio heavily because some users (including me) may want to use this crate outside of the asynchronous world (e.g., with the regular thread model). Besides, indeed, tokio seems a defact standard async runtime, but there are some alternatives (e.g., async-std) that provide its own channel implementation. Some user may want to use rustracing with one of the alternatives.
Instead of switching the channel implementation to tokio based one, IMO, it seems good to extend Tracer and SpanReceiver to allow arbitrary channel type as a type parameter (I have no plan to implement this feature in the near future though...).
By the way, just FYI, this crate now uses crossbeam as the channel implementation (see https://github.com/sile/rustracing/pull/4).
Instead of switching the channel implementation to tokio based one, IMO, it seems good to extend Tracer and SpanReceiver to allow arbitrary channel type as a type parameter
I tried implementing this idea in https://github.com/sile/rustracing/pull/9. If you think this PR is good, I'll merge it. > @andrewbanchich
That makes sense to me.
I've actually just switched to using the official opentelemetry crate alongside tracing and tracing-opentelemetry.
Thank you though!