In Graylog 2, tags were a very convenient method for classifying and combining configurations for specific sidecars. E.g. a generic 'linux' tag for gathering generic logs from all Linux machines, and more specific tags that would only apply to certain machines (including these Linux machines).
Simply defining the appropriate tags in a sidecar configuration file on a server would cause it to collect the correct logs from this server, using the combined configurations for all these tags.
With the removal of tag-based configuration it looks like it is no longer possible to apply multiple configurations to a sidecar. I need to create a configuration for every single combination of (former) tags I want to use on all my servers, and combine the desired log inputs inside all these configurations using variables if I want to avoid duplication. The number of combinations can grow exponentially when more log inputs are introduced.
How difficult would it be to allow multiple configurations to be applied to a sidecar, effectively allowing the combination of different configurations without having to create a lot of compound configurations every time a new log input is introduced?
Please refer to this community thread for a workaround:
https://community.graylog.org/t/graylog-3-0-filebeat-configuration-and-tags/8949/16
One possible way to support this, is that we add a tags list back into the sidecar.yml.
We could expose these tags as runtime variables.
So let's say that your sidecar.yml has tags: [ "apache", "rails" ]
your configuration could render sections based on tags.
For instance
filebeat.inputs:
- type: log
paths:
- /var/log/test*.log
<#if sidecar.tags.apache?? >
- /var/log/apache
</#if>
<#if sidecar.tags.rails?? >
- /var/log/rails/application.log
</#if>
Hello,
Unfortunately, this doesn't work for Graylog 3.2 and a new sidecar.
Yeah, it would be nice to have this in the future but please focus on supporting ES 7
Most helpful comment
One possible way to support this, is that we add a tags list back into the
sidecar.yml.We could expose these tags as runtime variables.
So let's say that your sidecar.yml has
tags: [ "apache", "rails" ]your configuration could render sections based on tags.
For instance