-
Notifications
You must be signed in to change notification settings - Fork 47
Description
We should document whether or not we support the valuable
crate. The tracing
crate has announced experimental support
Use case:
This allows users to record both user-defined types, and standard library collections such as Vec
and HashMap
, as structured data attached to tracing spans.
Case For
- We mimic the
tracing
crate - its familiar for tracing users. - It is convenient.
Case Against
- It's a special-purpose use case, e.g. debugging, we can likely better support more simply.
- We should discourage pushing complex user-defined types, and standard library collections to the tracing UI as a general practice - moving such volumes of data around the network will cripple your app performance - see 1.
- As we mimic
tracing
crate behavior we can expect to approachtracing
"like" performance. - It's yet another crate to build.
One Alternative
Better, in my mind, is to stick with a simple record!(span, "key", "value")
API.
For more complex use cases, the documents should encourage users to employ the standard format!()
. Specifically, for example: record!(span, "key", format!("{:#?}", udt))
. For more complex user defined types and data they have the ability to implement Display
and/or Debug
traits. The Debug
trait will likely already exist in most development stories. In performance monitoring stories there are strong incentives to keep-it-simple, and here the Display
trait can be repurposed to support that use case.
We should document whether or not "Object-safe value inspection, used to pass un-typed structured data across trait-object boundaries." is within the scope of Minitrace, or not.
I think not.
Thoughts?
In particular, my focus (head-space), is occupied by the #[trace]
attribute... there may be Minitrace implementation details that mean it is more performant to use the valuable
crate when recording and passing these data to Jaeger, datadog etc.