OpenTelemetry fully supports the AWS Tracing header
Note the failure to detect any resource information MUST NOT be considered an error, whereas an error that occurs during an attempt to detect resource information SHOULD be considered an error.
/metadataendpoint or whatever, what should happen?
I was doing a final comb of the tracing spec to prepare for the release of the JS API and I noticed current trace API spec states:
The API MUST implement methods to create a SpanContext. These methods SHOULD be the only way to create a SpanContext. This functionality MUST be fully implemented in the API, and SHOULD NOT be overridable.
In JS the SpanContext is just an interface that any plain object can meet and there currently exists no API to create a span context. What is the intention behind requiring the API to be the only way to create a SpanContext
Hey, I just started looking at implementing traces and metrics in the same application, and I noticed that
http.target recommendations for traces (https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/semantic_conventions/http.md#http-server-semantic-conventions) and metrics (https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/metrics/semantic_conventions/http-metrics.md#parameterized-labels) seem incompatible.
In particular, metrics recommends converting
http.target to a parameterized version, while tracing seems to suggest the non-parameterized version. Is it expected to use different values for the same label for traces and metrics?
Hey Specification folks! I'm implementing some throughput benchmarks for the Java API/SDK and had a question on https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/performance-benchmark.md#create-spans
I'm assuming we're meant to have attribute strings of size 20 bytes vs. 20 characters (i.e. should I be using long-unicode here at all?) Want to make sure our throughput metrics are consistent.