Emit notice logs

Questions / Help
, ,
1

I would like Logger.notice to emit notice logs instead of info

1 Like
2

There has been a lot of work on the Logger lately, later versions of Erlang and Elixir should also support more log levels. Erlang -- Logging it seems notice is supported.

So update to the latest elixir and erlang and hopefully you’ll solve your problem

3

Thanks,
currently I’m using

Erlang/OTP 24 [erts-12.0.3] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit]

IEx 1.13.0-dev (8161e43) (compiled with Erlang/OTP 22)
Interactive Elixir (1.13.0-dev) - press Ctrl+C to exit (type h() ENTER for help)

I see there’s an interesting PR here

But looking at the changes (in particular the levels documentation, I still read that the INFO level is used for info and notice
)

4

Having a fast check in the master branch I think the problems is around here

5

Riccardo’s colleague here :slight_smile:
Thanks for the answer!
However by the documentation (1.13-dev) we see that

Once initialized, the handler should be designed to handle the following events:

   * {level, group_leader, {Logger, message, timestamp, metadata}} where:
        * level is one of :debug, :info, :warn, or :error, as previously described (for compatibility with pre 1.10 backends the :notice will be translated to :info and all messages above :error will be translated to :error)

meaning that all levels different from :debug, :info, :warn, or :error are normalized before being sent to the handler.

So, technically you can use Logger.notice, but practically you will have only info using the default :console backend.

Seeing that the handle_event in log backends get an erl_level key I think it means we can use it in any custom log backend, but replicating the :console one and its optimizations just for aligning to Erlang’s log levels seems overkill.

Is there a reason those levels has been stripped down in Elixir? Seems to me that we could benefit from some more granularity, and from more integrated logs in the BEAM languages.

Thanks!

6

They have not been stripped down. Elixirs logger implementation is older than erlangs :logger, but since the latter was introduced there’s an ongoing effort to bring implementations closer together. So it’s a matter of elixirs logger levels not yet being expanded to fully support all the levels erlangs logger implementation supports.

1 Like
7

Ok, as an author of Elixir’s and Erlang’s loggers integration I think I need to step up and explain stuff a little.

Yes, this reason is 1 in front of Elixir version. We cannot introduce breaking changes to set of standard applications before we reach Elixir 2 (and that is not happening any time soon). Reason why that would be a breaking change is simple - Elixir’s Logger’s backends could treat the type spec of the callback as a source of truth, so they could just define a way to translate “old” 4 levels into string and just ignore other possibilities like that:

def level_name(:debug), do: "DEBUG"
def level_name(:info), do: "INFORMATIONAL"
def level_name(:warn), do: "WARNING"
def level_name(:error), do: "ERROR

If we would pass the levels “as is” to the Elixir’s Logger’s backends then it would cause exceptions for “new” levels.

So there is simply no way to introduce support for what you want in a reasonable way. In theory we could add metadata key, but that also could cause collisions with user-defined metadata.

If you want to use all Erlang capabilities like all levels then you need to use Erlang’s Logger’s handlers, which are a little bit harder to write properly, but give you much more features and possibilities.

1 Like
8

this fixes my problem (and possibly breaks the rest of the world?)

9

Thank you! I understand now what is breaking in introducing such kind of a change.
It is indeed a simple, yet so heavily impacting thing and I hope this discussion will be useful to others wondering the same!
Thank you again for stepping in, we’re currently trying to understand if there is some way we can make this work out for us, will update the thread if we find a reasonable solution :slight_smile:

1 Like
10

I love how this story ends :slight_smile:

Awesome work @riccardomanfrin @zoten <3 <3

1 Like