Thanks for the awesome feedback, we will go through your use case and see if we can find a solution that solves it in a better way. There are a lot of potential ways to go from here so I guess I have to collect some more data and meditate a little bit about it :) But this is really valuable feedback for us. In many cases we are simply lacking real world examples, much appreciated!
Cheers, Marius On 19 July 2016 at 20:03, 123Dev <[email protected]> wrote: > 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 > <https://groups.google.com/d/msgid/graylog2/34474028-966a-4a7c-9aaf-0fbe5cc441c3%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Developer Tel.: +49 (0)40 609 452 077 Fax.: +49 (0)40 609 452 078 TORCH GmbH - A Graylog Company Poolstraße 21 20335 Hamburg Germany https://www.graylog.com <https://www.torch.sh/> Commercial Reg. (Registergericht): Amtsgericht Hamburg, HRB 125175 Geschäftsführer: Lennart Koopmann (CEO) -- 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/CAMqbBbJi7k3UuQ_Yqy1Q%3DLz%3DmpVjvNfzwcgdtMEiH_cpC0Ye_A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
