It's the least we could do Marius when we are the benefactors of an awesome product with an amazing development / support teams.
Can't thanks enough. Cheers On Wednesday, July 20, 2016 at 10:31:00 AM UTC-4, Marius Sturm wrote: > > 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] <javascript:>> > 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] <javascript:>. >> 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/ab74d1aa-594a-4ccd-ac1a-d9adae3801ad%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
