Thanks Marius for the explanation, and totally understand that the solution needs to be scalable and needs to address equally the small and big deployments.
Before Graylog Sidecar, all our client machines that were running nxlog, each and every one of them had their own configuration locally stored and managed. Graylog Collector Sidecar is a great addition as it allows us to manage and update configurations centrally from Graylog. If we look at it from the client machine (collector) perspective, it needs to advertise the services it has for potential logging. Some Windows Examples: - Eventlog - Internal - MSSQL - IIS - IIS_Advanced - ... The client would not advertise anything that needs to be kept private or is not available. (in Tags I suppose) And that would be it from the client side. On Graylog Server side. Ideally we would want a flexible modular configuration that allows reuse of definitions without the need to copy repetitively from one config to another. That is why I suggested decoupling of the Inputs, Outputs, Snippets, and Routes from Configurations and allowing to build various configurations by including elements from the 4 collections. The idea is that the server knows what services are available on each client, and is at liberty (depending on business needs) to collect or stop collecting certain logs, route them to one output or to another and so forth all centrally from Graylog. At no point the server should be able to collect logs for which the client hasn't advertised (authorized by tags) The way it is now, if we want to gather logs of more services or less services from a specific client, we would need to modify the tags on the client (collector_sidecar.yml) which kind of defeats the purpose of centralized control. The way we got around this is really crude, we just added one tag per collector (host name) created a configuration on the server with a matching tag, and dumped the entire nxlog.conf into snippet, making sure we modified the output to use the id defined in the output. I'm certain we're not making the best use of graylog sidecar collector, as we have no modular control and all we have is managing the nxlog config remotely. The above is not to suggest that Graylog should head in that direction, but rather provide a one customer use case so that you and your team understands how people are using the product, and design the best product based on common patterns / traits in usage. One last note, if I want to force the sidecar to restart the nxlog service for whatever reasons (example in case it stopped sending data due to some broken network pipe) we have to edit the config and make dummy changes to force a reload. it would be convenient if there was a way from the UI to tell the collector to reload the service. Many thanks for not only providing such a wonderful product, but also actively responding to forum posts, supporting it and always looking for ways of improving it. You folks are amazing. Thanks -- You received this message because you are subscribed to the Google Groups "Graylog Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/graylog2/34474028-966a-4a7c-9aaf-0fbe5cc441c3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
