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

Allow auto-configuration of Metricbeat stack modules for stack monitoring #17609

Merged
merged 40 commits into from
Apr 16, 2020

Conversation

ycombinator
Copy link
Contributor

@ycombinator ycombinator commented Apr 8, 2020

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, and beat.

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 to true, 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

  • My code follows the style guidelines of this project
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I have made corresponding change to the default configuration files
  • I have added tests that prove my fix is effective or that my feature works
  • I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Related issues

@jsoriano jsoriano self-requested a review April 8, 2020 18:18
@ycombinator ycombinator marked this pull request as ready for review April 8, 2020 20:16
@ycombinator ycombinator added enhancement Metricbeat Metricbeat module needs_backport PR is waiting to be backported to other branches. Feature:Stack Monitoring Team:Services (Deprecated) Label for the former Integrations-Services team v7.8.0 v8.0.0 labels Apr 8, 2020
@elasticmachine
Copy link
Collaborator

Pinging @elastic/integrations-services (Team:Services)

@elasticmachine
Copy link
Collaborator

Pinging @elastic/stack-monitoring (Stack monitoring)

metricbeat/mb/mb.go Outdated Show resolved Hide resolved
Copy link
Member

@jsoriano jsoriano left a 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 Show resolved Hide resolved
UnpackConfig(to interface{}) error

// ReConfigure reconfigures the module with the new configuration object.
ReConfigure(config *common.Config, register *Register) error
Copy link
Member

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.

Copy link
Contributor Author

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:

type Wrapper struct {
.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed in fc45f1d55.

Copy link
Member

@jsoriano jsoriano Apr 15, 2020

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, so mb.Module can be seen as a way to control visibility. When a method receives a mb.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.

metricbeat/mb/mb.go Outdated Show resolved Hide resolved
metricbeat/helper/elastic/elastic.go Show resolved Hide resolved
metricbeat/mb/testing/modules.go Outdated Show resolved Hide resolved
@@ -140,3 +142,81 @@ func TestFixTimestampField(t *testing.T) {
})
}
}

func TestReconfigureXPackEnabledMetricSets(t *testing.T) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

Copy link
Contributor Author

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!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 81e1d967a.

metricbeat/helper/elastic/elastic.go Outdated Show resolved Hide resolved
@@ -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
Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added in 168f7e53c.

Copy link
Member

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.

metricbeat/mb/mb.go Outdated Show resolved Hide resolved
metricbeat/helper/elastic/elastic.go Show resolved Hide resolved
@ycombinator
Copy link
Contributor Author

ycombinator commented Apr 9, 2020

@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!

Copy link
Contributor

@dedemorton dedemorton left a 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.

metricbeat/module/beat/_meta/docs.asciidoc Outdated Show resolved Hide resolved
metricbeat/docs/modules/beat.asciidoc Outdated Show resolved Hide resolved
@ycombinator
Copy link
Contributor Author

Hey @jsoriano @dedemorton this is ready for review when you get a chance. Thanks!

metricbeat/helper/elastic/elastic.go Outdated Show resolved Hide resolved
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:
Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated in 9b48420e8.

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`.

Copy link
Contributor Author

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

Copy link
Contributor

@dedemorton dedemorton left a 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.

metricbeat/docs/modules/beat.asciidoc Outdated Show resolved Hide resolved
Copy link
Member

@jsoriano jsoriano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

metricbeat/module/logstash/logstash_test.go Show resolved Hide resolved
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`.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

metricbeat/helper/elastic/elastic.go Outdated Show resolved Hide resolved
@jsoriano
Copy link
Member

jenkins, test this again please

@jsoriano
Copy link
Member

@ycombinator failure in CI is related:

# github.com/elastic/beats/v7/metricbeat/mb [github.com/elastic/beats/v7/metricbeat/mb.test]
mb/mb_test.go:472:31: too many arguments in call to bm.WithConfig
	have (*common.Config, *Register)
	want (common.Config)

Copy link
Contributor

@dedemorton dedemorton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ycombinator ycombinator merged commit 8e9c73b into elastic:master Apr 16, 2020
@ycombinator ycombinator deleted the mb-stack-auto branch April 16, 2020 20:17
@ycombinator ycombinator removed the needs_backport PR is waiting to be backported to other branches. label Apr 16, 2020
ycombinator added a commit that referenced this pull request Apr 24, 2020
…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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Feature:Stack Monitoring Metricbeat Metricbeat module Team:Services (Deprecated) Label for the former Integrations-Services team v7.8.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Auto-configure stack monitoring metricsets when xpack.enabled is set to true
5 participants