William Heinbockel wheinbockel@gmail.com writes:
I propose we roughly follow the proposal from Balazs:
- Core Fields -- flat names that are defined by lumberjack/CEE. These
should encompass the minimal set of fields that are commonly used.
- 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.