Document configuration blocks that are supported in Central Management

[dedemorton]

Right now, we don't do a very good job of describing the configuration blocks that are supported in central management. We need to indicate which options are supported so users don't need to play whack-a-mole to figure out what's allowed.

[dedemorton]

We also need to document restrictions more clearly.

[dedemorton]

@exekias @mattapperson I want to make sure we don't have any holes here. Can you help me identify the config settings that are (or aren't) supported in CM?

[mattapperson]

Pinging @ph and @urso

[ph]

The way that CM currently works it to listen to some configuration block, looking at what we have the following keys and eveything under them are handled by CM.

filebeat.modules:
metribeat.modules:
filebeat.inputs:
output:

Anything outside the above keys are OK to be modified by the user.

Logging options, setup.* options and xpack.* options.

[ph]

Currently as of today only the elasticsearch /Logstash /kafka output should be supported, we might add support for kafka redis, the console and the file output will not be exposed by CM and they will be blacklisted #9099

All current Metricbeat, Filebeat modules should be exposed in the UI and we don't have currently any limitation on them.

[mattapperson]

Kafka is supported, as is logstash

[dedemorton]

@ph So to clarify, I think you are saying:

• After users enroll a Beat in central management, all the configs under the following sections need to be defined through the UI in Kibana:

  • filebeat.modules:
  • metribeat.modules:
  • filebeat.inputs:
  • output:

  Question: If they are defined in the yml, what happens? Are they ignored?

• Any configs not in this list ^^ can be defined in the local filebeat.yml or metricbeat.yml configuration files after the user has enrolled the Beat.

Is that correct?

[martin-br]

we might add support for redis

I confirm that it would be really nice to still be able to output to Redis either by manual configuration in local yml that would not be ignored or even better through CM.

[ph]

@martin-br I would prefer to keep the source of truth from CM and not having to reconcile local states vs remotes states.

[martin-br]

@ph I fully agree, to support Redis output in CM should be the target 👍 Should I create a new issue dedicated ?

[ph]

@martin-br Yes and I will track it. :)