Custom Metrics Unit not valid

[JosephHobbs]

Describe the bug

I'm using the client to pull a list of metrics defined within my Dynatrace SaaS tenant. When I run dt.metrics.list() it results in a ValueError indicating that 'xxx' is not a valid Unit. Due to this error, I am unable to retrieve all metric information available.

ValueError: 'sessions' is not a valid Unit

In my circumstance, the invalid units all relate back to custom metrics. From what I can tell, I think they are being created/populated by a Spring Boot app pushing data via Micrometer. Specifically I'm seeing these values triggering failures.

• buffers
• bytes
• classes
• events
• files
• milliseconds
• rows
• sessions
• tasks
• threads

If I set the metadata_selector to 'custom("false")' it filters out way more than just these items. For example, metrics from extensions/etc. are no longer returned.

I get the point of using an Enum here, but it sounds like the tenant lets you use just about anything as a Unit. If that the case, should this be relaxed or just use a string variable or something?

To Reproduce

Steps to reproduce the behavior:

1. Create a custom metric with a unit that is not present as a value in the Unit enum.
2. Execute a dt.metrics.list() and process results.
3. See ValueError returned.

Expected behavior

Knowing that a Unit type other than those declared by Dynatrace could exist, the client should handle this situation gracefully. Either leverage an Enum that represents 'any other value' or use something that won't fail if an unexpected value is returned.

Additional context

Thank you!

[JosephHobbs]

Even better, instead of using a static Enum for Unit, pull it from the Environment V2 /units API?

[Dynatrace-James-Kitson]

Thanks @JosephHobbs - given that this list of defined units has grown substantially maintaining this as an enum becomes even more unwieldy, and especially as there can be cases where the units are not even know by Dynatrace in advance it all points to using an enum not being worth the benefits it adds.

Your solution of a a fallback type would work but since it prevents a user from being able to make use of that field it's just further justification to change and treat this as a simple string.

Thank you for your raising this and contribution.

[JosephHobbs]

I agree 100% and appreciate the response. My goal was just to get it working, so I didn't want to propose such a drastic change. This works perfectly.

Thank you!