Multiple outputs

[mdklapwijk]

First try at allowing filebeat having multiple outputs:

• shared inputs; all outputs share the same input config,
• named configs; each output has its own main yaml config,
• named services; each output has is own systemd unit file,
• composite service; to start and stop all named services at once.

Note: only tested on Debian 10.

[pcfens]

I love the idea of using the upstream elastic repo as suggested in #189, but we customize a few things in the setup. I think it's reasonable to ask users that need those customizations to set manage_repo to false and manage it themselves, but we should probably remove references to the parameters too (README, params.pp, init.pp).

[pcfens]

Can we split the defined type in to its own file.

We might want to think about titling this one a little different too since we're not creating a new "add". I don't have another idea yet though.

[pcfens]

Thanks @mdklapwijk! This will help a lot moving towards some form of support on #48 too.

It sounds like there are a lot of changes in here in addition to supporting multiple outputs, including deprecating support for Filebeat 6 (probably time to do that anyway), switches to the elastic_stack::repo module for the apt/yum repos, and 2 new module dependencies.

I'd like to add some unit tests to the systemd logic so we can confidently make changes in the future (I need to move them from Travis to GitHub actions so they run here too).

[mdklapwijk]

Hi Phil,

I was planning on starting a stripped version, dropping FB6, Windows support etc. So I could implement filebeat::output, just like filebeat::input. As stated, this was my first attempt at this and it was done in such a manner it would not interfere with the already existent logic, hence the big foreach-loop over the outputs-hash in config.pp.

If you are interested I would create a new branch for this later this week, as I already (partly) done the filebeat::output, but it broke backward compat. a bit...

Regards,

Marcel