-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Allow auto-configuration of Metricbeat stack modules for stack monitoring #17609
Conversation
fa6c19b
to
0f14eaa
Compare
Pinging @elastic/integrations-services (Team:Services) |
Pinging @elastic/stack-monitoring (Stack monitoring) |
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.
Good job here, it is an interesting approach to use the module builders for this, I sometimes wonder if we should have them, but this proves that they are useful 👍
I have added some suggestions, let me know what you think. I would like to limit the availability of Reconfigure
method so it is more clear that is only intended to be used on the base module on module factories.
metricbeat/mb/mb.go
Outdated
UnpackConfig(to interface{}) error | ||
|
||
// ReConfigure reconfigures the module with the new configuration object. | ||
ReConfigure(config *common.Config, register *Register) error |
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.
Remove it from the Module
interface? So this is only allowed in principle where a BaseModule
is received, as in module builders.
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.
Sure. I'd like to learn — mostly for my own curiousity — why this difference is significant. The only place I could find in the Metricbeat codebase where mb.Module
is implemented but mb.BaseModule
is not embedded was here:
beats/metricbeat/mb/module/wrapper.go
Line 53 in 95626b8
type Wrapper struct { |
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.
Changed in fc45f1d55.
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.
Sure. I'd like to learn — mostly for my own curiousity — why this difference is significant. The only place I could find in the Metricbeat codebase where mb.Module is implemented but mb.BaseModule is not embedded was here:
Well, this is not so significant, but there are two reasons why I would prefer to avoid adding a method to this interface:
mb.Module
is something like a "read-only" interface, that can be used to access to information about the module, but not modifying it, somb.Module
can be seen as a way to control visibility. When a method receives amb.Module
it knows that it is only to get information of the module. When a method receives a*mb.BaseModule
it has access to all the base module, this can be intended for methods like the module builders, where it can make sense to allow modifications of the module as it is still being built.mb.Module
is a public interface, adding methods to it can break existing code (as happened with the test here). Though I don't think many community beats are implementing their own mb.Modules... so not so important.
@@ -140,3 +142,81 @@ func TestFixTimestampField(t *testing.T) { | |||
}) | |||
} | |||
} | |||
|
|||
func TestReconfigureXPackEnabledMetricSets(t *testing.T) { |
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.
func TestReconfigureXPackEnabledMetricSets(t *testing.T) { | |
func TestConfigureModule(t *testing.T) { |
If not it looks like we are testing Reconfigure
, but there is already a test for that in metricbeat/mb/mb_test.go
.
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.
Ah yes, sorry, this is a leftover from previous iterations of the implementation. Good catch, thanks, will fix!
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.
Fixed in 81e1d967a.
metricbeat/mb/mb.go
Outdated
@@ -94,6 +104,44 @@ func (m *BaseModule) UnpackConfig(to interface{}) error { | |||
return m.rawConfig.Unpack(to) | |||
} | |||
|
|||
// ReConfigure re-configures the module with the given raw configuration |
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.
Maybe add a comment about this method being intended to be used in module factories.
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.
Sure, will do. Again, just to further my own understanding of how Metricbeat modules work, what would be the downside / risk of calling this method from some place other than a module factory?
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.
Added in 168f7e53c.
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.
Again, just to further my own understanding of how Metricbeat modules work, what would be the downside / risk of calling this method from some place other than a module factory?
Metricsets can access the module through base.Module()
, one metricset could modify the base module, unexpectedly affecting other metricsets of the same module.
@jsoriano Thanks for the review. I've addressed all your feedback so this PR is ready for another round of review when you get a chance. @dedemorton There are docs changes in this PR (see the thread here: #17609 (comment)). So I've requested your review as well. Thank you both! |
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.
Added suggestions to fix copy/paste error.
Hey @jsoriano @dedemorton this is ready for review when you get a chance. Thanks! |
af1dcc5
to
c054555
Compare
The Beat module contains a minimal set of metrics to enable monitoring of any Beat or other software based on libbeat across | ||
multiple versions. To monitor more Beat metrics, use our {stack} | ||
{monitor-features}. | ||
There are two modules that collect metrics about any Beat or other software based on libbeat: |
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.
Not sure if we should talk so explicitly about this as two modules, this can create confusion. In the docs and in the code this is a single module.
The only place where this behaves as two modules is when using metricbeat module
, but not everyone uses this approach to configure Metricbeat.
I think we should add something explaining xpack.enabled
option, and there we should explain that this option changes the enabled metricsets, for people using these docs as reference config.
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.
Sounds good. In addition to what you've said, I think it might be helpful to also mention under the xpack.enabled
option documentation that this option can be configured via a shortcut: metricbeat modules enable <actual_module_name>-xpack
. WDYT?
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.
Updated in 9b48420e8.
3de4b25
to
9b48420
Compare
UI in {kib}. To enable this usage, set `xpack.enabled: true` and remove any `metricsets` | ||
from the module's configuration. Alternatively, run `metricbeat modules disable beat` and | ||
metricbeat modules enable beat-xpack`. | ||
|
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.
@jsoriano Based on your feedback, I updated the docs for the beat
module. WDYT? @dedemorton I'd like your feedback as well.
If/when we're happy with the beat
module docs, I'll make similar changes to other stack modules' docs in this PR.
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.
LGTM.
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.
Except for the small nit I point out, the docs look fine.
We are really inconsistent throughout the docs where we refer to modules by name (sometimes uppercase, sometimes lowercase, and sometimes in back ticks. I like the way you've done it here (in back ticks) because it matches what users see in the config file. If you like this approach, I will create a clean up issue for this problem in the docs. Curious to hear what others think.
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.
Thanks!
UI in {kib}. To enable this usage, set `xpack.enabled: true` and remove any `metricsets` | ||
from the module's configuration. Alternatively, run `metricbeat modules disable beat` and | ||
metricbeat modules enable beat-xpack`. | ||
|
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.
LGTM.
jenkins, test this again please |
@ycombinator failure in CI is related:
|
Co-Authored-By: DeDe Morton <dede.morton@elastic.co>
0ecaad5
to
b9c5fd3
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.
LGTM
…ring (#17609) (#17772) * Add ability to reconfigure a module * Reconfigure Logstash module with required metricsets for xpack.enabled * Replace assert with require * Adding CHANGELOG entry * Update default configuration files * Auto-configure beat module metricsets when xpack.enabled = true * Refactoring common code into helper function * Adding tests for ReConfigure() / making it part of Module interface * Moving comments * Fixing infinite recursion 🤦 * Implement for kibana module * Implementing for elasticsearch module * Moving ReConfigure method to BaseModule from Module * Fixing test function name * Use errors.Wrapf * Logging config change * Adding comment about intent of use. * s/ReConfigure/Reconfigure/ * Don't pass registry * Return copy of reconfigured module * Updating module docs to clarify auto-configuration * Fixing test * Trying out docs for `beat` module * Fixing tests * Adding tests for ReConfigure() / making it part of Module interface * Moving comments * Fixing infinite recursion 🤦 * Implement for kibana module * Implementing for elasticsearch module * Moving ReConfigure method to BaseModule from Module * Logging config change * Return copy of reconfigured module * Updating module docs to clarify auto-configuration * Fixing test * Trying out docs for `beat` module * Update metricbeat/docs/modules/beat.asciidoc Co-Authored-By: DeDe Morton <dede.morton@elastic.co> * Uppercasing start of log message * Updating all stack modules' docs * Reodering imports * Fixing rebase error Co-authored-by: DeDe Morton <dede.morton@elastic.co> Co-authored-by: DeDe Morton <dede.morton@elastic.co>
What does this PR do?
Metricbeat offers four Elastic stack modules that can be used to collect and index data intended for the Stack Monitoring UI in Kibana:
elasticsearch
,kibana
,logstash
, andbeat
.Each of these modules' configurations accepts an optional boolean flag,
xpack.enabled
. By default, this flag is not set, in which case it's default value,false
is used. When this flat is set totrue
, this signals to the modules that they are to be used for the express purpose of collecting data for the Stack Monitoring UI in Kibana. In this case, specific metricsets in the module must be enabled, as the UI expects data collected by these metricsets to function properly.This PR makes it so that if
xpack.enabled: true
is set in a stack module's configuration, the required metricsets are automatically enabled in the module's configuration.Why is it important?
Without such automatic configuration the user must manually configure exactly the required metricsets when
xpack.enabled: true
is set.Checklist
I have made corresponding changes to the documentationCHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.Related issues