Consider changing help text for span/logs batch exporter metric "queueSize"

[evantorrie]

Is your feature request related to a problem? Please describe.

Currently, sending logs and spans over OTLP from a Java application using the BatchSpanProcessor and BatchLogRecordProcessor causes problems for the OpenTelemetry collector when configured with a Prometheus exporter.

While this seems like a limitation of the Prometheus exposition format, even after including the InstrumentationScope name/version as attributes on each of these queueSize metrics, most Prometheus exporters (certainly the Golang one does) will complain that it has two metrics with the same name but different "help" text.

In the Java SDK case, the log record batch processor creates a queueSize metric with description "The number of logs queued" while the span batch processor creates a queueSize metric with description "The number of spans queued".

Describe the solution you'd like

Consider changing the description, aka "help" text, for each to be "The number of items queued". Since each one has a different InstrumentationScope as well as a different attribute (spanProcessorType vs. logRecordProcessorType), these will still be distinguishable in the backend.

Describe alternatives you've considered

Use transformprocessor to "delete" the metric "description" field from metrics destined for Prometheus exporter (seems drastic).

Additional context

OpenTelemetry Specification PR for InstrumentationScope labels: open-telemetry/opentelemetry-specification#2703

[jack-berg]

Consider changing the description, aka "help" text, for each to be "The number of items queued".

This seems reasonable. However, like opentelemetry-specification#2703 aims to solve instrument name collisions across different scopes, I think we will ultimately need a solution at the spec level.

[puckpuck]

We are running into this issue with the OpenTelemetry Demo project. The adservice in that project, a Java-based app, has the auto-instrumentation agent enabled to send all data to an OpenTelemetry collector. The queueSize metric reports an error unless we filter it out or set its description to blank.

Ideally, we shouldn't have to do this, and the SDK would work without any special configuration required within the Collector itself.

This could also be an opportunity to converge that metric to standard attribute names and descriptions across all telemetry types. Based on the telemetry type, it currently emits logReportProcessorType and spanProcessorType attributes. Making the description and attribute names similar across telemetry types would help with developer and operator experience.

[taisph]

Not sure if I am seeing a regression here. The otel-collectors are complaining about metrics and logs received from Java services using the java-agent. None of the non-java services cause this error.

error gathering metrics: 3 error(s) occurred:
* collected metric queueSize_ratio label:{name:"job" value:"fop"} label:{name:"processorType" value:"BatchSpanProcessor"} gauge:{value:0} timestamp_ms:1707900663054 has help "The number of items queued" but should have "The number of spans queued"
* collected metric queueSize_ratio label:{name:"job" value:"fop"} label:{name:"processorType" value:"BatchLogRecordProcessor"} gauge:{value:0} timestamp_ms:1707900663054 has help "The number of items queued" but should have "The number of spans queued"
* collected metric queueSize_ratio label:{name:"job" value:"dwh"} label:{name:"processorType" value:"BatchSpanProcessor"} gauge:{value:3} timestamp_ms:1707900631814 has help "The number of items queued" but should have "The number of spans queued"

Agent: v1.32.1 and v2.0.0
Collector: v0.93.0

I'll create a new issue if needed.