You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 approach tracing "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.
The text was updated successfully, but these errors were encountered:
taqtiqa-mark
changed the title
Doc: Valuable support or Feature: record("key", "value")
Feature: Valuable support or record("key", "value")
Apr 12, 2022
Better, in my mind, is to stick with a simple span.record("key", "value") API.
In fact we could make the public API even smaller with record!(span,"key", "value")
taqtiqa-mark
changed the title
Feature: Valuable support or record("key", "value")
Feature: Valuable support or record!(span,"key", "value")
Apr 27, 2022
We should document whether or not we support the
valuable
crate. Thetracing
crate has announced experimental supportUse case:
This allows users to record both user-defined types, and standard library collections such as
Vec
andHashMap
, as structured data attached to tracing spans.Case For
tracing
crate - its familiar for tracing users.Case Against
tracing
crate behavior we can expect to approachtracing
"like" performance.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 implementDisplay
and/orDebug
traits. TheDebug
trait will likely already exist in most development stories. In performance monitoring stories there are strong incentives to keep-it-simple, and here theDisplay
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 thevaluable
crate when recording and passing these data to Jaeger, datadog etc.The text was updated successfully, but these errors were encountered: