Motivation

Today modules come with exactly one default configuration file, modules.d/<module>.yml.disabled. When the module is enabled, this file is replaced by modules.d/<module>.yml.

Sometimes it might be useful to have a configuration file for a module that is a slight variant of what we provide today. For example, consider the elasticsearch module in Metricbeat. It's default module configuration file looks like this:

# Module: elasticsearch
# Docs: https://www.elastic.co/guide/en/beats/metricbeat/master/metricbeat-module-elasticsearch.html

- module: elasticsearch
  #metricsets:
  #  - node
  #  - node_stats
  period: 10s
  hosts: ["http://localhost:9200"]
  #username: "user"
  #password: "secret"

However, if we want to configure this module for X-Pack Monitoring, we need the module configuration file to look like this:

# Module: elasticsearch
# Docs: https://www.elastic.co/guide/en/beats/metricbeat/master/metricbeat-module-elasticsearch.html

- module: elasticsearch
  metricsets:
    - ccr
    - cluster_stats
    - index
    - index_recovery
    - index_summary
    - ml_job
    - node_stats
    - shard
  period: 10s
  hosts: ["http://localhost:9200"] 
  #username: "user"
  #password: "secret"
  xpack.enabled: true 

Today, a user would have to metricbeat modules enable elasticsearch and then manually make the necessary changes to modules.d/elasticearch.yml to configure it properly for X-Pack Monitoring.

Proposal

We ship not only modules.d/elasticsearch.yml.disabled but also modules.d/elasticsearch-xpack.yml.disabled. If a user runs metricbeat modules enable elasticsearch the first disabled file is enabled. But if the user runs metricbeat modules enable elasticsearch-xpack the second disabled file is enabled.

This has the implication that module names cannot contain - but I think that's a reasonable limitation? Of course, we can choose another delimiter as well, as long as it works well across OSes.