[erlang-questions] [ANN] Lager - a new logging framework for Erlang/OTP

[Tim Watson]

On 21 July 2011 21:18, Max Lapshin <max.lapshin@REDACTED> wrote:
>>
>> I like the way you check the levels though -
>> https://github.com/basho/lager/blob/master/src/lager_console_backend.erl#L42
>> - this is cleaner than the boilerplate I ended up with in fastlog,
>> which checks the atoms for all the possible levels. I might steal
>> that. :)
>>
>
> I suppose it is a bad idea to filter logs in the single process. It
> seems a very good idea like in log4erl to
> compile module when reading configuration and filter messages _before_
> sending them to error_logger.
>
> It is better to filter with 24 cores, than with one =)
>

I don't agree that this is an either or thing. It is true that turning
on and off the levels at compilation time is clearly superior in terms
of performance, but it isn't much use when you're deployed in
production and wish to turn up (or down) the logging levels for a
temporary period. Filtering out certainly logging levels at compile
time is quite easy - tuning to get good performance at runtime without
sacrificing flexibility is harder. Besides, log4erl also supports
changing log levels on the appenders at runtime, so it is also doing
some work at runtime. Probably the most efficient way would be to
bucket the loggers according to all the levels they are enabled for,
which would carry a little time overhead in finding a logger (for a
given level) and a little space overhead in storing the buckets.

I do agree that doing as much work in the client as possible is good.
I would move the formatting work (which in fastlog is usually
undertaken by error_logger, although that can be overriden - to the
client process, but I have state associated with the individual
loggers. I've been thinking about having a single proc to hold all the
various states and having the parse_transform generate code that gets
the state back and doing the level checking and actually logging calls
in the client.

Currently fastlog attempts to do things in as light a fashion as
possible, as you can read about on the wiki:
https://github.com/hyperthunk/fastlog/wiki. I'm going to benchmark
before making any significant changes - perhaps the various authors of
logging frameworks could agree on a sensible set of benchmarks that we
could all aspire to?