Metric names are changed in CloudWatch

[danieljamesscott]

I've noticed that commit https://github.com/micrometer-metrics/micrometer/commit/b7bbea3d6935aaf794d538cf5f6da5155c9bb93f caused a change to the metric names published to CloudWatch. e.g. 1.0.5 sends

MetricName: jvm.memory.used,Dimensions: [{Name: area,Value: heap}, {Name: statistic,Value: value}]

But 1.1.3 sends

MetricName: jvm.memory.used.value,Dimensions: [{Name: area,Value: heap}]

Was this a deliberate change? And are the names supposed to remain consistent going forwards?

I saw this issue related to promethius:

https://github.com/micrometer-metrics/micrometer/issues/1063

But I don't see any other issues related to this.

[izeye]

As Micrometer 1.0.x line has reached its EOL and there were no issues related to the change since then, this seems okay to be closed now.

[shakuzen]

Was this a deliberate change?

I'm not sure if it was deliberate. It doesn't seem to add any value (no pun intended) to suffix all gauge metric names with .value. We're setting the Unit for them. @jkschneider do you remember if this change was intentional? Either way, changing it back would break users who are using the names with the .value on them. We could course correct long-term, though.

{MetricName: jvm.memory.max.value,Dimensions: [{Name: area,Value: nonheap}, {Name: id,Value: CodeHeap 'non-profiled nmethods'}],Timestamp: Thu Sep 03 17:46:55 JST 2020,Value: 1.22912768E8,Values: [],Counts: [],Unit: Bytes,}

And are the names supposed to remain consistent going forwards?

Yes, the intention is to keep them stable since changes to names can break alerts and dashboards.

[daddyg]

Hi all,

I was just wondering if this is being looked in to. I am experiencing the same issue where an upgrade to spring boot 2.1 has broken a load of our dashboards and alarms.

We have two situations:

• metric names that were suffixed with .count manually are now showing as .count.count
• metric names that were not suffixed with .count are now suffixed with .count

The first of these issues can be fixed in code by changing the metric name we specify but the second situation requires us to go and change any alarm or dashboard where we have these metrics in use.

There is also a more worrying side effect of this though in our unit and feature tests. Let's assume that I want to publish a requests.success.count metric. In order for the CloudWatch metric to be published as requests.success.count, I have to name the metric in code as requests.success, and let the micrometer cloudwatch registry add the .count suffix. But in my tests which use a different metric registry, I have to expect the name of the metric to be without the suffix. This seems both counter intuitive and also inconsistent with other micrometer registries.

Thanks,

Mike

[marcingrzejszczak]

Boot 3.1 is the latest supported OSS version. Is this still a problem now?

[github-actions[bot]]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[github-actions[bot]]

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open.