It seems like then we’d be giving up on systemd/syslog etc. compatibility?
···
On Mon, Feb 4, 2019 at 11:32 AM Thomas Scholtes thomas@monadic.xyz wrote:
This is a list of things I think the logging system for the daemon should support
- option to output structured logs that are easy to parse, process, and well understood by other software. JSON and logfmt are good options.
- stable, human-readable identifier for log entries. Meaning that logging code at a specific location should always use the same static
“message” and every context specific data should be provided in extra fields. This makes it easier to filter and analyze logs
- Pretty output that is easy to parse by humans for development. (Using colors, layout, etc.)
Alfredo created a nice PR for oscoin where he motivated and followed these principles.
This is a list of things I think the logging system for the daemon should support
- option to output structured logs that are easy to parse, process, and well understood by other software. JSON and logfmt are good options.
- stable, human-readable identifier for log entries. Meaning that logging code at a specific location should always use the same static
“message” and every context specific data should be provided in extra fields. This makes it easier to filter and analyze logs
- Pretty output that is easy to parse by humans for development. (Using colors, layout, etc.)
Alfredo created a nice PR for oscoin where he motivated and followed these principles.
Do any of you have a favoured lib at this point?
···
On Monday, February 4, 2019 at 10:32:53 AM UTC, Thomas Scholtes wrote:
This is a list of things I think the logging system for the daemon should support
- option to output structured logs that are easy to parse, process, and well understood by other software. JSON and logfmt are good options.
- stable, human-readable identifier for log entries. Meaning that logging code at a specific location should always use the same static
“message” and every context specific data should be provided in extra fields. This makes it easier to filter and analyze logs
- Pretty output that is easy to parse by humans for development. (Using colors, layout, etc.)
Alfredo created a nice PR for oscoin where he motivated and followed these principles.
It seems like then we’d be giving up on systemd/syslog etc. compatibility?
I don’t think my proposal excludes support for systemd/syslog. I just did not include it because I’m not convinced that the impact/effort ratio is good for this feature. I’d like to know what the benefit of systemd/syslog support over stdout log support is and who will benefit from that.
···
On Mon, Feb 4, 2019 at 1:10 PM Julian Arni julian@monadic.xyz wrote:
It seems like then we’d be giving up on systemd/syslog etc. compatibility?
On Mon, Feb 4, 2019 at 11:32 AM Thomas Scholtes thomas@monadic.xyz wrote:
This is a list of things I think the logging system for the daemon should support
- option to output structured logs that are easy to parse, process, and well understood by other software. JSON and logfmt are good options.
- stable, human-readable identifier for log entries. Meaning that logging code at a specific location should always use the same static
“message” and every context specific data should be provided in extra fields. This makes it easier to filter and analyze logs
- Pretty output that is easy to parse by humans for development. (Using colors, layout, etc.)
Alfredo created a nice PR for oscoin where he motivated and followed these principles.
Do any of you have a favoured lib at this point?
I don’t. It should just be simple and cover the use cases I outlined.
···
Am Donnerstag, den 07.03.2019, 08:26 -0800 schrieb james@monadic.xyz:
On Monday, February 4, 2019 at 10:32:53 AM UTC, Thomas Scholtes wrote:
> This is a list of things I think the logging system for the daemon should support
> option to output structured logs that are easy to parse, process, and well understood
> by other software. JSON and logfmt are good options.
> stable, human-readable identifier for log entries. Meaning that logging code at a
> specific location should always use the same static
> “message” and every context specific data should be provided in extra fields. This
> makes it easier to filter and analyze logs
> Pretty output that is easy to parse by humans for development. (Using colors, layout,
> etc.)
> Alfredo created a nice PR for oscoin where he motivated and followed these principles.
>
I’m not suggesting to provide the capability to log to a file. I think the daemon should just log to stdout. As you mentioned this is what users expect and works well with systemd. If the effort to have syslog/journald as an additional sink is small then we might want to include it. I’m still don’t think that the benefit of that is big
···
On Mon, Feb 4, 2019 at 1:41 PM Julian Arni julian@monadic.xyz wrote:
I don’t actually feel strongly one way or the other, but I’ll still answer.
Many libraries (such as logging-facade/logging-facade-syslog, or katip/katip-syslog, the latter written by Alfredo :)) make the effort of logging in a syslog-appropriate format close to zero.
I’m not sure what exactly is being discussed. If the question is whether to log to file or to the journal, the big advantage is that we don’t have to do log rotation (we can just output to stdout and systemd at least handles the rest), and that users often first expect to see messages in journalctl. If the question is, given that we are sending to journald, why keep to it’s format, then the answer is that then the tooling works properly.
The landscape here isn’t that we’re sending our own server logs, in which case we are both reader and writer and can decide the format in a completely ad-hoc way, but that we’re writing to a user’s computer, and any new step (e.g., to grep for only high-priority message, install jq and do xyz) will be an annoyance to users.
That said, I agree the syslog format kinda sucks.
On Mon, Feb 4, 2019 at 1:19 PM Thomas Scholtes thomas@monadic.xyz wrote:
It seems like then we’d be giving up on systemd/syslog etc. compatibility?
I don’t think my proposal excludes support for systemd/syslog. I just did not include it because I’m not convinced that the impact/effort ratio is good for this feature. I’d like to know what the benefit of systemd/syslog support over stdout log support is and who will benefit from that.
On Mon, Feb 4, 2019 at 1:10 PM Julian Arni julian@monadic.xyz wrote:
It seems like then we’d be giving up on systemd/syslog etc. compatibility?
On Mon, Feb 4, 2019 at 11:32 AM Thomas Scholtes thomas@monadic.xyz wrote:
This is a list of things I think the logging system for the daemon should support
- option to output structured logs that are easy to parse, process, and well understood by other software. JSON and logfmt are good options.
- stable, human-readable identifier for log entries. Meaning that logging code at a specific location should always use the same static
“message” and every context specific data should be provided in extra fields. This makes it easier to filter and analyze logs
- Pretty output that is easy to parse by humans for development. (Using colors, layout, etc.)
Alfredo created a nice PR for oscoin where he motivated and followed these principles.
I don’t actually feel strongly one way or the other, but I’ll still answer.
Many libraries (such as logging-facade/logging-facade-syslog, or katip/katip-syslog, the latter written by Alfredo :)) make the effort of logging in a syslog-appropriate format close to zero.
I’m not sure what exactly is being discussed. If the question is whether to log to file or to the journal, the big advantage is that we don’t have to do log rotation (we can just output to stdout and systemd at least handles the rest), and that users often first expect to see messages in journalctl. If the question is, given that we are sending to journald, why keep to it’s format, then the answer is that then the tooling works properly.
The landscape here isn’t that we’re sending our own server logs, in which case we are both reader and writer and can decide the format in a completely ad-hoc way, but that we’re writing to a user’s computer, and any new step (e.g., to grep for only high-priority message, install jq and do xyz) will be an annoyance to users.
That said, I agree the syslog format kinda sucks.
···
On Mon, Feb 4, 2019 at 1:19 PM Thomas Scholtes thomas@monadic.xyz wrote:
It seems like then we’d be giving up on systemd/syslog etc. compatibility?
I don’t think my proposal excludes support for systemd/syslog. I just did not include it because I’m not convinced that the impact/effort ratio is good for this feature. I’d like to know what the benefit of systemd/syslog support over stdout log support is and who will benefit from that.
On Mon, Feb 4, 2019 at 1:10 PM Julian Arni julian@monadic.xyz wrote:
It seems like then we’d be giving up on systemd/syslog etc. compatibility?
On Mon, Feb 4, 2019 at 11:32 AM Thomas Scholtes thomas@monadic.xyz wrote:
This is a list of things I think the logging system for the daemon should support
- option to output structured logs that are easy to parse, process, and well understood by other software. JSON and logfmt are good options.
- stable, human-readable identifier for log entries. Meaning that logging code at a specific location should always use the same static
“message” and every context specific data should be provided in extra fields. This makes it easier to filter and analyze logs
- Pretty output that is easy to parse by humans for development. (Using colors, layout, etc.)
Alfredo created a nice PR for oscoin where he motivated and followed these principles.