Before we dive too deep into which fields to support and how to name
them, we should first discuss the structure and organization of the
names.
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.
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: !/.:|)
The functional product categories should be related to an
organizational entity -- lumberjack, cee, IANA, etc.
We need some way to distinguish vendor/product namespaces from
organization/functional ones.