search

open-telemetry / oteps

OpenTelemetry Enhancement Proposals
https://opentelemetry.io
Apache License 2.0
340 stars 164 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 1 year ago

vikrambe commented 1 year 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 1 year 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 1 year 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 1 year 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 1 year 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.