-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added transformation closure to MBeanHelper #960
Conversation
Do you think my suggestion of #901 (comment) would be more expressive for general use cases? The closures accept an mbean instead of an attribute value. |
@@ -106,7 +125,9 @@ class MBeanHelper { | |||
return [ofInterest, attributes].combinations().collect { pair -> | |||
def (bean, attribute) = pair | |||
try { | |||
new Tuple3(bean, attribute, bean.getProperty(attribute)) | |||
def extractedAttribute = bean.getProperty(attribute) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would expect this to throw the AttributeNotFoundException* for custom ones. As is this would require all passed maps to be value-ovewriting processors instead of allowing a general computed value capability.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I guest when I first conceptualized this I only thought about it through the lens of transforming existing attributes. Do you think it would be good to allow the instrument helpers to target attributes that don't actually exist on the mbeans?
Hey @rmfitzpatrick, that's valid, I can make that adjustment. |
Hey @rmfitzpatrick, I addressed your comments and just added another test case for custom attributes. |
jmx-metrics/src/test/java/io/opentelemetry/contrib/jmxmetrics/MBeanHelperTest.java
Outdated
Show resolved
Hide resolved
return ofInterest.collect { | ||
try { | ||
it.getProperty(attribute) | ||
attributeTransformation.containsKey(attribute) ? attributeTransformation[attribute](it) : it.getProperty(attribute) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small point -- I'm not sure about groovy, but in java calling containsKey()
immediately followed by get()
could (in early versions at least) incur two lookups. It's probably fine, and the size of the number of beans in our maps here is so small to render this moot....however, if you did factor out a method at least you could avoid the code duplication below. Something like getPropertyValue(bean, attribute)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @breedx-splk, yep I refactored this when resolving the conflict with the callback change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it. I think this is a worthy change that we can continue improving on if needed. Thanks!
1b2cfe5
to
351c964
Compare
168446c
to
f886400
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tiny naming nit, otherwise looks great.
} | ||
} | ||
|
||
Object getBeanAttributeTransform(GroovyMBean bean, String attribute){ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be getBeanAttribute*or*Transform
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep fair point, I changed it to WithTransform since its kind of a proxy function
da6e91c
to
f886400
Compare
"{mbean -> mbean.getProperty(\"SomeAttribute\") == 'someValue' ? 'newValue' : 'someValue'}") | ||
}, | ||
{ | ||
"AnotherAttribute", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mind updating this to try to get a nonexistent property for error handling vetting? I think it repeats existing added coverage.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In its current state I think that'll throw an AttributeNotFound exception, do we want to handle that error in the same manner as if a nonexistent property was passed to an instrument helper? I just followed the pattern of labelFuncs and the other closure params where it doesn't look like theres any additional error handling
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the same error behavior makes sense and it could be helpful to add coverage to better enforce that moving forward.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah thats a good point, I can create an additional PR for error handling the closure based args
This enhancement enables non-numeric mbean attributes to be transformed into numeric values that can be consumed by the instrument callbacks. The MbeanHelper component has been updated to also accept a map of closures for the attributes being targeted.
Example:
Existing Issue(s):
Resolves #901
Testing:
Added unit tests to MbeanHelperTest to include transformation scenarios
Documentation:
Updated README to include usage instructions