Logging for the daemon

It seems like then we鈥檇 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
    鈥渕essage鈥 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
    鈥渕essage鈥 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
    鈥渕essage鈥 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鈥檇 be giving up on systemd/syslog etc. compatibility?

I don鈥檛 think my proposal excludes support for systemd/syslog. I just did not include it because I鈥檓 not convinced that the impact/effort ratio is good for this feature. I鈥檇 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鈥檇 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
    鈥渕essage鈥 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鈥檛. 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
> 鈥渕essage鈥 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鈥檓 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鈥檓 still don鈥檛 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鈥檛 actually feel strongly one way or the other, but I鈥檒l 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鈥檓 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鈥檛 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鈥檚 format, then the answer is that then the tooling works properly.

The landscape here isn鈥檛 that we鈥檙e 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鈥檙e writing to a user鈥檚 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鈥檇 be giving up on systemd/syslog etc. compatibility?

I don鈥檛 think my proposal excludes support for systemd/syslog. I just did not include it because I鈥檓 not convinced that the impact/effort ratio is good for this feature. I鈥檇 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鈥檇 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
    鈥渕essage鈥 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鈥檛 actually feel strongly one way or the other, but I鈥檒l 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鈥檓 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鈥檛 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鈥檚 format, then the answer is that then the tooling works properly.

The landscape here isn鈥檛 that we鈥檙e 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鈥檙e writing to a user鈥檚 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鈥檇 be giving up on systemd/syslog etc. compatibility?

I don鈥檛 think my proposal excludes support for systemd/syslog. I just did not include it because I鈥檓 not convinced that the impact/effort ratio is good for this feature. I鈥檇 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鈥檇 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
    鈥渕essage鈥 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.