On Wed, 22 Aug 2012, Miloslav Trmac wrote:
Hello,
----- Original Message -----
In
rsyslog-6.4.0/plugins/ommongodb/README I found the line:
"Note: currently templates are not supported. Ommongodb will pick a default
schema and use the message object content for that (templateless)."
I happen to be currently working on this, see the ommongodb branch at
http://fedorapeople.org/cgit/mitr/public_git/rsyslog.git/ . I'd be interested
to hear whether the proposed approach works for you. More detailed description
is below.
Mirek
Some questions:
- I this approach reasonable? The problem with this is that the "field"
treatment of the template is so different from other cases; there is a
precedent with omoracledb's use of ...AS_ARRAY, but that's only a single
module.
Why have your own template engine instead of using the normal rsyslog
template engine?
The users are already familar with, and that gets extended to cover new
things without you having to duplicate the effort. This includes the
ability to dump all properties out as JSON and is going to include
abilities to modify the fields and leave some out of the output in the
future (as part of the entire lumberjack related effort)
- What to do about non-string values? mongodb recognizes different
types, and it would be good to use the native one (so that numbers
instead of strings could be compared - note that there is no automatic
type conversion when comparing different types in mongodb). Non-string
types can be handled on output (by adding
"format-as-int"/"format-as-date" options), but AFAICS on input /
mmjsonparse everything is treated as strings. Is it at this point
realistic to think about preserving the type of data as presented on
input while reformatting it (e.g. by using mmjsonparse, and a template
with $!all-json and some of the above-mentioned field "edits")? Or is
rsyslog so fundamentally based on strings that this would take too much
work? (There is always the option to preserve types simply by treating
the JSON as unmodified plaintext).
Remember that the input to rsyslog is strings to start with (with the
exception of internally generated metadata). To get it to be anything
other than a string is going to require converting it. There's nothing
preventing you from getting a JSON string from rsyslog and optimizing it
by converting the data from strings to a more compact format for storage.
Output modules to transport the data from system to system via JSON will
be doing exactly the same thing.
David Lang
_______________________________________________
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
