Describe the enhancement:

The Beats should either fail to start and/or log error messages when unrecognized settings are used in the Beats yaml files.

Describe a specific use case for the enhancement or feature:

For example, Elasticsearch 8.7.0 (as it was what I already had downloaded), does the following if a setting of foo: bar was added to the yaml file:

[2023-10-09T17:49:54,590][ERROR][o.e.b.Elasticsearch      ] [REDACTED] fatal exception while booting Elasticsearchjava.lang.IllegalArgumentException: unknown setting [foo] please check that any required plugins are installed, or check the breaking changes documentation for removed settings
	at org.elasticsearch.server@8.7.0/org.elasticsearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:575)
	at org.elasticsearch.server@8.7.0/org.elasticsearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:521)
	at org.elasticsearch.server@8.7.0/org.elasticsearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:491)
	at org.elasticsearch.server@8.7.0/org.elasticsearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:461)
	at org.elasticsearch.server@8.7.0/org.elasticsearch.common.settings.SettingsModule.<init>(SettingsModule.java:151)

which was likely added as part of elastic/elasticsearch#20951.

However, I repeated the same steps with Filebeat 8.8.1 (as it is what I had already downloaded), nothing was mentioned regarding the setting

% grep foo filebeat-20231009.ndjson
% grep -v info filebeat-20231009.ndjson
{"log.level":"warn","@timestamp":"2023-10-09T17:52:26.856-0500", ...

Although the example is over simplified, this is a problem because the lack of "allow list" validation for settings increases the time required for troubleshooting and validation of configuration files during upgrades. Some examples of the challenges this creates includes:

• Filebeat doe not flag the setting difference for multiline between filestream and log inputs
  • https://www.elastic.co/guide/en/beats/filebeat/8.10/multiline-examples.html
  • https://www.elastic.co/guide/en/beats/filebeat/7.17/multiline-examples.html
  • It is too easy to just replace "log" with "filestream" for the input stream and assume the settings are the same, then end up on
• Typos on settings names
  • Leads to unnecessary hours spent troubleshooting if one doesn't recognize two letters transposed in a word in the Yaml file
• Version upgrades, especially major version upgrades
  • Although there is a config file test command, it runs the same configuration validation as the usual program. It flags yaml formatting issues but not incorrect or unknown settings.
  • The work around for this is to go line by line in the yaml configuration files comparing the settings against the {type}beat.reference.yaml file and the documentation pages. This would be much more efficient for the computer program to do this work instead of manually by a human.

Note: This same problem may apply to Elastic Agent and Fleet policy set-up in Kibana. I just didn't check these nor open tickets for it.