Future of Logger in Elixir

[chulkilee]

@hauleth

Unfortunately it is lagging behind Erlang’s logger API which provides structured logging.

I see Elixir Logger expects chardata while Erlang logger can accept a map src.

This can be improved in future version of Elixir requiring OTP > 21, without breaking interface, instead of taking chardata_or_fun type. This is actually in Support Erlang 21 new features · Issue #6611 · elixir-lang/elixir · GitHub - “Unify :logger and Logger metadata”

@hauleth

And metadata field in log entry is completely different from actual log entry. For example request duration belongs to log main value, not its metadata. And in structured logging you can make explicit distinction which is what.

I see your point, but why not using metadata as your “additional data” attached to keep the data? And actually there are good feature of Logger metadata - living in a process - so you can just set persistent “main log value” in metadata, and keep using it. Do we need to reinvent this behavior? Maybe. But why don’t we leverage existing metadata?

Logger.metadata(transaction_id: txid)
Logger.debug("starting", foo: 1, bar: 2)
# ....
Logger.info("completed")

If we want side-effect free logging… then we need to pass everything. That works, but I don’t think it worths to do that. We set Logger metadata explicilty for logger (e.g. not “misusing” process dictionary… oh I’m breaking the rule #1)

log_common_metadata = [transaction_id: txid]
Logger.debug([message: "starting", foo: 1, bar: 2] ++ log_common_metadata)
Logger.info([{:message, "completed"} | log_common_metadata)

@hauleth

Not that different. telemetry is just additional logging library that is meant to log only metrics, but these two are interconnected. So for me there is not that much difference between logger 's structured logging feature and telemetry .

Logging and collecting metric has some common goals, but logger and telemtry is different mechanism. logger creates log events on caller side while telemtry implements dispatching mechanism to allow others know when a specific event happens. The can serve the same purpose - by using telemtry to trigger events (via :telemetry.execute/3) for any events requiring logs, and writing telemtry handler to subscribe those events, and just “print log message”. It works, and I see there are certain cases it’s better to use define telemtry events. Oh, we may define a event called “logevent” and then log backend subscribing those events. Oh, then we basically use telemtry as message queue