Define messaging metrics and add error.type attribute to spans

[lmolkova]

Fixes open-telemetry/opentelemetry-specification#1014

[pyohannes]

Thanks for putting a stake in the ground here, this is a great start.

[cyrille-leclerc]

I love the duration metrics.
FYI Related to this, I'm brainstorming with @jpkrohling and others on the idea to adopt OTel Semantic Conventions metrics in the OTel Collector Service Graph Connector and we are looking at standard metrics for client/producer and server/consumer durations.

Did we consider stronger consistency with existing http.server.duration, http.client.duration, rpc.{client, server}.duration that are aligned with the SpanKind={server, client, producer, consumer, internal} and look at messaging metrics like:

• Preferring name messaging.producer.duration over messaging.publish.duration for the definition "Measures the duration of publish operation."
• Introducing messaging.consumer.duration with the definition "Measures the duration to consume messages."
  • This would be consistent with http.server.duration: Measures the duration of inbound HTTP requests.

[pyohannes]

• Preferring name messaging.producer.duration over messaging.publish.duration for the definition "Measures the duration of publish operation."
• Introducing messaging.consumer.duration with the definition "Measures the duration to consume messages."
  • This would be consistent with http.server.duration: Measures the duration of inbound HTTP requests.

On the messaging side, the current metric names relate to the messaging specific operation names. For the consumer side I definitely see value in having separate consumer metrics pull-based (receive) and push-based (deliver) scenarios. The duration of pull and push durations aren't semantically consistent, as the push duration usually also involves the duration of processing the message, whereas the pull duration doesn't. We shouldn't mix both in one single metric.

[pyohannes]

For spans, messaging systems add system-specific attributes to the spans.

Do we want to treat messaging system specific metric dimensions the same way, so that messaging systems extend existing metrics? Or do we require them to send different system-specific metrics?

The first approach makes cardinality hard to control (imagining a single service using two different messaging systems), the second one will likely duplicate information.

[lmolkova]

Do we want to treat messaging system specific metric dimensions the same way, so that messaging systems extend existing metrics? Or do we require them to send different system-specific metrics?

I think there a couple of options here:

1. Allow to extend generic metrics.

   • I've created update circleci to use go 1.14 opentelemetry-specification#553 to follow up and will prototype how it looks like for one of the Azure SDKs.
   • The only downside of this approach is that applications that see metrics from multiple messaging systems will need to have slightly different dashboards/alerts/queries for them.

2. Make every system come up with their own set of additional metrics that would sometimes overlap with the generic ones.

   • We should probably change this PR to just describe how to create custom messaging metrics semconv and not attempt to define generic metrics
   • The downside is that every system would need to define something custom (even if it's just a metric name)

I suggest to start with Option 1 - as messaging semconv progresses towards stability, we should get more feedback from messaging systems and instrumentation prototypes and can change the approach.

[pyohannes]

There are still some details to clarify, but this provides a great starting point.

[joaopgrassi]

Overall looks like a good start! Left some non blocking comments.

[lmolkova]

@open-telemetry/specs-semconv-approvers this PR is approved by the messaging WG members, please take a look