<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - RFE: support extra fields in systemd-journal-upload" href="https://bugs.freedesktop.org/show_bug.cgi?id=89102#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - RFE: support extra fields in systemd-journal-upload" href="https://bugs.freedesktop.org/show_bug.cgi?id=89102">bug 89102</a> from <a class="email" href="mailto:duncan@innes.net" title="Duncan Innes <duncan@innes.net>"> Duncan Innes</a> <pre>(In reply to Zbigniew Jedrzejewski-Szmek from <a href="show_bug.cgi?id=89102#c1">comment #1</a>) > Your request should be split into two or ever three parts. > Sure - no problem doing this. > > First, adding custom fields to the log event stream. This has been requested > before, and should be done. > Could you point me to the request. I did search for similar, but turned up nothing. If there's already an RFE, I'll just track that one. > > Second, we might consider adding fields from /usr/lib/os-release > automatically, things like description of the OS like CPE_NAME, BUILD_ID, > and stuff from /etc/machine-info, DEPLOYMENT, LOCATION, CHASSIS. I can see > how this would be useful, but I'm not sure if it is worth the overhead. > Sure - I didn't realise /etc/machine-info was able to store user data. It's limited to PRETTY_HOSTNAME, ICON_NAME, CHASSIS, and DEPLOYMENT though. I think it would be a big benefit to large estates to be able to specify custom fields as well here. Would the overhead not be limited to reading this file at s-j-upload startup, then inserting the data into each exported entry? A flag on s-j-upload command could indicate whether or not to add extra fields. Default to NO. User then chooses whether to increase system load & network traffic by adding extra data. I might be over-simplifying this though. > > Third, JSON format. I'm not sure why you would s-j-upload specifically to > support JSON. journalctl -o json/json-pretty gives you JSON already. > s-j-upload is really a tool to communicate with s-j-remote, and the binary > and HTTP protocols it already has should be enough. I'll leave this ticket for the supporting of extra fields in the log data. I'll open a separate ticket for adding the export in JSON format.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>