[Survey] Developer Experience

[tsloughter]

Hi (@open-telemetry/java-approvers)

The DevEx SIG (https://github.com/open-telemetry/sig-developer-experience\) is running a survey with other SIGs, to collect feedback from the approvers and maintainers of each programming language. We are initially focusing on the topics below, so we'd love to have your insights on it.

After we collect everyone's opinion, I'll sum this up in the DevEx repo and link you to it.

Collecting this info would help us find spots to improve throughout the whole OTel project.

Feel free to link issues/discussions/docs and so on.

Survey:

1. Differences from upstream spec:

• discrepancies - why?
• extra convenience

2. Most requested features

• API
• SDK
• Instrumentations/semantic conventions

3. Things to consider from other telemetry projects (things like micrometer)

[jack-berg]

Discrepancies from upstream:

• Default OTLP protocol is grpc. Reason: historical artifact from when grpc was preferred over http/protobuf.
• No support for OTLP http/json. Reason: increases support burden without a strong use case.
• No support for OTLP throttling. Reason: no user demand.
• No support for OTLP partial responses. Reason: implementation is complicated, limited user demand.
• Experimental support for providing generic attribute processing capabilities via views. I.e. enrich measurement with attributes from context or baggage. Reason: historical artifact from early metrics prototype.
• No support for tracer, meter, logger attributes. Reason: no strong use case / user demand.
• No support for configuring exemplar reservoir in view. Reason: havne't gotten around to it, no user demand.
• No support for metric filters in metric readers. Reason: nobody to drive implementation, limited user demand.
• Log attributes can only be standard attribute value types - no support for any value. (Note, log bodies support any value) Reason: limited user demand, implementation pollutes API ergonomics.
• No support for opencensus binary propagator. Reason: nobody to drive implementation, limited user demand.

Extra convenience:

• We have something called the instrumentation-api in opentelemetry-java-instrumentation. This API is an abstract over the trace, metrics API which makes it easier to write instrumentation which conforms to semantic conventions. The idea is you implement a series of interfaces which require you to provide attributes required by conventions, and the internals take care of recording the data in the format required by the conventions.
• Kotlin extension for making it easier to propagate OpenTelemetry context into kotlin coroutines.
• PassThroughPropagator a propagator which extract and injects a configurable set of context fields.
• Autoconfigure a dedicated module for interpretting the env var configuration interface and returning configured SDK components, complete with a rich set of programmatic customization capabilities for when the env vars are insufficient.
• OTLP proxy support. Not mentioned in the spec, but a natural addition with high user demand.

Most requested features:

• Ability to turn off sampling for low value spans like health check calls. This was the single most requested feature, which we recently closed because there's a solution involving contrib components and declarative config, but there really should be a built-in sampler to achieve this.

That's all the time I have for the moment. I'll come back and update these lists as things come to mind / time permits.