On Tue, Jul 16, 2013 at 9:09 AM, Rainer Gerhards <[email protected]>wrote:
> On Tue, Jul 16, 2013 at 9:06 AM, Erik Steffl <[email protected]> wrote: > >> On 07/15/2013 11:52 PM, Rainer Gerhards wrote: >> >>> On Tue, Jul 16, 2013 at 8:47 AM, Rainer Gerhards >>> <[email protected]>**wrote: >>> >>> >>>> >>>> yup, but in a different flavor: I think everyone can pretend things if >>>> he >>>> is able to reconfigure rsyslog. I think the point here is to provide the >>>> necessary facility to rightful users. And if e.g. mmjsonparse always >>>> parses >>>> into the root, you have essentially lost, you can't properly work with >>>> subtrees. I remember we discussed adding a capability to write to >>>> different >>>> subtrees, not sure though if we did implement it. >>>> >>>> >>> I just checked: unfortunately we did not yet do that. >>> >> >> that would solve my problem I think, if the parser would put data into >> a user specified subtree instead of root of json. >> >> We are using the dev version (latest packages from adiscon ubuntu >> repository), just about to release it to production (not a huge one, few >> servers, maybe a million messages per day). Would definitely at least test >> the version with parsing into a subtree. >> >> curious: why all the discussions only talk about one json tree. Why not >> have several named json trees? > > > For the same reason you only have one file system tree: the tree is a > hierarchical namespace, so why add another namespace on top of it? > > >> Then whenever referring to json one would specify which tree to use. > > > You do - it's the top level > > !usr!xxx has all usr variables > !msg!xxx has all msg variables > !yyy!xxx has all yyy variables > > see the different trees? > > >> Technically it's no different than having one tree > > I forgot: it's a *big* difference: you need an additonal resolve to handle the various top level trees - with all support infrastructure like hash tables to keep their names etc. All solved without cost and complexity when a single name space is used. Rainer > but mentally it might be easier to manage (and to keep things separated - >> incoming parsed message, outgoing message, user specified data etc.) >> >> > again: think filesystem (or dns name or... - it's just the regular method > of choice). > > I'll see if I can quickly add that capability to mmjsonparse. Can you > confirm this is the parser you need? > > Rainer > >> thanks! >> >> erik >> >> ______________________________**_________________ >> rsyslog mailing list >> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog> >> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.com/professional-services/> >> What's up with rsyslog? Follow https://twitter.com/rgerhards >> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad >> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you >> DON'T LIKE THAT. >> > > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
