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
{{ message }}
This repository has been archived by the owner on Apr 23, 2021. It is now read-only.
lurker here: while I've not needed nano's very often to find what's accumulated slowest/problem path, I'd like to encourage you to keep/allow it as a precision instrument, as it enables re-use of the underlying data structures in some interesting ways beyond the strict trace-collection things.
Thanks for chiming in! Right that makes sense... 👍
While usually nanosecond precision is more the domain of profiling, there's no reason for us to arbitrarily disallow nanos, maybe someone can make use of the same infra in some useful way to measure something quickly 👍
While it's debatable if nanoseconds make sense in distributed traces... (a few nanos here or there are not likely going to lead you down to "aha this is the slow request!" etc), but yeah the topic comes up from time to time and the current otel spec suggests allowing nanos: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/api.md#set-status
Related discussion in zipkin-js openzipkin/zipkin-js#187
The text was updated successfully, but these errors were encountered: