I really can’t miss this opportunity to scream that Elixir logs have always been one of my biggest and most frequent rants. For all that is good about this language, logs are unforgivably horrendous

I’d love if unstructured logs did not exist, ever. There’s not a single good usecase where structured logs plus a report_cb doesn’t win. I always create structured logs with a report_cb that formatters can optionally call if they want to create a user-friendly string from the structure, noting, “user-friendly” is forever a subjective opinion and should therefore be strictly optional and never overriding the actual structure, in case someone else wants to format things differently. And even then, the “user-friendly” string should not replace the structured payload. But then I’ve seen many libraries that, as soon as they see a report_cb field, replace the entire structure with the value of that report_cb, so I can’t even safely add my own callbacks either.

I’d also be more than happy if Logger just did not exist at all, for once erlang’s :logger is better at about everything. For example, how the Logger is configured always bites me, it’s all :logger under the hood but all the configuration is slightly different so it always takes me several rounds to configure the right thing (one example, handlers other than the default are configured under the application and with a few keys being named differently).

If there’s only one thing I wish to put out there and for every one to take, ranting aside, is to use structured logging, not optionally, not sometimes, but as the only valid way. I’d even make it enforced by the library and fail compilation otherwise

PS: @PragTob has heard my rants so many times

Hmm, I admit I don’t have a lot of experience with Syslog 5424, but I think it’s a format, right? Just like GCP or Datadog json-based formats? In that case, it’s not really relevant here, since I’m not proposing a new export format, but rather a way to write logs that will better accommodate any format. In general case, a running app can have multiple logging handlers: a default handler with default terminal formatter, an additional handler with json format and another one that sends errors to Sentry over HTTP. Reports are equipped to work well with all of them.

I touched this topic at the end. Telemetry doesn’t really solve this particular problem. In your library, you still have a handler that calls Logger.log with dynamic message and metadata, which is ok, but not perfect. If users were to customize logs, they would have to basically throw away all your efforts and do the work themselves. Telemetry just makes it easier to do.

You could totally use reports in your handler and that would make your logs even better!