this is mostly for @Alex Crichton @Jakub Konka but didnt seem like the right discussion for a github issue - i'd like feedback on possibly changing the logging macros emitted by wiggle and used in wasi-common to use the tracing crate https://docs.rs/tracing/0.1.14/tracing/
we use tracing all over the place at fastly, which is my primary motivation, but in general i think tracing
has a couple of advantages over log
that make it worth using
the first is the concept of spans, which are natural to use in wiggle-generated functions where we want to log the arguments of a function, then later when an inner func returns we want to log the return values. the argument values and return value s are part of the same span, which means the backend can automatically correlate them, rather than have to associate them by searching on some common part of the text
the second is (stable) support for structured fields (in log this is noted as unstable and called kv support)
which also naturally matches to the names of arguments / return values we already have in witx, and keeps that structure around longer so that it can be e.g. encoded in json by the backend that sends it to some logging endpoint that understands json
also, trace hooks that are disabled (marked as uninteresting, essentially) by the backend are very low overhead - its one atomic load to determine whether a hook is disabled.
anyway, im going to prepare a patch to make tracing an additional opt-in logging facility, because we'd like to use that at fastly, but if it ends up being alright with all of you, we can drop the log
based one afterwards.
CC @fitzgen (he/him), who's also looked into tracing
Yeah, my plan was to integrate the tracing
crate throughout wasmtime and cranelift, so big +1 from me!
A little bit of an aside, but it would be super sweet if someone made a tracing subscriber that outputted chrome traces, so they could be viewed in the chrome:tracing UI or the firefox profiler
excellent, thank you fitzgen!
Last updated: Nov 22 2024 at 16:03 UTC