William Heinbockel <wheinbockel(a)gmail.com> writes:
I propose we roughly follow the proposal from Balazs:
1. Core Fields -- flat names that are defined by lumberjack/CEE. These
should encompass the minimal set of fields that are commonly used.
2. Extended Fields -- additional fields are either tied to a specific
product/application or a functional product group (anti-virus,
firewalls, etc.)
We should focus on scoping and defining #1, probably combining the
libumberlog, patterndb, liblognorm, RFC5424/IANA fields. Maybe the
best place to start is with the `auditd` list
<
http://people.redhat.com/sgrubb/audit/audit-parse.txt> and abstract
linux-specific names to be more generally applicable.
Another contender to keep in mind is probably the journal - they have a
few fields of their own (some of which the others, syslog-ng, rsyslog &
nxlog could implement aswell, if so need be) that might worth being
considered.
Lennart also expressed interest in emitting CEE-enhanced JSON from
journal, as long as there's a clear algorithm to translate
journal-internal names to CEE (but that's a future topic), and I'm
fairly sure they'd be interested in the extended fields too.
For #2, we need to figure out how these work. I vote that the
structure should infer the namespace and the namespace should either
be unique to the vendor/product or developed by the community.
{"red_hat":{"auditd":{"time":"..."}}} would work,
or collapsed to
{"red_hat|auditd|time":"..."}
(feel free to substitute divisive char: !/.:|)
Definitely the former. I imagine most consumers will use dot-notation to
reach into nested structures, and it is VERY unintuitive when you have
"foo.bar.baz" and "foo|bar|baz.quux" too. (Which we will, since
extensions are - I hope - allowed to nest)
We need some way to distinguish vendor/product namespaces from
organization/functional ones.
Perhaps put vendor extensions under a "vendor" or "org" key?
{"org":{"redhat":{"foo":"bar"}}}
Perhaps a bit verbose, but it's simple and crystal clear, in my opinion.
--
|8]