[exporter/dynatrace] Dynatrace support for Summary metric data type

[RangelReale]

Description: <Describe what has changed.> Dynatrace support for Summary metric data type.

I created this because I need to use the StatsD receiver, and it don't support Histogram for timing, only Summary.

This was based on reading the source code of other exporters, I don't have a deep knowledge of metrics, so this must be reviewed for correctness.

By my understanding, the received data is already a summary, so the only work would be converting to the OpenTelemetry format.

Link to tracking Issue: <Issue number if applicable>

Testing: <Describe what testing was performed and which tests were added.> Tested using the StatsD receiver sending to Dynatrace, it seems to report corrent timing.

Documentation: <Describe the documentation added.>

[linux-foundation-easycla[bot]]

The committers listed above are authorized under a signed CLA.

• :white_check_mark: login: RangelReale / name: Rangel Reale (36d41c4a1b741d2fbbec3756097219fae5d77398, d0b226f8406f4bfa84d25f2a48aab5093756f82b, 647967d47abf6d773ead6568d376db60fb478a81, ab1130594eb4a329b499c202a3ef32aeb43a6d40)

[dyladan]

@RangelReale I want to make sure you are aware that we're not ignoring this PR, but having internal discussions about how summaries should be handled. Whatever gets released is going to be supported for a very long time so we want to make sure that these conversions fit with what our metrics team is expecting and are consistent with other integrations.

[RangelReale]

@RangelReale I want to make sure you are aware that we're not ignoring this PR, but having internal discussions about how summaries should be handled. Whatever gets released is going to be supported for a very long time so we want to make sure that these conversions fit with what our metrics team is expecting and are consistent with other integrations.

Absolutelly no problem, I'm not an expert on metrics, I posted also to have feedback if the code is doing the right thing.

[github-actions[bot]]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[pirgeo]

Hi, we talked about this some more and found that the Summary representation in OTLP is not directly compatible with our data model, and will result in misleading values if ingested like this. This is mainly due to the fact that the OTLP Summary data type is "just" a compatibility thing (it's not possible to create Summary objects in the OTel SDKs, see https://github.com/open-telemetry/opentelemetry-specification issue # 2704). We are working on finding an alternative way of ingesting these data, but I am afraid we will not be able to accept this PR at this time. I will let you know as soon as I have more information.

[RangelReale]

Hi, we talked about this some more and found that the Summary representation in OTLP is not directly compatible with our data model, and will result in misleading values if ingested like this. This is mainly due to the fact that the OTLP Summary data type is "just" a compatibility thing (it's not possible to create Summary objects in the OTel SDKs, see https://github.com/open-telemetry/opentelemetry-specification issue # 2704). We are working on finding an alternative way of ingesting these data, but I am afraid we will not be able to accept this PR at this time. I will let you know as soon as I have more information.

Yes, I understand, that was the intent of this PR, to see if my assumptions were right.

There is another MR that is adding exponential histogram to Statsd, it may solve the same problem, but using the more otel compatible histogram type.