Reality-check if exporter health metrics should be merged across signals

[JonasKunz]

This is issue is about whether the exporter health metrics should be merged across signals.
E.g. currently the exporter metrics are separated per signal:

• otel.otel.sdk.exporter.log.exported.count
• otel.otel.sdk.exporter.span.exported.count

The metric definitions are pretty much copy-paste, with only adjustments to the unit. The question is whether it makes more sense to combine them into a single metric (e.g. otel.otel.sdk.exporter.exported.count), differentiating the signal types using an attribute (otel.signal=span/log/metric).

Per discussion in the SIG Meeting on 17.03.2025 we decided to not merge them for now, even though their definitions are very similar. Some concerns where:

• Confusion when building dashboards: Other health metrics would not have the otel.signal attribute, making it a bit more difficult/ error prone to build dashboards.
• Non-intuitive metric units: One would need to check the exact metric defintion to understand that the unit is actually dependent on the otel.singal type
• Risk of diverging: Exporters have dedicated specifications per signal. If those diverge, we would run into the risk of not being able to represent the different behaviours in the exporter metrics.

The decision therfore was to keep them separated for now. After the metrics have been implemented and used in the wild, we will revisit this decision if there are too many drawbacks discovered. We can then adjust, as the metrics are experimental.

[trask]

I like that otel.sdk.exporter.operation.duration is unified across signals (#2007).

Keeping the others separate makes sense to me, especially due to the difference in units and the differences between span/log pipelines (which are similar) and metric pipelines (which are fairly different and so may be hard to unify across all three).

[joaopgrassi]

Should we close this as it's nothing is changing or we prefer to leave it open? Was there any new insights since this was opened?

[JonasKunz]

I don't think the implementation of these metrics has come far enough to really make a decision, however so far I personally am still happy with the design. Imo we could close this and reopen if needed.

[joaopgrassi]

Alright I will keep it open in the backlog then.