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.
The @opentelemetry Metrics Workshop happens tomorrow at 9:30 PST at https://zoom.us/j/8203130519
9:30 - 9:45am PST: Opening remarks, organization of the day, how we got here, and the many streams of work. We have an API, language SDKs, a Protocol, a Collector, Receivers, Exporters, Semantic Conventions, and a connection to Tracing [organizer: OTel Committee]
9:45-10:15am PST: Community building: @opentelemetry has first-class @OpenMetricsIO support, and @PrometheusIO users are first-class users. These projects are meant to get along, and committed to it. [organizer: Alolita Sharma]
10:15 - 11:00am PST: @opentelemetry Collector deployment models (e.g., Daemonset vs. Statefulset), Agents, Sidecars, and first-class support for Prometheus Remote-Write [organizer: Jaana Dogan]
11:30 - 12:15pm The Metrics API and Data Model, how we integrated the @opencensusio feature set (Tracing and Metrics, combined!) with the @OpenMetricsIO and StatsD data models. Presenting the six @opentelemetry metric instruments [organizer: Bogdan Drutu]
12:15 - 13:00pm Histograms! How we’ll support high-resolution and variable-boundary histograms and the connection to sampling metric events [organizers: Josh MacDonald, Michael Gerstenhaber]
13:30 - 15:00pm Questions and answers
OTEL_PROPAGATORSneeds to be