[systemd-bugs] [Bug 77879] New: RFE: journald to accept custom fields

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=77879

          Priority: medium
            Bug ID: 77879
          Assignee: systemd-bugs at lists.freedesktop.org
           Summary: RFE: journald to accept custom fields
        QA Contact: systemd-bugs at lists.freedesktop.org
          Severity: normal
    Classification: Unclassified
                OS: All
          Reporter: duncan at innes.net
          Hardware: Other
            Status: NEW
           Version: unspecified
         Component: general
           Product: systemd

Add the ability for journald to create custom fields & values in addition to
simply storing the message text.

i.e. iptables current log output:

"MESSAGE" : "IN= OUT=eth0 SRC=A.B.C.D DST=W.X.Y.Z LEN=64 TOS=0x00 PREC=0x00
TTL=64 ID=23937 DF PROTO=UDP SPT=52894 DPT=53 LEN=44"

could be expanded to:

"MESSAGE" : "IN= OUT=eth0 SRC=A.B.C.D DST=W.X.Y.Z LEN=64 TOS=0x00 PREC=0x00
TTL=64 ID=23937 DF PROTO=UDP SPT=52894 DPT=53 LEN=44",
"IPTABLES_OUT" : "eth0",
"IPTABLES_SRC" : "A.B.C.D",
"IPTABLES_DST" : "W.X.Y.Z",
"IPTABLES_LEN" : "64",
"IPTABLES_TOS" : "0x00",
"IPTABLES_PREC" : "0x00",
"IPTABLES_TTL" : "64",
"IPTABLES_ID" : "23937",
"IPTABLES_PROTO" : "UDP",
"IPTABLES_SPT" : "52894",
"IPTABLES_DPT" : "53"

The storage of these custom fields would be entirely up to the logging source. 
If iptables does not have the ability to write these extra fields, the standard
log message would still be used.

The naming of the custom fields would be up to the various logging sources.

Reason:

Rich searching of log data without having to parse MESSAGE fields.  Especially
when logs are pushed to a central server mechanism.  Some logged data
(iptables, httpd, audit, etc) lends itself entirely to this extra granularity,
but it could not be forced on all data.

In estates with hundreds or thousands of servers sending logs to a central
store, the ability to quickly search all logs for "AUDIT_TYPE" :
"authentication failure" and "AUDIT_USER" : "vulnerable" will show attempts to
brute force a user password across the whole estate (I know there are better
ways of detecting this specific example, but it's the best I can come up with
right now).

While these fields can be parsed out of the message line at a later point, it
would add value to the data to have the logging application separate out the
data rather than relying on grok parsing (or other) at a later point, which may
not capture all possibilities.

Thanks

Duncan

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20140424/cade72ff/attachment-0001.html>