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

Unify default module configurations #6908

Merged
merged 8 commits into from
May 17, 2018
Merged

Conversation

exekias
Copy link
Contributor

@exekias exekias commented Apr 20, 2018

Since we split module configurations into modules.d folder, we can keep
configurations more verbose, so users have a quick reference when
opening them for editing.

This change unifies configuration files using the followin rules:

  • Write at least the following settings, in this order: module,
    metricsets, period, hosts.
  • Default metricsets list shown as it helps to know what's the list,
    or disable just one. Inline if there is only one metricset, one line
    per metricset if there is more than one.
  • Some modules have exceptions and include more definitions, or different
    defaults.
  • Comments are allowed (and encouraged), both to explain a setting and
    to suggest a full configuration.
  • enabled setting is not shown at all, modules are enabled by using
    metricbeat modules enable <module name>. Use comments to suggest
    settings that are disabled by default.

@exekias exekias added discuss Issue needs further discussion. review Metricbeat Metricbeat needs_backport PR is waiting to be backported to other branches. v6.3.0 labels Apr 20, 2018
@exekias
Copy link
Contributor Author

exekias commented Apr 20, 2018

Changes are duplicated so there is only need to review 32 files under module/*/_meta/config.yml, modules.d and docs are generated from there

@exekias exekias force-pushed the unify-module-confs branch 2 times, most recently from 79b7642 to 69eee1a Compare April 20, 2018 10:55
#- core
#- diskio
#- socket
processes: ['.*']
Copy link
Member

Choose a reason for hiding this comment

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

This is the default, should we leave it commented out?

Copy link
Contributor

@ruflin ruflin left a comment

Choose a reason for hiding this comment

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

Here is the meta issue where we discussed the initial changes: #6668 We should separate the discussion here between the short config and reference config:

short config:

  • We removed the metricsets from the config.yml to make sure always the defaults apply. So if we add one more metricset, the config does not have to change and you automatically get the new metricset. I like the config without the metricsets as it focuses on the modules. Most users are at first probably not interested in the metricsets.
  • period: Our take was to remove it if it's the default and only leave it in if it deviates. It makes the config shorter
  • +1 on module and hosts
  • Instead of adding lots of comments, we should link to the docs page. The reference config is that contains all the comments.

I personally would prefer that we keep the short config really short and use the reference for all the comments etc. I think this PR starts to blur the lines again.

@@ -1,2 +1,4 @@
- module: aerospike
metricsets: ["namespace"]
Copy link
Contributor

Choose a reason for hiding this comment

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

The reason we left out the metricsets in the short config is to make sure we always have the default behaviour an it's not influence by the config. So if we add one more metricset to the defaults, a user will get it automatically without having to change the 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.

I see this point, what about having them commented?

@@ -1,2 +1,4 @@
- module: aerospike
metricsets: ["namespace"]
period: 10s
Copy link
Contributor

Choose a reason for hiding this comment

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

I remember @andrewkroh suggested to remove period. The part I like about it is that it makes the config even shorter.

Copy link
Member

Choose a reason for hiding this comment

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

One option would be to only include the period when it's not the default of 10s.

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 general, I would prefer to keep it as it adds visibility to the setting, any user opening the config file for the module will know what that is and how it works really quick. If we remove it they need to go back to the docs.

@@ -1,7 +1,16 @@
- module: ceph
metricsets: ["cluster_health", "cluster_status", "monitor_health"]
metricsets:
- cluster_health
Copy link
Contributor

Choose a reason for hiding this comment

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

+1 on the new structure here, makes it easier to comment one.

period: 10s
hosts: ["localhost:5000"]
Copy link
Contributor

Choose a reason for hiding this comment

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

oh, seems like we forgot hosts here :-(

- cluster_disk
- osd_tree
- osd_df
- pool_disk
period: 1m
Copy link
Contributor

Choose a reason for hiding this comment

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

this is a good example I think where having period in makes sense.

@@ -1,2 +1,8 @@
- module: windows
period: 60s
metricsets: ["perfmon"]
Copy link
Contributor

Choose a reason for hiding this comment

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

This is not enabled by default so it should not be here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I commented it out

Copy link
Member

@andrewkroh andrewkroh left a comment

Choose a reason for hiding this comment

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

👍

# - core
# - diskio
# - socket

- module: system
period: 1m
metricsets:
Copy link
Member

Choose a reason for hiding this comment

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

I think it might make sense to use the ignore_types option instead of the filter. Or maybe these mounts are filtered by default now?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's a good question, @jsoriano do your recent changes affect this?

Copy link
Member

Choose a reason for hiding this comment

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

Oh sorry, I forgot this question. My latest changes filter by default the filesystem types marked as nodev in /proc/filesystems, and remove duplications caused by bind mounts and similar. Probably this is enough to have meaningful events by default without needing these processors.

period: 60s
metricsets: ["perfmon"]
period: 10s
perfmon.counters:
Copy link
Member

Choose a reason for hiding this comment

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

While it would be a deviance from the defaults, I think that including an example would be very helpful to users. We have some in the docs.

period: 10s
metricsets:
- cpu
- load
Copy link
Member

Choose a reason for hiding this comment

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

load doesn't exist for Windows. Does load get deleted during packaging for Windows (check before-build in the Makefile)?

Copy link
Contributor Author

@exekias exekias Apr 20, 2018

Choose a reason for hiding this comment

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

It should, but it's a good point, I must test this

Carlos Pérez-Aradros Herce added 2 commits April 20, 2018 16:50
Since we split module configurations into modules.d folder, we can keep
configurations more verbose, so users can have a quick reference when
opening them for editing.

This change unifies configuration files using the followin rules:

 * Write at least the following settings, in this order: `module`,
 `metricsets`, `period`, `hosts`.
 * Default metricsets list shown as it helps to know what's the list,
 or disable just one. Inline if there is only one metricset, one line
 per metricset if there is more than one.
 * Some modules have exceptions and include more definitions, different
 defaults.
 * Comments are allowed (and encouraged), both to explain a setting and
 to suggest a full configuration.
 * `enabled` setting is not shown at all, modules are enabled by using
 `metricbeat modules enable <module name>`. Use comments to suggest
 settings that are disabled by default.
@exekias exekias force-pushed the unify-module-confs branch from 36a3790 to 2581f7e Compare April 20, 2018 14:50
@exekias exekias force-pushed the unify-module-confs branch from 290b591 to ddf9cc9 Compare April 25, 2018 16:43
@exekias exekias force-pushed the unify-module-confs branch from 0b5829c to efc0520 Compare April 25, 2018 17:02
@exekias
Copy link
Contributor Author

exekias commented Apr 25, 2018

I gave this another spin: included link to docs + commented metricsets

@@ -20,7 +20,9 @@ in <<configuration-metricbeat>>. Here is an example configuration:
----
metricbeat.modules:
- module: golang
metricsets: ["expvar","heap"]
# metricsets:
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: Could you put the # directly before the metricset without space? It's more similar to what we do everywhere else.

@@ -19,28 +19,32 @@ in <<configuration-metricbeat>>. Here is an example configuration:
----
metricbeat.modules:
- module: jolokia
metricsets: ["jmx"]
# metricsets: ["jmx"]
Copy link
Contributor

Choose a reason for hiding this comment

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

Comment above applies to all #

# Password of hosts. Empty by default.
#password: secret

# By setting raw to true, all raw fields from the status metricset will be added to the event.
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's remove this from here as I don't want to encourage people to use it.

@@ -1,2 +1,17 @@
- module: mysql
hosts: ["tcp(127.0.0.1:3306)/"]
# metricsets: ["status"]
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we use here also the - notation already?

hosts: ["localhost:8080"]
status_path: "/status"
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this a default? If yes, it should be commented out.

# should never take longer then period, as otherwise calls can pile up.
#timeout: 1s

# Optional fields to be added to each event
Copy link
Contributor

Choose a reason for hiding this comment

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

This is not specific to redis, lets remove it.

# Max number of concurrent connections. Default: 10
#maxconn: 10

# Filters can be used to reduce the number of fields sent.
Copy link
Contributor

Choose a reason for hiding this comment

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

This is not redis specific, lets remove it.


# TODO add module release status if beta or experimental
header = """# Module: {module}
# Docs: https://www.elastic.co/guide/en/beats/metricbeat/{docs_branch}/metricbeat-module-{module}.html
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice


"""

# Create directory for module confs
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we have the docs link also in the reference config file?

Copy link
Contributor Author

@exekias exekias May 9, 2018

Choose a reason for hiding this comment

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

I gave this a try but it would change reference file for all beats, and URL patterns are different. Also, not sure if it's that useful there, as it's the reference file. What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

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

As this is the module collection only for metricbeat, why did it change the other config files?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was talking about reference file, which is being collected by a different script

Copy link
Contributor

Choose a reason for hiding this comment

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

Got it, lets leave it out for now then.

@@ -10,6 +10,7 @@ ES_BEATS?=..
GOX_OS=netbsd linux windows
GOX_FLAGS=-arch="amd64 386 arm ppc64 ppc64le"

DOCS_BRANCH=$(shell grep doc-branch ../libbeat/docs/version.asciidoc | cut -c 14-)
Copy link
Contributor

Choose a reason for hiding this comment

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

LGTM for now but just want to mention that this pretty fragile as we found out other cases.

@@ -251,7 +253,8 @@ metricbeat.modules:

#-------------------------------- HTTP Module --------------------------------
- module: http
metricsets: ["json"]
#metricsets:
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we in the reference file have the enabled one commented out to make it more clear? I like it in the short config to make sure the defaults keep working but here it's more about documenting it?

Copy link
Contributor

@ruflin ruflin left a comment

Choose a reason for hiding this comment

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

We are close :-)

@@ -1,2 +1,4 @@
- module: aerospike
# metricsets: ["namespace"]
Copy link
Contributor

Choose a reason for hiding this comment

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

should be before metricsets directly for consistency.

@@ -1,2 +1,21 @@
- module: postgresql
#metricsets:
# # Stats about every PostgreSQL database
Copy link
Contributor

Choose a reason for hiding this comment

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

I would remove the comments for the metricsets. For these details we have the docs.

hosts: ["localhost:15672"]

username: guest
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 commented out or is guest a common default?

Copy link
Member

@jsoriano jsoriano May 14, 2018

Choose a reason for hiding this comment

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

Yes, guest exists by default.

Copy link
Contributor

Choose a reason for hiding this comment

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

So it's better to connect by default with guest/guest the have no credentials?

Copy link
Member

Choose a reason for hiding this comment

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

guest/guest can be seen as some kind of "no credentials" for rabbitmq :)
By default it always exists, and I don't know if it is possible to connect with rabbitmq without credentials. I think it'd be good if metricbeat tries to connect with these credentials by default too, so it can collect some metrics out of the box.

Copy link
Contributor

Choose a reason for hiding this comment

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

SGTM. Not part of this PR but I wonder if we should in these case then also set them directly in the code as defaults.

Copy link
Member

Choose a reason for hiding this comment

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

Yes, good point, I'll take care of this.

@ruflin ruflin merged commit 16015b5 into elastic:master May 17, 2018
stevea78 pushed a commit to stevea78/beats that referenced this pull request May 20, 2018
Since we split module configurations into modules.d folder, we can keep
configurations more verbose, so users have a quick reference when
opening them for editing.

This change unifies configuration files using the followin rules:

 * Write at least the following settings, in this order: `module`,
 `metricsets`, `period`, `hosts`.
 * Default metricsets list shown as it helps to know what's the list,
 or disable just one. Inline if there is only one metricset, one line
 per metricset if there is more than one.
 * Some modules have exceptions and include more definitions, or different
 defaults.
 * Comments are allowed (and encouraged), both to explain a setting and
 to suggest a full configuration.
 * `enabled` setting is not shown at all, modules are enabled by using
 `metricbeat modules enable <module name>`. Use comments to suggest
 settings that are disabled by default.
stevea78 pushed a commit to stevea78/beats that referenced this pull request May 20, 2018
Since we split module configurations into modules.d folder, we can keep
configurations more verbose, so users have a quick reference when
opening them for editing.

This change unifies configuration files using the followin rules:

 * Write at least the following settings, in this order: `module`,
 `metricsets`, `period`, `hosts`.
 * Default metricsets list shown as it helps to know what's the list,
 or disable just one. Inline if there is only one metricset, one line
 per metricset if there is more than one.
 * Some modules have exceptions and include more definitions, or different
 defaults.
 * Comments are allowed (and encouraged), both to explain a setting and
 to suggest a full configuration.
 * `enabled` setting is not shown at all, modules are enabled by using
 `metricbeat modules enable <module name>`. Use comments to suggest
 settings that are disabled by default.
@exekias exekias removed needs_backport PR is waiting to be backported to other branches. v6.3.0 labels Jun 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss Issue needs further discussion. Metricbeat Metricbeat review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants