Micrometer: CloudWatch2: InvalidParameterValueException

[adanilinel1]

I tried using micrometer-registry-cloudwatch2:1.3.0 registry to publish metrics to CloudWatch.
The metrics are generated by Spring Boot, and the repository is configured with a filter for "http.server.requests" metric.

I am getting this exception:

software.amazon.awssdk.services.cloudwatch.model.InvalidParameterValueException: The parameter MetricData.member.4.Unit must be a value in the set [ Seconds, Microseconds, Milliseconds, Bytes, Kilobytes, Megabytes, Gigabytes, Terabytes, Bits, Kilobits, Megabits, Gigabits, Terabits, Percent, Count, Bytes/Second, Kilobytes/Second, Megabytes/Second, Gigabytes/Second, Terabytes/Second, Bits/Second, Kilobits/Second, Megabits/Second, Gigabits/Second, Terabits/Second, Count/Second, None ]

[adanilinel1]

I see that jvm.threads.states.value has unit as "null"

[izeye]

@adanilinel1 Thanks for the report, and sorry for the inconvenience.

When I was creating https://github.com/micrometer-metrics/micrometer/pull/1523, I misread UNKNOWN_TO_SDK_VERSION as unknown to SDK version from a client. Looking at the Javadoc for MetricDatum.unit(), it seems to be unknown to SDK version from a server. I created https://github.com/micrometer-metrics/micrometer/pull/1646 to fix this.

[twasink]

That would probably explain this error I'm getting then:

The parameter MetricData.member.5.Unit must be a value in the set ...

(The only metrics I'm publishing at the moment are the JvmMemoryMetrics)

I wasn't getting this error with the deprecated Cloudwatch v1

[shakuzen]

@twasink would you be able to try with 1.3.1-SNAPSHOT to see if the issue is fixed in the upcoming patch?

[dniel]

@shakuzen tried snapshot 1.3.1-SNAPSHOT now and it seems to solve the problem.

[shakuzen]

tried snapshot 1.3.1-SNAPSHOT now and it seems to solve the problem.

Thank you for trying the snapshot and letting us know it's working for you now.

[twasink]

I can indeed see metrics being published to Cloudwatch correctly now.

I've noticed that the earlier version also had a memory leak - my dev server was falling over after a few hours of idle use with the broken Cloudwatch logger. I'm now running a test to see if that continues with the SNAPSHOT, and will let you know of the results. (Again, all I have is the JvmMetrics being logged)

[twasink]

Okay - while I do indeed have a memory leak that was introduced at the same time I moved to the cloudwatch2 library, it turns out to be a bug in my own application code (doing something badly with SQS queues). The coincidence in timing is that I moved to cloudwatch2 because I'm moving to the AWS SDK for Java v2.

So it all looks good to me.

[shakuzen]

So it all looks good to me.

Thanks for confirming and reporting back.