Skip to content
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

Merged
merged 9 commits into from
Aug 4, 2023

Conversation

akats7
Copy link
Contributor

@akats7 akats7 commented Jul 16, 2023

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:

def exampleMBean = otel.mbean(
  "example.mbean", ["CustomAttrFromString": { mbean -> (mbean.getProperty("Attribute") == "running") ? 1 : 0 }]
)
otel.instrument(exampleMBean, "my-metric", "CustomAttrFromString", otel.&longUpDownCounterCallback)

Existing Issue(s):

Resolves #901

Testing:

Added unit tests to MbeanHelperTest to include transformation scenarios

Documentation:

Updated README to include usage instructions

@rmfitzpatrick
Copy link
Contributor

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)
Copy link
Contributor

@rmfitzpatrick rmfitzpatrick Jul 17, 2023

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.

Copy link
Contributor Author

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?

@akats7
Copy link
Contributor Author

akats7 commented Jul 18, 2023

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.

Hey @rmfitzpatrick, that's valid, I can make that adjustment.

@akats7
Copy link
Contributor Author

akats7 commented Jul 24, 2023

Hey @rmfitzpatrick, I addressed your comments and just added another test case for custom attributes.

cc. @breedx-splk @dehaansa @Mrod1598

return ofInterest.collect {
try {
it.getProperty(attribute)
attributeTransformation.containsKey(attribute) ? attributeTransformation[attribute](it) : it.getProperty(attribute)
Copy link
Contributor

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)

Copy link
Contributor Author

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

Copy link
Contributor

@breedx-splk breedx-splk left a 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!

@trask trask added this to the v1.29.0 milestone Jul 25, 2023
Copy link
Contributor

@dehaansa dehaansa left a 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){
Copy link
Contributor

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?

Copy link
Contributor Author

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

@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Jul 31, 2023

CLA Signed

The committers listed above are authorized under a signed CLA.

"{mbean -> mbean.getProperty(\"SomeAttribute\") == 'someValue' ? 'newValue' : 'someValue'}")
},
{
"AnotherAttribute",
Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor

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.

Copy link
Contributor Author

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

@trask trask merged commit aa0ca10 into open-telemetry:main Aug 4, 2023
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Enable ability to overwrite mbean attribute value
6 participants