Bug 89102

Your request should be split into two or ever three parts.

First, adding custom fields to the log event stream. This has been requested before, and should be done.

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.

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.

(In reply to Zbigniew Jedrzejewski-Szmek from comment #1)
> 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.

(In reply to Duncan Innes from comment #2)
> 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.
Might now have been public. Chances are that it'll get implemented in
a week or two.

> > 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.
I'm thinking of something like this in /etc/systemd/journal-upload.conf:
SendFields=DEPLOYMENT CPE_NAME CUSTOM1=value
where fields without a value specified would be extracted from machine-info
and os-release, and fields with a value would be send with the given value.

(In reply to Zbigniew Jedrzejewski-Szmek from comment #3)
> I'm thinking of something like this in /etc/systemd/journal-upload.conf:
> SendFields=DEPLOYMENT CPE_NAME CUSTOM1=value
> where fields without a value specified would be extracted from machine-info
> and os-release, and fields with a value would be send with the given value.

Sounds ideal to me.  Can't see the need for too many custom fields.
Would it be acceptable to enter custom fields in /etc/machine-info?  Then the fields could simply be referenced in your config file.