yeah, it does make sense, as long as everybody can work with a
subtree. Pretty sure ability to parse into a subtree would solve the
problem I have... (and probably other problems where people want
variables that are not part of the message).
erik
On 07/16/2013 12:11 AM, Rainer Gerhards wrote:
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.
_______________________________________________
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.
