From a9a6b803a60793d42a74e0f1693a7594dffb6bc3 Mon Sep 17 00:00:00 2001
From: Siri Hansen
It consists of two parts - the logger part and the - handler part. The logger will forward log events to one - or more handler(s).
+ handler part. The logger part forwards log events to + one or more handler(s).Filters can be added to the logger and to each +
Filters can be added to the logger part and to each handler. The filters decide if an event is to be forwarded or not, and they can also modify all parts of the log event.
@@ -121,10 +121,10 @@log(Log, Config) -> ok
- A handler is called by the logger backend after filtering on - logger level and on handler level for the handler which is - about to be called. The function call is done on the client - process, and it is up to the handler implementation if other +
The handler callback is called after filtering on logger + level and on handler level for the handler in + question. The function call is done on the client process, + and it is up to the handler implementation if other processes are to be involved or not.
Multiple instances of the same handler can be
@@ -134,7 +134,7 @@
Filters can be set on the logger or on a handler. Logger
+ Filters can be set on the logger part, or on a handler. Logger
filters are applied first, and if passed, the handler filters
for each handler are applied. The handler callback is only
called if all handler filters for the handler in question also
@@ -145,7 +145,7 @@
The configuration parameter The Logger can be configured either when the system starts through
{fun((Log,Extra) -> Log | stop | ignore), Extra}
Logger is best configured by using the configuration parameters
- of kernel. There are three possible configuration parameters:
+ of Kernel. There are four possible configuration parameters:
The
logger
+The application configuration parameter
Disable the default handler. This allows another application
to add its own default handler. See
Only one entry of this option is allowed.
Add a handler as if
It is allowed to have multiple entries of this option.
Add the specified
Only one entry of this option is allowed.
This option configures
It is allowed to have multiple entries of this option.
Examples:
Output logs into a the file "logs/erlang.log"
+Output logs into the file "logs/erlang.log"
[{kernel,
[{logger,
@@ -338,7 +344,6 @@
To use event handlers written for
-error_logger:add_report_handler/1,2.
-
- This will automatically start the
-#{level=>info,
- filter_default=>log,
- filters=>[]}.
-
- Note that this handler will ignore events that do not
- originate from the old
Also note that
The old
Calls
+ to
To get log events on the same format as produced
by
By default, all log events originating from within OTP, except the former so called "SASL reports", look the same as before.
By SASL reports we mean supervisor reports, crash reports and progress reports.
@@ -494,32 +493,63 @@ error_logger:add_report_handler/1,2. namedThe destination of these log events were configured by - environment variables for the SASL application.
+Due to the specific event handlers, the output format slightly differed from other log events.
As of OTP-21, the concept of SASL reports is removed, - meaning that the default behavior is as follows:
+ meaning that the default behaviour is as follows:If the old behavior is preferred, the kernel environment
- variable
If the old behaviour is preferred, the Kernel configuation
+ parameter
All SASL reports have a metadata
field
See the
To use event handlers written for
+error_logger:add_report_handler/1,2.
+
+ This will automatically start the
+#{level=>info,
+ filter_default=>log,
+ filters=>[]}.
+
+ Notice that this handler will ignore events that do not
+ originate from the old
Also notice that
Logger does, to a certain extent, check its input data before forwarding a log event to the handlers, but it does not evaluate conversion funs or check the validity of format strings and arguments. This means that any filter or handler must be careful when formatting the data of a log event, making sure that it does not crash due to bad input data or faulty callbacks.
-If a filter or handler still crashes, logger will remove the +
If a filter or handler still crashes, Logger will remove the
filter or handler in question from the configuration, and then
print a short error message on the console. A debug event
containing the crash reason and other details is also issued,
@@ -552,13 +582,13 @@ error_logger:add_report_handler/1,2.
When starting an erlang node, the default behavior is that all
+ When starting an erlang node, the default behaviour is that all
log events with level info and above are logged to the
console. In order to also log debug events, you can either
change the global log level to First, we add an instance of logger_std_h with
+ First, we add an instance of And finally, we need to make sure that the logger itself allows
+ And finally, we need to make sure that Logger itself allows
debug events. This can either be done by setting the global
- logger level:
@@ -575,9 +605,9 @@ ok
#Fun<erl_eval.12.98642416>
4> logger:add_handler_filter(debug_handler,allow_debug,{Fun,[]}).
ok
-
5> logger:set_logger_config(level,debug). ok@@ -599,21 +629,22 @@ adding_handler(logger:handler_id(),logger:config()) -> {ok,logger:config()} | {e removing_handler(logger:handler_id(),logger:config()) -> ok changing_config(logger:handler_id(),logger:config(),logger:config()) -> {ok,logger:config()} | {error,term()} -
When logger:add_handler(Id,Module,Config) is called, logger - will first call Module:adding_handler(Id,Config), and if it - returns {ok,NewConfig} the NewConfig is written to the +
When
A handler can be removed by calling - logger:remove_handler(Id). logger will call - Module:removing_handler(Id,Config), and then remove the handler's - configuration from the configuration database.
-When logger:set_handler_config is called, logger calls - Module:changing_config(Id,OldConfig,NewConfig). If this function - returns ok, the NewConfig is written to the configuration - database.
- -A simple handler which prints to the console could be
+
When
A simple handler that prints to the console could be implemented as follows:
-module(myhandler).
@@ -720,7 +751,7 @@ do_log(Fd,Log,#{formatter:={FModule,FConfig}}) ->
and as long as the length of the message queue is lower, all log
requests are handled asynchronously. This simply means that the
process sending the log request (by calling a log function in the
- logger API) does not wait for a response from the handler but
+ Logger API) does not wait for a response from the handler but
continues executing immediately after the request (i.e. it will not
be affected by the time it takes the handler to print to the log
device). If the message queue grows larger than this value, however,
@@ -876,7 +907,14 @@ logger:add_handler(my_disk_log_h, logger_disk_log_h,
See Also
- error_logger(3) ,
- SASL(6)
+
+ disk_log(3) ,
+ error_logger(3) ,
+ logger(3) ,
+ logger_disk_log_h(3) ,
+ logger_filters(3) ,
+ logger_formatter(3) ,
+ logger_std_h(3) ,
+ sasl(6)
--
cgit v1.2.3