Future of Logger in Elixir

Chat / Discussions
, ,
22

This is my mental model of current state of the loggers:

  1. Logger handlers is the main interface for logging
  2. Logger handlers are recommended to support something called “overload protection”
  3. The default :logger_std_h handler does have an overload protection
  4. If you want to write a custom handler, you’ll have to implement overload protection, like for example, Sentry handler does.
  5. LoggerBackends is a logger handler which allows you to write logger backends which is a concept unique to this package. Custom backends won’t need overload protection as they are not logger handlers.

So my rule of thumb is as follow: logger handlers that implement overload protection can be all used as handlers alongside each other:

config :my_app, :logger, [
  {:handler, :file_log, :logger_std_h, ...},
  {:handler, :sentry, Sentry.LoggerHandler, ...}
]

Whenever you want a custom logger but don’t want to implement overload protection, you can take advantage of LoggerBackends and write a custom logger backend instead.

In reality, I’ve yet to find myself writing a custom handler as the built-in :logger_std_h in combination with filters and formatters is very very flexible. So flexible, in fact, that LoggerJSON project was completely rewritten from being a logger backend to being a formatter.

5 Likes