Hi, thanks for the feedback, that's very helpful for us. Otherwise we never know if the concepts are understood by the users or not. The current implementation is merging all configurations that are fetched throug the provided tags. So let's say that your sidecar starts with three tags, internally it's fetching all three configurations and merge them together to a single new one. So you end up with a configuration that includes all outputs/inputs/snippets from all three configurations. That said, the only limitation is in the web interface. Currently you can't use an output from one configuration with an input from another configuration. But that could be changed relatively easily.
Our goal is to find a solution that is intuitive and scales at the same time. When you think of not having 1-5 configurations but maybe a few dozens. Putting all inputs/output/snippets into one big bucket would be pretty confusing imo. Losing the overview means you never know what will actually be configured on the target system. So I am very open to better ideas but they need to solve the problem for bigger and smaller setups. Maybe there is some holy grail we missed till now. Cheers, Marius On 18 July 2016 at 19:02, 123Dev <[email protected]> wrote: > Agreed, the tag is confusing to us too. > On Graylog, if I have 3 configurations. > > - Config1 - tag1 > - Config2 - tag2 > - Config3 - tag3 > > On the collector side, I was wrongly expecting that if I set tag1 and > tag2, the client would get both configurations. > But that didn't work > > Because each configuration to be configured needs its own output, and the > generated nxlog.conf did not get the two outputs or the auto-generated two > routes. > > I think Inputs, Outputs, Snippets and even routes (which cannot be defined > now) need to be decoupled from a configuration and be allowed to be defined > independently each in its own collections (similar to how the rules are > done in pipelines) for convenience (you don't want to repeat for each > config) and functionality (see below the nxlog internal example) > Then a configuration can pull one or many of the above components from the > collections, and then applied to a collector. > > If we don't decouple, then if we want to have nxlog internal logs logged > to Graylog, we would need to define something like this in Snippets for > each config (repeated and modified to match the output id) > <Input internal> > Module im_internal > </Input> > > <Route internal> > Path internal => 977ad164136aa0330cf2b422 > </Route> > > > and if the client has multiple tags, would it get multiple copies? single > copy? which output? which route? > > Sorry if we're understanding this thing totally wrong. > > 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/0eb49603-18b4-4e1e-98f7-02ccfd35ef08%40googlegroups.com > <https://groups.google.com/d/msgid/graylog2/0eb49603-18b4-4e1e-98f7-02ccfd35ef08%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/CAMqbBbJK8TLr6JuwQUx-gj8UjDuwFrZ84O5UqRtAxb%2B5t--0NA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
