<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - RFE: journald to accept custom fields"
href="https://bugs.freedesktop.org/show_bug.cgi?id=77879">77879</a>
</td>
</tr>
<tr>
<th>Assignee</th>
<td>systemd-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Summary</th>
<td>RFE: journald to accept custom fields
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>systemd-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Reporter</th>
<td>duncan@innes.net
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Other
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Component</th>
<td>general
</td>
</tr>
<tr>
<th>Product</th>
<td>systemd
</td>
</tr></table>
<p>
<div>
<pre>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</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>