Metricbeat: Canonicalize MBean names in Jolokia module #7321
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jsoriano
added
module
review
Metricbeat
jsoriano
force-pushed
the
jolokia-wildcard-canonical-names
branch
from
c2374dd
to
a84cbbf
Compare
|
jenkins, test this again, please |
ruflin
reviewed
Jun 14, 2018
| return errors.Errorf("metric key '%v' for mbean '%s' not found in mapping (%+v)", attributeName, requestMbeanName, mapping) | ||
| // This shouldn't ever happen, if it does it is probably that some of our | ||
| // assumptions when building the request and the mapping is wrong. | ||
| logp.Debug("jolokia.jmx", fmt.Sprintf("mapping: %+v", mapping)) |
There was a problem hiding this comment.
you don't need the fmt.Sprintf part here, you can write:
logp.Debug("jolokia.jmx", "mapping: %+v", mapping)
There was a problem hiding this comment.
Or you can use Debugw with a the structured logger with a "jolokia" context.
There was a problem hiding this comment.
Much better without Sprintf yes, thanks :)
We were setting the `canonicalNaming` option to `false` in requests to Jolokia, assuming that it should leave MBean names in responses as they are. We need that for mappings to work. But in some scenarios, as when using wildcards, Jolokia is responding with canonicalized names, what breaks mappings. This change canonicalizes names from config only for mappings and the pre-built request. If we see that after setting `canonicalNaming` to `true` there is some scenario in which Jolokia replies with non-canonicalized names, then we'd have to canonicalize also MBeans for responses, or rethink how we do the mapping.
jsoriano
force-pushed
the
jolokia-wildcard-canonical-names
branch
from
a84cbbf
to
5e98ce5
Compare
jsoriano
added a commit
to jsoriano/beats
that referenced
this pull request
Jun 20, 2018
We were setting the `canonicalNaming` option to `false` in requests to Jolokia, assuming that it should leave MBean names in responses as they are. We need that for mappings to work. But in some scenarios, as when using wildcards, Jolokia is responding with canonicalized names, what breaks mappings. This change canonicalizes names from config only for mappings and the pre-built request. If we see that after setting `canonicalNaming` to `true` there is some scenario in which Jolokia replies with non-canonicalized names, then we'd have to canonicalize also MBeans for responses, or rethink how we do the mapping. (cherry picked from commit ef70ea0)
jsoriano
added
v6.3.1
and removed
needs_backport
ruflin
pushed a commit
that referenced
this pull request
Jun 21, 2018
…okia module (#7385) We were setting the `canonicalNaming` option to `false` in requests to Jolokia, assuming that it should leave MBean names in responses as they are. We need that for mappings to work. But in some scenarios, as when using wildcards, Jolokia is responding with canonicalized names, what breaks mappings. This change canonicalizes names from config only for mappings and the pre-built request. If we see that after setting `canonicalNaming` to `true` there is some scenario in which Jolokia replies with non-canonicalized names, then we'd have to canonicalize also MBeans for responses, or rethink how we do the mapping. (cherry picked from commit ef70ea0)
leweafan
pushed a commit
to leweafan/beats
that referenced
this pull request
Apr 28, 2023
… in Jolokia module (elastic#7385) We were setting the `canonicalNaming` option to `false` in requests to Jolokia, assuming that it should leave MBean names in responses as they are. We need that for mappings to work. But in some scenarios, as when using wildcards, Jolokia is responding with canonicalized names, what breaks mappings. This change canonicalizes names from config only for mappings and the pre-built request. If we see that after setting `canonicalNaming` to `true` there is some scenario in which Jolokia replies with non-canonicalized names, then we'd have to canonicalize also MBeans for responses, or rethink how we do the mapping. (cherry picked from commit 7dbdf8f)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We were setting the
canonicalNamingoption tofalsein requests toJolokia, assuming that it should leave MBean names in responses as they
are. We need MBeans in request and in responses to be the same for
mappings to work.
But in some scenarios, as when using wildcards, Jolokia is responding with
canonicalized names, what breaks mappings.
This change canonicalizes names from config only for mappings and the
pre-built request. If we see that after setting
canonicalNamingtotruethere is some scenario in which Jolokia replies with non-canonicalized
names, then we'd have to canonicalize also MBeans for responses, or rethink
how we do the mapping.