Proposal: TraceID just being hex value doesnt help with decision making at tracing backend. Is there a possibility to encode additional metadata such as timestamp, region etc.

open-telemetry / oteps

OpenTelemetry Enhancement Proposals

https://opentelemetry.io

Apache License 2.0

326 stars 157 forks source link

Proposal: TraceID just being hex value doesnt help with decision making at tracing backend. Is there a possibility to encode additional metadata such as timestamp, region etc. #236

Closed vikrambe closed 8 months ago

vikrambe commented 10 months ago

TraceID just being hex value doesnt help with decision making at tracing backend. Adding more info to TraceID would help decision making at the backend. Encoding traceId with timestamp, region code, service name etc...

dmathieu commented 10 months ago

TraceID is a public value, since it's passed in HTTP headers. So passing identifiable data into it (such as region, service name) can be a security/privacy issue.

tedsuo commented 9 months ago

@vikrambe what you are describing are Resources, which are sent out of band and are used to describe all telemetry emitted by each service.

dyladan commented 9 months ago

In this project and the W3C we've actually been moving in the opposite direction where we try to encourage more randomness. See the new random flag in the w3c spec as an example.

tedsuo commented 8 months ago

@vikrambe closing this issue as the trace-id is defined as random in the W3C spec.

https://www.w3.org/TR/trace-context/#randomness-of-trace-id

Most of the information you mentioned is already reported out-of-band. If you really need a particular piece of information in-band, have a look at the baggage feature for sending it along. However, be advised that it is unusual to need this for observability purposes.