From 8aa64c90ddd20ec0ca8cc5fe92a6124324c51da5 Mon Sep 17 00:00:00 2001
From: Siri Hansen When a log macro is used, Logger also inserts location
information: A timestamp produced
- with
In OTP-21, a new API for logging was added to Erlang/OTP. The
old
See
The Erlang error logger is an event manager (see
Initially,
Also the SASL application, if started, adds its own event
- handler, which by default writes supervisor, crash, and progress
- reports to the terminal. See
-
It is recommended that user-defined applications report
- errors through the error logger to get uniform reports.
- User-defined event handlers can be added to handle application-specific
- events, see
-
Error logger is no longer started by default, but is
+ automatically started when an event handler is added
+ with
User-defined event handlers can be added to handle application-specific + events.
+Existing event handlers provided by STDLIB and SASL are still + available, but are no longer used by OTP.
Warning events were introduced in Erlang/OTP R9C and are enabled by default as from Erlang/OTP 18.0. To retain backwards compatibility with existing user-defined event handlers, the warning events can be @@ -191,7 +181,7 @@ ok
The
The default value is
See chapter If set, no
-
The following application environment variables can still be +
The following application configuration parameters can still be set, but they will only be used if the corresponding new logger variables are not set.
- This module is the main logger API. It contains functions that allow
- application to use a single log API and the system to manage those log
- events independently. To log events the logger
-
?LOG_ERROR("error happened because: ~p",[Reason]). %% With macro
logger:error("error happened because: ~p",[Reason]). %% Without macro
- This log event will then be sent to the configured log handlers which - by default means that it will be printed to the console. If you want +
This log event is then sent to the configured log handlers which
+ by default means that it is be printed to the console. If you want
your systems logs to be printed to a file instead of the console you
- have to configure the default handler to do so. The simplest way is
+ must configure the default handler to do so. The simplest way is
to include the following in your
[{kernel,
@@ -63,7 +91,7 @@ logger:error("error happened because: ~p",[Reason]). %% Without macro
- how to use the API,
see
the User's Guide .
- - how to configure logger,
+
- how to configure Logger,
see the
Configuration
section in the User's Guide.
- the convinience macros in logger.hrl,
@@ -129,8 +157,8 @@ logger:error("error happened because: ~p",[Reason]). %% Without macro
update_process_metadata/1
Logger merges all the metadata maps before forwarding the log event to the handlers. If the same keys occur, values - from the log call overwrites process metadata, which in turn - overwrites values set by Logger.
+ from the log call overwrite process metadata, which in turn + overwrite values set by Logger.A filter which can be installed for logger or for a handler.
+A filter which can be installed for the logger part of + Logger, or for a handler.
All macros expand to a call to logger, where
All macros expand to a call to Logger, where
Lookup the current configuration for logger.
+Look up the current configuration for the logger part of + Logger.
Lookup the current configuration for the given handler.
+Look up the current configuration for the given handler.
Same as
Display or return all current logger configuration.
+Display or return all current Logger configurations.
Return the pretty printed current logger configuration +
Return the pretty printed current Logger configuration as iodata.
Return the current logger configuration as a term. The - format of this term may change inbetween releases. For a +
Return the current Logger configuration as a term. The
+ format of this term may change between releases. For a
stable format use
The same as calling
Pretty print all the current logger configuration to +
Pretty print all the current Logger configuration to standard out. Example:
logger:i(print).
Current logger configuration:
@@ -423,9 +455,9 @@ Current logger configuration:
- Add a filter to the logger.
+ Add a filter to the logger part of Logger.
- Add a filter to the logger.
+ Add a filter to the logger part of Logger.
The filter fun is called with the log event as the first
parameter, and the specified filter_args() as the
second parameter.
@@ -436,8 +468,8 @@ Current logger configuration:
-
The filter passed. The next logger filter, if
any, is applied. If no more logger filters exist, the
- log event is forwarded to the handler part of the
- logger, where handler filters are applied.
+ log event is forwarded to the handler part of Logger,
+ where handler filters are applied.
stop
-
@@ -449,9 +481,9 @@ Current logger configuration:
The filter has no knowledge of the log event. The next
logger filter, if any, is applied. If no more logger
filters exist, the value of the filter_default
- configuration parameter for the logger specifies if the
- log event shall be discarded or forwarded to the handler
- part.
+ configuration parameter for the logger part specifies if
+ the log event shall be discarded or forwarded to the
+ handler part.
See section Remove the filter identified
- by
Set the log level for the
specified
The log level for a module overrides the global log level - of the logger for log event originating from the module in + of Logger for log events originating from the module in question. Notice, however, that it does not override the level configuration for any handler.
-For example: Assume that the global log level for the
- logger is
For example: Assume that the global log level for Logger
+ is
With this configuration, no debug messages will be logged, since they are all stopped by the global log level.
-If the level for
If the level for
Debug events from other modules are still not logged.
-To change the global log level for the logger, use +
To change the global log level for Logger, use
To change the log level for a handler, use @@ -572,9 +604,10 @@ Current logger configuration:
The originating module for a log event is only detected
if
Reads the application configuration parameter
This function should be used by custom logger handlers to make +
This function should be used by custom Logger handlers to make
configuration consistent no matter which handler the system uses.
- Normal usage to to add a call to
-behaviour(application).
start(_, []) ->
@@ -616,19 +651,20 @@ start(_, []) ->
{ok, Pid, []};
Error -> Error
end.
- This will read the
This reads the
If the handler is meant to replace the default handler the kernels
- default handlers have to be disabled before the new handler is added.
- A
If the handler is meant to replace the default handler, the Kernel's
+ default handler have to be disabled before the new handler is added.
+ A
[{kernel,
[{logger,
- %% Disable the default kernel handler
+ %% Disable the default Kernel handler
[{handler,default,undefined}]}]},
{my_app,
[{logger,
@@ -640,10 +676,10 @@ start(_, []) ->
- Set configuration data for the logger.
+ Set configuration data for the logger part of Logger.
- Set configuration data for the logger. This overwrites the
- current logger configuration.
+ Set configuration data for the logger part of Logger. This
+ overwrites the current logger configuration.
To modify the existing configuration,
use
update_logger_config/1 , or, if a more
@@ -658,21 +694,25 @@ start(_, []) ->
- Add or update configuration data for the logger.
+ Add or update configuration data for the logger part
+ of Logger.
- Add or update configuration data for the logger. If the
- given Key already exists, its associated
- value will be changed to Value . If it
- does not exist, it will be added.
+ Add or update configuration data for the logger part of
+ Logger. If the given Key already exists,
+ its associated value will be changed
+ to Value . If it does not exist, it will
+ be added.
- Update configuration data for the logger.
+ Update configuration data for the logger part of
+ Logger.
- Update configuration data for the logger. This function
- behaves as if it was implemented as follows:
+ Update configuration data for the logger part of
+ Logger. This function behaves as if it was implemented as
+ follows:
{ok,Old} = logger:get_logger_config(),
logger:set_logger_config(maps:merge(Old,Config)).
@@ -697,7 +737,7 @@ logger:set_logger_config(maps:merge(Old,Config)).
, then do the merge before writing the new
configuration back with this function.
If a key is removed compared to the current configuration,
- and the key is know by Logger, the default value is used. If
+ and the key is known by Logger, the default value is used. If
it is a custom key, then it is up to the handler
implementation if the value is removed or a default value is
inserted.
diff --git a/lib/kernel/doc/src/logger_chapter.xml b/lib/kernel/doc/src/logger_chapter.xml
index 4232429589..21b460e72a 100644
--- a/lib/kernel/doc/src/logger_chapter.xml
+++ b/lib/kernel/doc/src/logger_chapter.xml
@@ -36,14 +36,14 @@
this API can be used as is, or it can be customized to suite
specific needs.
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).
Conceptual overview
- 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 @@
Filter
-
-
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 @@
{fun((Log,Extra) -> Log | stop | ignore), Extra}
The configuration parameter filter_default
- specifies the behavior if all filters return ignore .
+ specifies the behaviour if all filters return ignore .
filter_default is by default set to log .
The Extra parameter may contain any data that the
@@ -250,52 +250,58 @@
Logger can be configured either when the system starts through
configuration parameters ,
- or at run-time by using the logger
+ or at run-time by using the logger(3)
API. The recommended approach is to do the initial configuration in
the sys.config file and then use the API when some configuration
- has to be changed at run-time, such as the logging level.
+ has to be changed at run-time, such as the log level.
- Application configuration parameters
+ Kernel Configuration Parameters
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:
logger ,
logger_level ,
logger_sasl_compatible and
logger_log_progress .
- logger_level, logger_sasl_compatible and logger_log_progress are described in the
+ logger_level , logger_sasl_compatible and logger_log_progress are described in the
Kernel Configuration ,
while logger is described below.
-
+
- logger
- The logger application configuration parameter is used to configure
- three different logger aspects; handlers, logger filters and module levels.
+
logger
+ The application configuration parameter logger is used to configure
+ three different Logger aspects; handlers, logger filters and module levels.
The configuration is a list containing tagged tuples that look like this:
DisableHandler = {handler,default,undefined}
- - Disable the default handler. This will allow another application
+
-
+
Disable the default handler. This allows another application
to add its own default handler. See
- logger:add_handlers/1 for more details.
+ logger:add_handlers/1 for more details.
+ Only one entry of this option is allowed.
AddHandler = {handler,HandlerId,Module,HandlerConfig}
- - Add a handler as if
- logger:add_handler(HandlerId,Module,HandlerConfig) had been
- called.
- Filters = {filters, FilterDefault, [Filter]}
+ -
+
Add a handler as if
+ logger:add_handler(HandlerId,Module,HandlerConfig) is
+ called.
+ It is allowed to have multiple entries of this option.
+ Filters = {filters, default, [Filter]}
FilterDefault = log | stop
Filter = {FilterId, {FilterFun, FilterConfig}}
- - Add the specified
- logger filters . Only one entry is allowed of this option.
- ModuleLevel
- {module_level, Level, [Module]} ,
- this option configures the
- module log level to be used. It is possible to have multiple
- module_level entries.
+ -
+
Add the specified
+ logger filters .
+ Only one entry of this option is allowed.
+ ModuleLevel = {module_level, Level, [Module]}
+ -
+
This option configures
+ module log level .
+ 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 @@
-
@@ -441,36 +446,30 @@
error_logger in the following ways:
- Legacy event handlers
- -
-
To use event handlers written for error_logger , just
- add your event handler with
-
-error_logger:add_report_handler/1,2.
-
- This will automatically start the error_logger
- event manager, and add error_logger as a
- handler to logger , with configuration
-
-#{level=>info,
- filter_default=>log,
- filters=>[]}.
-
- Note that this handler will ignore events that do not
- originate from the old error_logger API, or from
- within OTP. This means that if your code uses the logger API
- for logging, then your log events will be discarded by this
- handler.
- Also note that error_logger is not overload
- protected.
-
- Logger API
+ API for Logging
-
The old error_logger API still exists, but should
only be used by legacy code. It will be removed in a later
release.
+ Calls
+ to
+ error_logger:error_report/1,2 ,
+
+ error_logger:error_msg/1,2 , and
+ corresponding functions for warning and info messages, are
+ all forwarded to Logger as calls
+ to
+ logger:log(Level,Report,Metadata) .
+ Level = error | warning | info and is taken
+ from the function name. Report contains the actual
+ log message, and Metadata contains additional
+ information which can be used for creating backwards
+ compatible events for legacy error_logger event
+ handlers, see
+ section Legacy
+ Event Handlers .
- Output format
+ Output Format
-
To get log events on the same format as produced
by error_logger_tty_h and error_logger_file_h ,
@@ -478,13 +477,13 @@ error_logger:add_report_handler/1,2.
configuration parameter legacy_header=>true . This is
also the default.
- Default format of log events from OTP
+ Default Format of Log Events from OTP
-
By default, all log events originating from within OTP,
except the former so called "SASL reports", look the same as
before.
- SASL reports
+ SASL Reports
-
By SASL reports we mean supervisor reports, crash reports
and progress reports.
@@ -494,32 +493,63 @@ error_logger:add_report_handler/1,2.
named sasl_report_tty_h
and sasl_report_file_h .
The destination of these log events were configured by
- environment variables for the SASL application.
+ SASL
+ configuration parameters .
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:
- Supervisor reports, crash reports and progress reports
are no longer connected to the SASL application.
- Supervisor reports and crash reports are logged by
default.
- Progress reports are not logged by default, but can be
- enabled with the kernel environment
- variable
logger_log_progress .
+ enabled with the Kernel configuration
+ parameter
+ logger_log_progress .
- The output format is the same for all log
events.
- If the old behavior is preferred, the kernel environment
- variable logger_sasl_compatible can be set
- to true . The old SASL environment variables can then
- be used as before, and the SASL reports will only be printed
- if the SASL application is running - through a second log
- handler named sasl_h .
+ If the old behaviour is preferred, the Kernel configuation
+ parameter
+ logger_sasl_compatible can be set
+ to true . The
+ old SASL
+ configuration parameters can then be used as
+ before, and the SASL reports will only be printed if the
+ SASL application is running, through a second log handler
+ named sasl_h .
All SASL reports have a metadata
field domain=>[beam,erlang,otp,sasl] , which can be
used, for example, by filters to stop or allow the
events.
+ See the SASL User's
+ Guide for more information about the old SASL
+ error logging functionality.
+
+ Legacy Event Handlers
+ -
+
To use event handlers written for error_logger , just
+ add your event handler with
+
+error_logger:add_report_handler/1,2.
+
+ This will automatically start the error_logger
+ event manager, and add error_logger as a
+ handler to logger , with configuration
+
+#{level=>info,
+ filter_default=>log,
+ filters=>[]}.
+
+ Notice that this handler will ignore events that do not
+ originate from the old error_logger API, or from
+ within OTP. This means that if your code uses the Logger API
+ for logging, then your log events will be discarded by this
+ handler.
+ Also notice that error_logger is not overload
+ protected.
@@ -535,14 +565,14 @@ error_logger:add_report_handler/1,2.
converting the report to a format string and arguments. The
handler might also do a custom conversion if the default format
is not desired.
- logger does, to a certain extent, check its input data
+
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.
Example: add a handler to log debug events to file
- 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 debug or add a separate
handler to take care of this. In this example we will add a new
handler which prints the debug events to a separate file.
- First, we add an instance of logger_std_h with
+
First, we add an instance of logger_std_h with
type {file,File} , and we set the handler's level
to debug :
@@ -575,9 +605,9 @@ ok
#Fun<erl_eval.12.98642416>
4> logger:add_handler_filter(debug_handler,allow_debug,{Fun,[]}).
ok
- 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:
+ log level:
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)
diff --git a/lib/kernel/doc/src/logger_disk_log_h.xml b/lib/kernel/doc/src/logger_disk_log_h.xml
index 440ae28e5d..20b49b8ca0 100644
--- a/lib/kernel/doc/src/logger_disk_log_h.xml
+++ b/lib/kernel/doc/src/logger_disk_log_h.xml
@@ -33,21 +33,21 @@
logger_disk_log_h.xml
logger_disk_log_h
- A disk_log based handler for the Logger
- application.
+ A disk_log based handler for the Logger.
- This is a handler for the Logger application that offers circular
- (wrapped) logs by using the disk_log application. Multiple instances
- of this handler can be added to logger, and each instance will print to
+
This is a handler for Logger that offers circular
+ (wrapped) logs by using disk_log .
+ Multiple instances
+ of this handler can be added to Logger, and each instance prints to
its own disk_log file, created with the name and settings specified in
the handler configuration.
The default standard handler,
logger_std_h , can be
- replaced by a disk_log handler at startup of the kernel application.
+ replaced by a disk_log handler at startup of the Kernel application.
See an example of this below.
The handler has an overload protection mechanism that will keep the handler
- process and the kernel application alive during a high load of log
+ process and the Kernel application alive during a high load of log
requests. How this feature works, and how to modify the configuration,
is described in the
User's Guide
@@ -121,7 +121,7 @@ logger:add_handler(my_disk_log_h, logger_disk_log_h,
#{filesync_repeat_interval => 1000}}).
In order to use the disk_log handler instead of the default standard - handler when starting en Erlang node, change the Kernel default logger to + handler when starting an Erlang node, change the Kernel default logger to use disk_log. Example:
erl -kernel logger '[{handler,default,logger_disk_log_h,
@@ -141,6 +141,12 @@ erl -kernel logger '[{handler,default,logger_disk_log_h,
+
+ See Also
+ logger(3)
+ logger_std_h(3)
+ disk_log(3)
+
diff --git a/lib/kernel/doc/src/logger_formatter.xml b/lib/kernel/doc/src/logger_formatter.xml
index 370d61d338..ee43634cf9 100644
--- a/lib/kernel/doc/src/logger_formatter.xml
+++ b/lib/kernel/doc/src/logger_formatter.xml
@@ -39,7 +39,8 @@
Each log handler has a configured formatter specified as a
module and a configuration term. The purpose of the formatter is
to translate the log events to a final printable string
- (unicode:chardata() ) which can be written to the output
+ (unicode:chardata()
+ ) which can be written to the output
device of the handler.
logger_formatter is the default formatter used by
Logger.
@@ -47,7 +48,8 @@
Configuration
- The configuration term for logger_formatter is a map,
+
The configuration term for logger_formatter is a
+ map ,
and the following keys can be set as configuration
parameters:
@@ -55,7 +57,7 @@
-
A positive integer representing the value of the option
with the same name to be used when calling
- io_lib:format/3 .
+ io_lib:format/3 .
This value limits the total number of characters printed
for each log event. Notice that this is a soft limit. For a
hard truncation limit, see option max_size .
@@ -99,7 +101,7 @@
added by the template parameter are not replaced.
Default is true .
- legacy_header = boolen()
+ legacy_header = boolean()
-
If set to true a header field is added to
logger_formatter's part of Metadata . The value of
@@ -181,8 +183,8 @@
to "+02:00" .
The default value is an empty string, meaning that
timestamps are displayed in local time. However, for
- backwards compatibility, if the SASL environment
- variable
+ backwards compatibility, if the SASL configuration
+ parameter
utc_log =true , the default is
changed to "Z" , meaning that timestamps are displayed
in UTC.
@@ -206,28 +208,42 @@
?LOG_ERROR("name: ~p~nexit_reason: ~p",[my_name,"It crashed"])
Default template:
Example log entry:
-2018-05-16T11:55:50.448382+02:00 error:
+=ERROR REPORT==== 17-May-2018::18:30:19.453447 ===
name: my_name
exit_reason: "It crashed"
- Notice that all eight levels might occur in the heading, +
Notice that all eight levels can occur in the heading,
not only
Default template:
Notice that the template is here the same as
+ for
+=ERROR REPORT==== 17-May-2018::18:31:06.952665 ===
+name: my_name, exit_reason: "It crashed"
+ Default template:
Example log entry:
-2018-05-16T11:55:50.448382+02:00 error: name: my_name, exit_reason: "It crashed"
+
+2018-05-17T18:31:31.152864+02:00 error: name: my_name, exit_reason: "It crashed"
Example log entry:
-2018-05-16T11:55:50.448382+02:00 error:
+2018-05-17T18:32:20.105422+02:00 error:
name: my_name
exit_reason: "It crashed"
diff --git a/lib/kernel/doc/src/logger_std_h.xml b/lib/kernel/doc/src/logger_std_h.xml
index bf23d874c8..a4f2848037 100644
--- a/lib/kernel/doc/src/logger_std_h.xml
+++ b/lib/kernel/doc/src/logger_std_h.xml
@@ -33,17 +33,17 @@
This is the default handler for the Logger
- application. Multiple instances of this handler can be added to
- logger, and each instance will print logs to
This is the default handler for Logger.
+ Multiple instances of this handler can be added to
+ Logger, and each instance will print logs to
The handler has an overload protection mechanism that will keep the handler
- process and the kernel application alive during a high load of log
+ process and the Kernel application alive during a high load of log
requests. How this feature works, and how to modify the configuration,
is described in the
In order to configure the default handler (that starts initially with
- the kernel application) to log to file instead of
erl -kernel logger '[{handler,default,logger_std_h,
@@ -127,6 +127,11 @@ erl -kernel logger '[{handler,default,logger_std_h,
+
Update the formatter configuration for the specified handler.
+The new configuration is merged with the existing formatter + configuration.
+To overwrite the existing configuration without any merge,
+ use
Update the formatter configuration for the specified handler.
+This is equivalent
+ to
A formatter is defined as a module exporting the following function:
-format(Log,Extra) -> unicode:chardata()
+ format(Log,FConfig) -> unicode:chardata()
The formatter callback is called by each handler, and the
returned string can be printed to the handler's destination
@@ -413,12 +413,12 @@
return
Default is
See
The default module is
Remove a module specific log setting. After this, the
diff --git a/lib/kernel/src/logger.erl b/lib/kernel/src/logger.erl
index d60be180bc..2a0e2e5f50 100644
--- a/lib/kernel/src/logger.erl
+++ b/lib/kernel/src/logger.erl
@@ -37,7 +37,7 @@
-export([add_handler/3, remove_handler/1,
add_logger_filter/2, add_handler_filter/3,
remove_logger_filter/1, remove_handler_filter/2,
- set_module_level/2, reset_module_level/1,
+ set_module_level/2, unset_module_level/1,
set_logger_config/1, set_logger_config/2,
set_handler_config/2, set_handler_config/3,
update_logger_config/1, update_handler_config/2,
@@ -408,10 +408,10 @@ update_formatter_config(HandlerId,Key,Value) ->
set_module_level(Module,Level) ->
logger_server:set_module_level(Module,Level).
--spec reset_module_level(Module) -> ok | {error,term()} when
+-spec unset_module_level(Module) -> ok | {error,term()} when
Module :: module().
-reset_module_level(Module) ->
- logger_server:reset_module_level(Module).
+unset_module_level(Module) ->
+ logger_server:unset_module_level(Module).
%%%-----------------------------------------------------------------
%%% Misc
diff --git a/lib/kernel/src/logger_config.erl b/lib/kernel/src/logger_config.erl
index 40dc1b1e1b..1d35c2e068 100644
--- a/lib/kernel/src/logger_config.erl
+++ b/lib/kernel/src/logger_config.erl
@@ -24,7 +24,7 @@
allow/2,allow/3,
get/2, get/3, get/1,
create/3, create/4, set/3,
- set_module_level/3,reset_module_level/2,
+ set_module_level/3,unset_module_level/2,
cache_module_level/2,
level_to_int/1]).
@@ -109,7 +109,7 @@ set_module_level(Tid,Module,Level) ->
ets:insert(Tid,{Module,level_to_int(Level)}),
ok.
-reset_module_level(Tid,Module) ->
+unset_module_level(Tid,Module) ->
ets:delete(Tid,Module), % should possibley overwrite instead of delete?
ok.
diff --git a/lib/kernel/src/logger_server.erl b/lib/kernel/src/logger_server.erl
index 18a784c8c2..16f61abdd6 100644
--- a/lib/kernel/src/logger_server.erl
+++ b/lib/kernel/src/logger_server.erl
@@ -25,7 +25,7 @@
-export([start_link/0,
add_handler/3, remove_handler/1,
add_filter/2, remove_filter/2,
- set_module_level/2, reset_module_level/1,
+ set_module_level/2, unset_module_level/1,
cache_module_level/1,
set_config/2, set_config/3, update_config/2,
update_formatter_config/2]).
@@ -83,9 +83,9 @@ set_module_level(Module,Level) when is_atom(Module) ->
set_module_level(Module,_) ->
{error,{not_a_module,Module}}.
-reset_module_level(Module) when is_atom(Module) ->
- call({reset_module_level,Module});
-reset_module_level(Module) ->
+unset_module_level(Module) when is_atom(Module) ->
+ call({unset_module_level,Module});
+unset_module_level(Module) ->
{error,{not_a_module,Module}}.
cache_module_level(Module) ->
@@ -243,8 +243,8 @@ handle_call({update_formatter_config,HandlerId,NewFConfig},_From,
handle_call({set_module_level,Module,Level}, _From, #state{tid=Tid}=State) ->
Reply = logger_config:set_module_level(Tid,Module,Level),
{reply,Reply,State};
-handle_call({reset_module_level,Module}, _From, #state{tid=Tid}=State) ->
- Reply = logger_config:reset_module_level(Tid,Module),
+handle_call({unset_module_level,Module}, _From, #state{tid=Tid}=State) ->
+ Reply = logger_config:unset_module_level(Tid,Module),
{reply,Reply,State}.
handle_cast({async_req_reply,_Ref,_Reply} = Reply,State) ->
diff --git a/lib/kernel/test/logger_SUITE.erl b/lib/kernel/test/logger_SUITE.erl
index 1d3410e356..66eee8219a 100644
--- a/lib/kernel/test/logger_SUITE.erl
+++ b/lib/kernel/test/logger_SUITE.erl
@@ -318,7 +318,7 @@ macros(_Config) ->
macros(cleanup,_Config) ->
logger:remove_handler(h1),
- logger:reset_module_level(?MODULE),
+ logger:unset_module_level(?MODULE),
ok.
set_level(_Config) ->
@@ -350,29 +350,29 @@ set_level_module(_Config) ->
logger:info(M2=?map_rep,?MY_LOC(0)),
ok = check_logged(info,M2,?MY_LOC(1)),
- {error,{not_a_module,{bad}}} = logger:reset_module_level({bad}),
- ok = logger:reset_module_level(?MODULE),
+ {error,{not_a_module,{bad}}} = logger:unset_module_level({bad}),
+ ok = logger:unset_module_level(?MODULE),
ok.
set_level_module(cleanup,_Config) ->
logger:remove_handler(h1),
- logger:reset_module_level(?MODULE),
+ logger:unset_module_level(?MODULE),
ok.
cache_level_module(_Config) ->
- ok = logger:reset_module_level(?MODULE),
+ ok = logger:unset_module_level(?MODULE),
[] = ets:lookup(logger,?MODULE), %dirty - add API in logger_config?
?LOG_INFO(?map_rep),
%% Caching is done asynchronously, so wait a bit for the update
timer:sleep(100),
[_] = ets:lookup(logger,?MODULE), %dirty - add API in logger_config?
- ok = logger:reset_module_level(?MODULE),
+ ok = logger:unset_module_level(?MODULE),
[] = ets:lookup(logger,?MODULE), %dirty - add API in logger_config?
ok.
cache_level_module(cleanup,_Config) ->
- logger:reset_module_level(?MODULE),
+ logger:unset_module_level(?MODULE),
ok.
format_report(_Config) ->
--
cgit v1.2.3
From e484181ecc5c3e2928d10632138837eba3c3229e Mon Sep 17 00:00:00 2001
From: Siri Hansen
This module is the main API for logging in Erlang/OTP. It
contains functions that allow applications to use a single log
@@ -217,6 +190,15 @@ logger:error("error happened because: ~p",[Reason]). %% Without macro
Configuration data for the
+ formatter. See
See section
See section
Some built-in filters exist. These are defined
in
See
- section
Some built-in filters exist. These are defined in
The following functions are to be exported from a handler callback module.
This callback function is optional.
The function is called when an new handler is about to be added, and the purpose is to verify the configuration and - initiate all resourced needed by the handler.
+ initiate all resources needed by the handler.If everything succeeds, the callback function can add possible default values or internal state values to the configuration, and return the adjusted map @@ -922,24 +905,7 @@ logger:set_process_metadata(maps:merge(logger:get_process_metadata(),Meta)).
This callback function is optional.
-The function is called when a handler is about to be - removed, and the purpose is to release all resources used by - the handler. The return value is ignored by Logger.
-This callback function is mandatory.
+The function is called when all global filters and all + handler filters for the handler in question have passed for + the given log event.
+The handler must log the event.
+The return value from this function is ignored by + Logger.
+This callback function is optional.
+The function is called when a handler is about to be + removed, and the purpose is to release all resources used by + the handler. The return value is ignored by Logger.
+The following functions are to be exported from a formatter + callback module.
+This callback function is mandatory.
+The function can be called by a log handler to convert a
+ log event term to a printable string. The returned value
+ can, for example, be printed as a log entry to the console
+ or a file using
See
As of OTP-21, Erlang/OTP provides a standard API for logging
+ through
By default, the Kernel application installs one log handler at
+ system start. This handler is named
You can also configure the system so that the default handler
+ prints log events to a single file, or to a set of wrap logs
+ via
By confiugration, you can aslo modify or disable the default + handler, replace it by a custom handler, and install additional + handlers.
+Erlang/OTP provides a standard API for logging. The backend of - this API can be used as is, or it can be customized to suite - specific needs.
-It consists of two parts - the logger part and the - handler part. The logger part forwards log events to - one or more handler(s).
+A log event consists of a log level, the + message to be logged, and metadata.
+The Logger backend forwards log events from the API, first + through a set of global filters, then through a set + of handler filters for each log handler.
+Each filter set consists of a log level check, + followed by zero or more filter functions.
+The following figure show a conseptual overview of Logger. The + figure shows two log handlers, but any number of handlers can be + installed.
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.
- -A formatter can be set for each handler. The formatter - does the final formatting of the log event, including the log - message itself, and possibly a timestamp, header and other - metadata.
- -In accordance with the Syslog protocol, RFC-5424, eight - severity levels can be specified:
+In accordance with the Syslog protocol, RFC-5424, eight log + levels can be specified:
A log event is allowed by Logger if the integer value of
- its
A handler is defined as a module exporting the following - function:
- -log(Log, Config) -> ok
-
- 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 - added. Configuration is per instance.
- -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 - pass.
- -A filter is specified as:
- -{fun((Log,Extra) -> Log | stop | ignore), Extra}
-
- The configuration parameter
The
A formatter is defined as a module exporting the following - function:
- -format(Log,FConfig) -> unicode:chardata()
-
- The formatter callback is called by each handler, and the - returned string can be printed to the handler's destination - (stdout, file, ...).
-This is the default handler used by OTP. Multiple instances - can be started, and each instance will write log events to a - given destination, console or file. Filters can be used for - selecting which event to send to which handler instance.
-This handler behaves much like logger_std_h, except it uses
-
This handler is to be used for backwards compatibility
- only. It is not started by default, but will be automatically
- started the first time an event handler is added
- with
No built-in event handlers exist.
-This filter provides a way of filtering log events based on a
-
A log event passes the level check if the integer value of its + log level is less than or equal to the currently configured log + level, that is, if the event is equally or more severe than the + configured level.
+The global log level can be overridden by a log level + configured per module. This is to, for instance, allow more + verbose logging from a specific part of the system.
+Filter functions can be used for more sophisticated filtering
+ than the log level check provides. A filter function can stop or
+ pass a log event, based on any of the event's contents. It can
+ also modify all parts of the log event. See see
+ section
If a log event passes through all global filters and all
+ handler filters for a specific handler, Logger forwards the event
+ to the handler callback. The handler formats and prints the
+ event to its destination. See
+ section
Everything upto and including the call to the handler callbacks + is executed on the client process, that is, the process where + the log event was issued. It is up to the handler implementation + if other processes are to be involved or not.
+The handlers are called in sequence, and the order is not + defined.
+Filters can be global, or attached to a specific + handler. Logger calls the global filters first, and if they all + pass, it calls the handler filters for each handler. Logger + calls the handler callback only if all filters attached to the + handler in question also pass.
+A filter is defined as:
+{FilterFun, Extra}
+ where
The filter function can return
If
If the log event is returned, the next filter function is + called with the returned value as the first argument. That is, + if a filter function modifies the log event, the next filter + function receivea the modified event. The value returned from + the last filter funcion is the value that the handler callback + receives.
+If the filter function returns
The configuration
+ option
Filters are applied in the reverse order of installation, + meaning that the last added filter is applied first.
+ +Global filters are added
+ with
Handler filters are added with
+ with
To see which filters are currently installed in the system,
+ use
For convenience, the following built-in filters exist:
+ +This filter provides a way of filtering log events based
- on the log level. See
A handler is defined as a module exporting at least the + following function:
+ ++ +log(Log, Config)
This function is called when a log event has passed through all + global filters, and all handler filters attached to the handler + in question. The function call is executed on the client + process, and it is up to the handler implementation if other + processes are to be involved or not.
+ +Logger allows adding multiple instances of a handler + callback. That is, the callback module might be implemented in + such a way that, by using different handler identities, the same + callback module can be used for multiple handler + instances. Handler configuration is per instance.
+ +In addition to the mandatory callback function
The following built-in handlers exist:
-This filter matches all progress reports
- from
This is the default handler used by OTP. Multiple instances + can be started, and each instance will write log events to a + given destination, console or file. Filters can be used for + selecting which event to send to which handler instance.
+This filter matches all events originating from a process
- that has its group leader on a remote node.
- See
This handler behaves much like logger_std_h, except it uses
+
This handler is to be used for backwards compatibility
+ only. It is not started by default, but will be
+ automatically started the first time an
The old
The default formatter is
A formatter can be used by the handler implementation to do the
+ final formatting of a log event, before printing to the
+ handler's destination. The handler callback gets the formatter
+ information in the handler configuration, which is passed as the
+ second argument to
The formatter information consits of a formatter
+ module,
+format(Log,FConfig) + -> FormattedLogEntry
See the
Specifies the severity level to log.
+Specifies the global log level to log.
+See table
The initial value of this option is set by the Kernel
+ configuration
+ parameter
Logger filters are added or removed with +
Global filters are added and removed with
See
By default, no filters exist.
+See section
Default is
Specifies what to do with an event if all filters
return
See section
Default is
Handlers are added or removed with
-
See
Specifies the severity level to log.
+Specifies the log level which the handler logs.
+See table
The log level can be specified when adding the handler,
+ or changed during runtime with, for
+ instance,
Default is
Handler filters can be specified when adding the handler,
- or added or removed later with
+ or added or removed during runtime with
See
See
By default, no filters exist.
+Default is
Specifies what to do with an event if all filters
return
See section
Default is
See
The formatter which the handler can use for converting + the log event term to a printable string.
+See
The default module is
Default
+ is
Any keys not listed above are considered to be handler
+ specific configuration. The configuration of the Kernel
+ handlers can be found in
+ the
Note that
Notice that
All Logger's built-in handlers will call the given formatter + before printing.
Logger provides backwards compatibility with the old
Log data is expected to be either a format string and
- arguments, a string (unicode:chardata), or a report (map or
+ arguments, a string
+ (
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 @@ -630,17 +743,17 @@ removing_handler(logger:handler_id(),logger:config()) -> ok changing_config(logger:handler_id(),logger:config(),logger:config()) -> {ok,logger:config()} | {error,term()}
When
A handler can be removed by calling
When
In order for the built-in handlers to survive, and stay responsive, during periods of high load (i.e. when huge numbers of incoming log requests must be handled), a mechanism for overload protection @@ -734,7 +847,7 @@ do_log(Fd,Log,#{formatter:={FModule,FConfig}}) -> as follows:
The handler process keeps track of the length of its message queue and reacts in different ways depending on the current status. The purpose is to keep the handler in, or (as quickly as possible), @@ -829,7 +942,7 @@ logger:add_handler(my_standard_h, logger_std_h,
A potential problem with large bursts of log requests, is that log files may get full or wrapped too quickly (in the latter case overwriting previously logged data that could be of great importance). For this reason, @@ -870,7 +983,7 @@ logger:add_handler(my_disk_log_h, logger_disk_log_h,
A handler process may grow large even if it can manage peaks of high load
without crashing. The overload protection mechanism includes user configurable
levels for a maximum allowed message queue length and maximum allowed memory
diff --git a/lib/kernel/src/logger.erl b/lib/kernel/src/logger.erl
index 2a0e2e5f50..9c721d7fee 100644
--- a/lib/kernel/src/logger.erl
+++ b/lib/kernel/src/logger.erl
@@ -93,14 +93,16 @@
-type config() :: #{level => level(),
filter_default => log | stop,
filters => [{filter_id(),filter()}],
- formatter => {module(),map()},
- term() => term()}.
+ formatter => {module(),formatter_config()},
+ atom() => term()}.
-type timestamp() :: integer().
+-type formatter_config() :: #{atom() => term()}.
-type config_handler() :: {handler, handler_id(), module(), config()}.
-export_type([log/0,level/0,report/0,msg_fun/0,metadata/0,config/0,handler_id/0,
- filter_id/0,filter/0,filter_arg/0,filter_return/0, config_handler/0]).
+ filter_id/0,filter/0,filter_arg/0,filter_return/0,config_handler/0,
+ formatter_config/0]).
%%%-----------------------------------------------------------------
%%% API
@@ -390,7 +392,7 @@ get_handler_config(HandlerId) ->
-spec update_formatter_config(HandlerId,FormatterConfig) ->
ok | {error,term()} when
HandlerId :: config(),
- FormatterConfig :: map().
+ FormatterConfig :: formatter_config().
update_formatter_config(HandlerId,FormatterConfig) ->
logger_server:update_formatter_config(HandlerId,FormatterConfig).
--
cgit v1.2.3
From d35c100a10239edc669b465a2176000ffcc1300f Mon Sep 17 00:00:00 2001
From: Siri Hansen
By SASL reports we mean supervisor reports, crash reports and progress reports.
diff --git a/lib/kernel/doc/src/logger_filters.xml b/lib/kernel/doc/src/logger_filters.xml index 1bbae8be21..f92181ea3f 100644 --- a/lib/kernel/doc/src/logger_filters.xml +++ b/lib/kernel/doc/src/logger_filters.xml @@ -52,61 +52,100 @@This filter provides a way of filtering log events based on a
-
The
The filter compares the value of the
The filter matches if
The filter matches if
The filter matches if
The filter matches if
The filter matches if there is no domain field in
- metadata. In this case
If the filter matches and
If the filter does not match, it returns
Log events that do not contain any domain field, will
- only match when
Example: stop all events with
- domain
+ This filter provides a way of filtering log events based on a
+ domain field in Metadata . This field is
+ optional, and the purpose of using it is to group log events
+ from, for example, a specific functional area. This allows
+ filtering or other specialized treatment in a Logger
+ handler.
+
+ A domain field must be a list of atoms, creating smaller
+ and more specialized domains as the list grows longer. The
+ biggest domain is [] , which comprices all
+ possible domains.
+
+ For example, consider the following domains:
+
+D1 = [beam,erlang,otp]
+D2 = [beam,erlang,otp,sasl]
+
+ D1 is the biggest of the two, and is said to be a
+ super-domain of D2 . D2 is a
+ sub-domain D1 . Both D1 and D2 are
+ sub-domains of []
+
+ The above domains are used for logs originating from
+ Erlang/OTP. D1 specifies that the log event comes from
+ Erlang/OTP in general, and D2 indicates that the log event
+ is a so
+ called SASL
+ report .
+
+ The Extra parameter to
+ the domain/2 function is specified when adding the
+ filter via
+ logger:add_logger_filter/2
+ or
+ logger:add_handler_filter/3 .
+
+ The filter compares the value of the domain field
+ in the log event's metadata (Domain )
+ to MatchDomain as follows:
+
+
+ Compare = sub
+ -
+
The filter matches if Domain is equal to or
+ a sub-domain of MatchDomain , that is,
+ if MatchDomain is a prefix of Domain .
+
+ Compare = super
+ -
+
The filter matches if Domain is equal to or a
+ super-domain of MatchDomain , that is,
+ if Domain is a prefix of MatchDomain .
+
+ Compare = equal
+ -
+
The filter matches if Domain is equal
+ to MatchDomain .
+
+ Compare = not_equal
+ -
+
The filter matches if Domain is not equal
+ to MatchDomain , or if there is no domain field in
+ metadata.
+
+ Compare = undefined
+ The filter matches if there is no domain field in
+ metadata. In this case MatchDomain
+ must be set to [] .
+
+
+
+ If the filter matches and Action = log ,
+ the log event is allowed. If the filter matches
+ and Action = stop , the log event is
+ stopped.
+
+ If the filter does not match, it returns ignore ,
+ meaning that other filters, or the value of the
+ configuration parameter filter_default , decide if the
+ event is allowed or not.
+
+ Log events that do not contain any domain field, match only
+ when Compare = undefined
+ or Compare = not_equal .
+
+ Example: stop all events with
+ domain [beam,erlang,otp,sasl|_]
+
+
logger:set_handler_config(h1,filter_default,log). % this is the default
-Filter = {fun logger_filters:domain/2,{stop,starts_with,[beam,erlang,otp,sasl]}}.
+Filter = {fun logger_filters:domain/2,{stop,sub,[beam,erlang,otp,sasl]}}.
logger:add_handler_filter(h1,no_sasl,Filter).
ok
All SASL reports have a metadata
field The function is called when an new handler is about to be
added, and the purpose is to verify the configuration and
initiate all resources needed by the handler. The handler identity is associated with the If everything succeeds, the callback function can add
possible default values or internal state values to the
configuration, and return the adjusted map
@@ -905,11 +905,9 @@ logger:set_process_metadata(maps:merge(logger:get_process_metadata(),Meta)).
The handler identity is associated with the
If everything succeeds, the callback function must return a
possibly adjusted configuration in
If the configuration is faulty, the callback function must @@ -942,6 +942,8 @@ logger:set_process_metadata(maps:merge(logger:get_process_metadata(),Meta)).
The function is called when all global filters and all handler filters for the handler in question have passed for the given log event.
+The handler identity is associated with the
The handler must log the event.
The return value from this function is ignored by Logger.
@@ -949,11 +951,9 @@ logger:set_process_metadata(maps:merge(logger:get_process_metadata(),Meta)).This callback function is optional.
The function is called when a handler is about to be removed, and the purpose is to release all resources used by - the handler. The return value is ignored by Logger.
+ the handler. +The handler identity is associated with the
The return value is ignored by Logger.
In addition to the mandatory callback function log(logger:log(),logger:config()) ->ok
It may also implement the following callbacks:
-adding_handler(logger:handler_id(),logger:config()) -> {ok,logger:config()} | {error,term()}
-removing_handler(logger:handler_id(),logger:config()) -> ok
-changing_config(logger:handler_id(),logger:config(),logger:config()) -> {ok,logger:config()} | {error,term()}
+adding_handler(logger:config()) -> {ok,logger:config()} | {error,term()}
+removing_handler(logger:config()) -> ok
+changing_config(logger:config(),logger:config()) -> {ok,logger:config()} | {error,term()}
When
A handler can be removed by calling
When
-module(myhandler).
--export([adding_handler/2, removing_handler/2, log/2]).
+-export([adding_handler/1, removing_handler/1, log/2]).
-export([init/1, handle_call/3, handle_cast/2, terminate/2]).
-adding_handler(Id,Config) ->
+adding_handler(Config) ->
{ok,Fd} = file:open(File,[append,{encoding,utf8}]),
{ok,Config#{myhandler_fd=>Fd}}.
-removing_handler(Id,#{myhandler_fd:=Fd}) ->
+removing_handler(#{myhandler_fd:=Fd}) ->
_ = file:close(Fd),
ok.
@@ -800,14 +800,14 @@ log(Log,#{myhandler_fd:=Fd,formatter:={FModule,FConfig}}) ->
single process.
-module(myhandler).
--export([adding_handler/2, removing_handler/2, log/2]).
+-export([adding_handler/1, removing_handler/1, log/2]).
-export([init/1, handle_call/3, handle_cast/2, terminate/2]).
-adding_handler(Id,Config) ->
+adding_handler(Config) ->
{ok,Pid} = gen_server:start(?MODULE,Config),
{ok,Config#{myhandler_pid=>Pid}}.
-removing_handler(Id,#{myhandler_pid:=Pid}) ->
+removing_handler(#{myhandler_pid:=Pid}) ->
gen_server:stop(Pid).
log(Log,#{myhandler_pid:=Pid} = Config) ->
diff --git a/lib/kernel/src/error_logger.erl b/lib/kernel/src/error_logger.erl
index 6c3b308308..96f6536e61 100644
--- a/lib/kernel/src/error_logger.erl
+++ b/lib/kernel/src/error_logger.erl
@@ -32,7 +32,7 @@
which_report_handlers/0]).
%% logger callbacks
--export([adding_handler/2, removing_handler/2, log/2]).
+-export([adding_handler/1, removing_handler/1, log/2]).
-export([get_format_depth/0, limit_term/1]).
@@ -101,9 +101,9 @@ stop() ->
%%%-----------------------------------------------------------------
%%% Callbacks for logger
--spec adding_handler(logger:handler_id(),logger:config()) ->
+-spec adding_handler(logger:config()) ->
{ok,logger:config()} | {error,term()}.
-adding_handler(?MODULE,Config) ->
+adding_handler(#{id:=?MODULE}=Config) ->
case start() of
ok ->
{ok,Config};
@@ -111,8 +111,8 @@ adding_handler(?MODULE,Config) ->
Error
end.
--spec removing_handler(logger:handler_id(),logger:config()) -> ok.
-removing_handler(?MODULE,_Config) ->
+-spec removing_handler(logger:config()) -> ok.
+removing_handler(#{id:=?MODULE}) ->
stop(),
ok.
diff --git a/lib/kernel/src/logger.erl b/lib/kernel/src/logger.erl
index 9c721d7fee..f22fd5e8de 100644
--- a/lib/kernel/src/logger.erl
+++ b/lib/kernel/src/logger.erl
@@ -90,7 +90,8 @@
-type filter() :: {fun((log(),filter_arg()) -> filter_return()),filter_arg()}.
-type filter_arg() :: term().
-type filter_return() :: stop | ignore | log().
--type config() :: #{level => level(),
+-type config() :: #{id => handler_id(),
+ level => level(),
filter_default => log | stop,
filters => [{filter_id(),filter()}],
formatter => {module(),formatter_config()},
diff --git a/lib/kernel/src/logger_disk_log_h.erl b/lib/kernel/src/logger_disk_log_h.erl
index 57c54ce27e..37a147e3dc 100644
--- a/lib/kernel/src/logger_disk_log_h.erl
+++ b/lib/kernel/src/logger_disk_log_h.erl
@@ -34,8 +34,8 @@
%% logger callbacks
-export([log/2,
- adding_handler/2, removing_handler/2,
- changing_config/3, swap_buffer/2]).
+ adding_handler/1, removing_handler/1,
+ changing_config/2, swap_buffer/2]).
%%%===================================================================
%%% API
@@ -108,8 +108,8 @@ reset(Name) ->
%%%-----------------------------------------------------------------
%%% Handler being added
-adding_handler(Name, Config) ->
- case check_config(adding, Name, Config) of
+adding_handler(#{id:=Name}=Config) ->
+ case check_config(adding, Config) of
{ok, Config1} ->
%% create initial handler state by merging defaults with config
HConfig = maps:get(?MODULE, Config1, #{}),
@@ -136,10 +136,9 @@ adding_handler(Name, Config) ->
%%%-----------------------------------------------------------------
%%% Updating handler config
-changing_config(Name,
- OldConfig=#{id:=Id, disk_log_opts:=DLOpts},
- NewConfig=#{id:=Id, disk_log_opts:=DLOpts}) ->
- case check_config(changing, Name, NewConfig) of
+changing_config(OldConfig=#{id:=Name, disk_log_opts:=DLOpts},
+ NewConfig=#{id:=Name, disk_log_opts:=DLOpts}) ->
+ case check_config(changing, NewConfig) of
Result = {ok,NewConfig1} ->
try gen_server:call(Name, {change_config,OldConfig,NewConfig1},
?DEFAULT_CALL_TIMEOUT) of
@@ -151,12 +150,10 @@ changing_config(Name,
Error ->
Error
end;
-changing_config(_Name, OldConfig, NewConfig) ->
+changing_config(OldConfig, NewConfig) ->
{error,{illegal_config_change,OldConfig,NewConfig}}.
-check_config(adding, Name, Config0) ->
- %% Merge in defaults on top level
- Config = maps:merge(#{id => Name}, Config0),
+check_config(adding, #{id:=Name}=Config) ->
%% Merge in defaults on handler level
LogOpts0 = maps:get(disk_log_opts, Config, #{}),
LogOpts = merge_default_logopts(Name, LogOpts0),
@@ -173,7 +170,7 @@ check_config(adding, Name, Config0) ->
Error ->
Error
end;
-check_config(changing, _Name, Config) ->
+check_config(changing, Config) ->
MyConfig = maps:get(?MODULE, Config, #{}),
case check_my_config(maps:to_list(MyConfig)) of
ok -> {ok,Config};
@@ -223,7 +220,7 @@ check_my_config([]) ->
%%%-----------------------------------------------------------------
%%% Handler being removed
-removing_handler(Name, _Config) ->
+removing_handler(#{id:=Name}) ->
stop(Name).
%%%-----------------------------------------------------------------
diff --git a/lib/kernel/src/logger_server.erl b/lib/kernel/src/logger_server.erl
index 16f61abdd6..9182b0b486 100644
--- a/lib/kernel/src/logger_server.erl
+++ b/lib/kernel/src/logger_server.erl
@@ -134,7 +134,7 @@ init([]) ->
filters=>?DEFAULT_HANDLER_FILTERS}),
%% If this fails, then the node should crash
{ok,SimpleConfig} =
- logger_simple:adding_handler(logger_simple,SimpleConfig0),
+ logger_simple:adding_handler(SimpleConfig0),
logger_config:create(Tid,logger_simple,logger_simple,SimpleConfig),
{ok, #state{tid=Tid, async_req_queue = queue:new()}}.
@@ -146,7 +146,7 @@ handle_call({add_handler,Id,Module,HConfig}, From, #state{tid=Tid}=State) ->
call_h_async(
fun() ->
%% inform the handler
- call_h(Module,adding_handler,[Id,HConfig],{ok,HConfig})
+ call_h(Module,adding_handler,[HConfig],{ok,HConfig})
end,
fun({ok,HConfig1}) ->
%% We know that the call_h would have loaded the module
@@ -177,7 +177,7 @@ handle_call({remove_handler,HandlerId}, From, #state{tid=Tid}=State) ->
call_h_async(
fun() ->
%% inform the handler
- call_h(Module,removing_handler,[HandlerId,HConfig],ok)
+ call_h(Module,removing_handler,[HConfig],ok)
end,
fun(_Res) ->
do_set_config(Tid,logger,Config#{handlers=>Handlers}),
@@ -213,7 +213,7 @@ handle_call({set_config,HandlerId,Config}, From, #state{tid=Tid}=State) ->
{ok,{Module,OldConfig}} ->
call_h_async(
fun() ->
- call_h(Module,changing_config,[HandlerId,OldConfig,Config],
+ call_h(Module,changing_config,[OldConfig,Config],
{ok,Config})
end,
fun({ok,Config1}) ->
@@ -348,8 +348,9 @@ default_config(logger) ->
#{level=>info,
filters=>[],
filter_default=>log};
-default_config(_) ->
- #{level=>info,
+default_config(Id) ->
+ #{id=>Id,
+ level=>info,
filters=>[],
filter_default=>log,
formatter=>{?DEFAULT_FORMATTER,#{}}}.
diff --git a/lib/kernel/src/logger_simple.erl b/lib/kernel/src/logger_simple.erl
index c8cdf25887..cfb3fcb620 100644
--- a/lib/kernel/src/logger_simple.erl
+++ b/lib/kernel/src/logger_simple.erl
@@ -19,7 +19,7 @@
%%
-module(logger_simple).
--export([adding_handler/2, removing_handler/2, log/2]).
+-export([adding_handler/1, removing_handler/1, log/2]).
%% This module implements a simple handler for logger. It is the
%% default used during system start.
@@ -27,7 +27,7 @@
%%%-----------------------------------------------------------------
%%% Logger callback
-adding_handler(?MODULE,Config) ->
+adding_handler(#{id:=?MODULE}=Config) ->
Me = self(),
case whereis(?MODULE) of
undefined ->
@@ -44,7 +44,7 @@ adding_handler(?MODULE,Config) ->
{error,{handler_process_name_already_exists,?MODULE}}
end.
-removing_handler(?MODULE,_Config) ->
+removing_handler(#{id:=?MODULE}) ->
case whereis(?MODULE) of
undefined ->
ok;
diff --git a/lib/kernel/src/logger_std_h.erl b/lib/kernel/src/logger_std_h.erl
index e5e0febc88..fc8ca1535b 100644
--- a/lib/kernel/src/logger_std_h.erl
+++ b/lib/kernel/src/logger_std_h.erl
@@ -35,8 +35,8 @@
terminate/2, code_change/3]).
%% logger callbacks
--export([log/2, adding_handler/2, removing_handler/2,
- changing_config/3, swap_buffer/2]).
+-export([log/2, adding_handler/1, removing_handler/1,
+ changing_config/2, swap_buffer/2]).
%%%===================================================================
%%% API
@@ -109,8 +109,8 @@ reset(Name) ->
%%%-----------------------------------------------------------------
%%% Handler being added
-adding_handler(Name, Config) ->
- case check_config(adding, Name, Config) of
+adding_handler(#{id:=Name}=Config) ->
+ case check_config(adding, Config) of
{ok, Config1} ->
%% create initial handler state by merging defaults with config
HConfig = maps:get(?MODULE, Config1, #{}),
@@ -137,9 +137,8 @@ adding_handler(Name, Config) ->
%%%-----------------------------------------------------------------
%%% Updating handler config
-changing_config(Name,
- OldConfig=#{id:=Id, ?MODULE:=#{type:=Type}},
- NewConfig=#{id:=Id}) ->
+changing_config(OldConfig=#{id:=Name, ?MODULE:=#{type:=Type}},
+ NewConfig=#{id:=Name}) ->
MyConfig = maps:get(?MODULE, NewConfig, #{}),
case maps:get(type, MyConfig, Type) of
Type ->
@@ -149,11 +148,11 @@ changing_config(Name,
_ ->
{error,{illegal_config_change,OldConfig,NewConfig}}
end;
-changing_config(_Name, OldConfig, NewConfig) ->
+changing_config(OldConfig, NewConfig) ->
{error,{illegal_config_change,OldConfig,NewConfig}}.
changing_config1(Name, OldConfig, NewConfig) ->
- case check_config(changing, Name, NewConfig) of
+ case check_config(changing, NewConfig) of
Result = {ok,NewConfig1} ->
try gen_server:call(Name, {change_config,OldConfig,NewConfig1},
?DEFAULT_CALL_TIMEOUT) of
@@ -166,9 +165,7 @@ changing_config1(Name, OldConfig, NewConfig) ->
Error
end.
-check_config(adding, Name, Config0) ->
- %% Merge in defaults on top level
- Config = maps:merge(#{id => Name}, Config0),
+check_config(adding, Config) ->
%% Merge in defaults on handler level
MyConfig0 = maps:get(?MODULE, Config, #{}),
MyConfig = maps:merge(#{type => standard_io},
@@ -179,7 +176,7 @@ check_config(adding, Name, Config0) ->
Error ->
Error
end;
-check_config(changing, _Name, Config) ->
+check_config(changing, Config) ->
MyConfig = maps:get(?MODULE, Config, #{}),
case check_my_config(maps:to_list(MyConfig)) of
ok -> {ok,Config};
@@ -207,7 +204,7 @@ check_my_config([]) ->
%%%-----------------------------------------------------------------
%%% Handler being removed
-removing_handler(Name,_Config) ->
+removing_handler(#{id:=Name}) ->
stop(Name).
%%%-----------------------------------------------------------------
diff --git a/lib/kernel/test/logger_SUITE.erl b/lib/kernel/test/logger_SUITE.erl
index 66eee8219a..f7ec59a7b7 100644
--- a/lib/kernel/test/logger_SUITE.erl
+++ b/lib/kernel/test/logger_SUITE.erl
@@ -839,20 +839,20 @@ check_maps(Expected,Got,What) ->
end.
%% Handler
-adding_handler(_Id,#{add_call:=Fun}) ->
+adding_handler(#{add_call:=Fun}) ->
Fun();
-adding_handler(_Id,Config) ->
+adding_handler(Config) ->
maybe_send(add),
{ok,Config}.
-removing_handler(_Id,#{rem_call:=Fun}) ->
+removing_handler(#{rem_call:=Fun}) ->
Fun();
-removing_handler(_Id,_Config) ->
+removing_handler(_Config) ->
maybe_send(remove),
ok.
-changing_config(_Id,_Old,#{conf_call:=Fun}) ->
+changing_config(_Old,#{conf_call:=Fun}) ->
Fun();
-changing_config(_Id,_Old,Config) ->
+changing_config(_Old,Config) ->
maybe_send(changing_config),
{ok,Config}.
--
cgit v1.2.3
From 51c6464a011eacd78340b60e2641eaecc36933f6 Mon Sep 17 00:00:00 2001
From: Siri Hansen
Date: Mon, 21 May 2018 17:59:10 +0200
Subject: Change env var logger_log_progress to logger_progress_reports
---
lib/kernel/doc/src/kernel_app.xml | 10 +++++-----
lib/kernel/doc/src/logger_chapter.xml | 8 ++++----
lib/kernel/src/kernel.app.src | 2 +-
lib/kernel/src/logger.erl | 6 +++---
lib/kernel/test/logger_env_var_SUITE.erl | 16 ++++++++--------
5 files changed, 21 insertions(+), 21 deletions(-)
(limited to 'lib/kernel')
diff --git a/lib/kernel/doc/src/kernel_app.xml b/lib/kernel/doc/src/kernel_app.xml
index a9292e7660..0f7e95472b 100644
--- a/lib/kernel/doc/src/kernel_app.xml
+++ b/lib/kernel/doc/src/kernel_app.xml
@@ -204,17 +204,17 @@
This configuration option only effects the default
and sasl handler. Any other handlers are uneffected.
If
If
The default value is
The default value is
This configuration option only effects the
The return value of the fun specifies if a log event is to be discarded or forwarded to the handlers:
The filter passed. The next logger filter, if any, is applied. If no more logger filters exist, the @@ -487,7 +487,7 @@ Current logger configuration:
The return value of the fun specifies if a log event is to be discarded or forwarded to the handler callback:
The filter passed. The next handler filter, if
any, is applied. If no more filters exist for this
@@ -929,11 +929,11 @@ logger:set_process_metadata(maps:merge(logger:get_process_metadata(),Meta)).
A handler is defined as a module exporting at least the
following function: This function is called when a log event has passed through all
global filters, and all handler filters attached to the handler
@@ -320,7 +320,7 @@
module, See the The only requirement that a handler MUST fulfill is to export
the following function: It may also implement the following callbacks: A simple handler which prints to file could be implemented like
@@ -782,8 +782,8 @@ removing_handler(#{myhandler_fd:=Fd}) ->
_ = file:close(Fd),
ok.
-log(Log,#{myhandler_fd:=Fd,formatter:={FModule,FConfig}}) ->
- io:put_chars(Fd,FModule:format(Log,FConfig)).
+log(LogEvent,#{myhandler_fd:=Fd,formatter:={FModule,FConfig}}) ->
+ io:put_chars(Fd,FModule:format(LogEvent,FConfig)).
The above handlers do not have any overload
@@ -810,8 +810,8 @@ adding_handler(Config) ->
removing_handler(#{myhandler_pid:=Pid}) ->
gen_server:stop(Pid).
-log(Log,#{myhandler_pid:=Pid} = Config) ->
- gen_server:cast(Pid,{log,Log,Config}).
+log(LogEvent,#{myhandler_pid:=Pid} = Config) ->
+ gen_server:cast(Pid,{log,LogEvent,Config}).
init(#{myhandler_file:=File}) ->
{ok,Fd} = file:open(File,[append,{encoding,utf8}]),
@@ -820,16 +820,16 @@ init(#{myhandler_file:=File}) ->
handle_call(_,_,State) ->
{reply,{error,bad_request},State}.
-handle_cast({log,Log,Config},#{fd:=Fd} = State) ->
- do_log(Fd,Log,Config),
+handle_cast({log,LogEvent,Config},#{fd:=Fd} = State) ->
+ do_log(Fd,LogEvent,Config),
{noreply,State}.
terminate(Reason,#{fd:=Fd}) ->
_ = file:close(Fd),
ok.
-do_log(Fd,Log,#{formatter:={FModule,FConfig}}) ->
- String = FModule:format(Log,FConfig),
+do_log(Fd,LogEvent,#{formatter:={FModule,FConfig}}) ->
+ String = FModule:format(LogEvent,FConfig),
io:put_chars(Fd,String).
diff --git a/lib/kernel/src/error_logger.erl b/lib/kernel/src/error_logger.erl
index 96f6536e61..b3957d0c7e 100644
--- a/lib/kernel/src/error_logger.erl
+++ b/lib/kernel/src/error_logger.erl
@@ -116,7 +116,7 @@ removing_handler(#{id:=?MODULE}) ->
stop(),
ok.
--spec log(logger:log(),logger:config()) -> ok.
+-spec log(logger:log_event(),logger:config()) -> ok.
log(#{level:=Level,msg:=Msg,meta:=Meta},_Config) ->
do_log(Level,Msg,Meta).
diff --git a/lib/kernel/src/logger.erl b/lib/kernel/src/logger.erl
index f35036aa04..12f8dd77cf 100644
--- a/lib/kernel/src/logger.erl
+++ b/lib/kernel/src/logger.erl
@@ -64,11 +64,11 @@
%%%-----------------------------------------------------------------
%%% Types
--type log() :: #{level:=level(),
- msg:={io:format(),[term()]} |
- {report,report()} |
- {string,unicode:chardata()},
- meta:=metadata()}.
+-type log_event() :: #{level:=level(),
+ msg:={io:format(),[term()]} |
+ {report,report()} |
+ {string,unicode:chardata()},
+ meta:=metadata()}.
-type level() :: emergency | alert | critical | error |
warning | notice | info | debug.
-type report() :: map() | [{atom(),term()}].
@@ -87,9 +87,10 @@
line := non_neg_integer()}.
-type handler_id() :: atom().
-type filter_id() :: atom().
--type filter() :: {fun((log(),filter_arg()) -> filter_return()),filter_arg()}.
+-type filter() :: {fun((log_event(),filter_arg()) ->
+ filter_return()),filter_arg()}.
-type filter_arg() :: term().
--type filter_return() :: stop | ignore | log().
+-type filter_return() :: stop | ignore | log_event().
-type config() :: #{id => handler_id(),
level => level(),
filter_default => log | stop,
@@ -101,9 +102,9 @@
-type config_handler() :: {handler, handler_id(), module(), config()}.
--export_type([log/0,level/0,report/0,msg_fun/0,metadata/0,config/0,handler_id/0,
- filter_id/0,filter/0,filter_arg/0,filter_return/0,config_handler/0,
- formatter_config/0]).
+-export_type([log_event/0,level/0,report/0,msg_fun/0,metadata/0,config/0,
+ handler_id/0,filter_id/0,filter/0,filter_arg/0,filter_return/0,
+ config_handler/0,formatter_config/0]).
%%%-----------------------------------------------------------------
%%% API
diff --git a/lib/kernel/src/logger_backend.erl b/lib/kernel/src/logger_backend.erl
index d9f5aa6faf..b3cf7d67dd 100644
--- a/lib/kernel/src/logger_backend.erl
+++ b/lib/kernel/src/logger_backend.erl
@@ -58,7 +58,7 @@ call_handlers(#{level:=Level}=Log,[Id|Handlers],Tid) ->
debug,
[{logger,removed_failing_handler},
{handler,{Id,Module}},
- {log,Log1},
+ {log_event,Log1},
{config,Config1},
{reason,{C,R,filter_stacktrace(S)}}]);
{error,{not_found,_}} ->
@@ -122,7 +122,7 @@ handle_filter_failed({Id,_}=Filter,Owner,Log,Reason) ->
[{logger,removed_failing_filter},
{filter,Filter},
{owner,Owner},
- {log,Log},
+ {log_event,Log},
{reason,Reason}]);
_ ->
ok
diff --git a/lib/kernel/src/logger_disk_log_h.erl b/lib/kernel/src/logger_disk_log_h.erl
index 37a147e3dc..773aa75bc6 100644
--- a/lib/kernel/src/logger_disk_log_h.erl
+++ b/lib/kernel/src/logger_disk_log_h.erl
@@ -235,15 +235,15 @@ swap_buffer(Name,Buffer) ->
%%%-----------------------------------------------------------------
%%% Log a string or report
--spec log(Log, Config) -> ok | dropped when
- Log :: logger:log(),
+-spec log(LogEvent, Config) -> ok | dropped when
+ LogEvent :: logger:log_event(),
Config :: logger:config().
-log(Log,Config=#{id:=Name}) ->
+log(LogEvent,Config=#{id:=Name}) ->
%% if the handler has crashed, we must drop this request
%% and hope the handler restarts so we can try again
true = is_pid(whereis(Name)),
- Bin = logger_h_common:log_to_binary(Log,Config),
+ Bin = logger_h_common:log_to_binary(LogEvent,Config),
logger_h_common:call_cast_or_drop(Name, Bin).
diff --git a/lib/kernel/src/logger_filters.erl b/lib/kernel/src/logger_filters.erl
index 322aa0265d..7359b3b4b7 100644
--- a/lib/kernel/src/logger_filters.erl
+++ b/lib/kernel/src/logger_filters.erl
@@ -27,13 +27,13 @@
-include("logger_internal.hrl").
-define(IS_ACTION(A), (A==log orelse A==stop)).
--spec domain(Log,Extra) -> logger:filter_return() when
- Log :: logger:log(),
+-spec domain(LogEvent,Extra) -> logger:filter_return() when
+ LogEvent :: logger:log_event(),
Extra :: {Action,Compare,MatchDomain},
Action :: log | stop,
Compare :: super | sub | equal | not_equal | undefined,
MatchDomain :: list(atom()).
-domain(#{meta:=Meta}=Log,{Action,Compare,MatchDomain})
+domain(#{meta:=Meta}=LogEvent,{Action,Compare,MatchDomain})
when ?IS_ACTION(Action) andalso
(Compare==super orelse
Compare==sub orelse
@@ -41,17 +41,17 @@ domain(#{meta:=Meta}=Log,{Action,Compare,MatchDomain})
Compare==not_equal orelse
Compare==undefined) andalso
is_list(MatchDomain) ->
- filter_domain(Compare,Meta,MatchDomain,on_match(Action,Log));
-domain(Log,Extra) ->
- erlang:error(badarg,[Log,Extra]).
+ filter_domain(Compare,Meta,MatchDomain,on_match(Action,LogEvent));
+domain(LogEvent,Extra) ->
+ erlang:error(badarg,[LogEvent,Extra]).
--spec level(Log,Extra) -> logger:filter_return() when
- Log :: logger:log(),
+-spec level(LogEvent,Extra) -> logger:filter_return() when
+ LogEvent :: logger:log_event(),
Extra :: {Action,Operator,MatchLevel},
Action :: log | stop,
Operator :: neq | eq | lt | gt | lteq | gteq,
MatchLevel :: logger:level().
-level(#{level:=L1}=Log,{Action,Op,L2})
+level(#{level:=L1}=LogEvent,{Action,Op,L2})
when ?IS_ACTION(Action) andalso
(Op==neq orelse
Op==eq orelse
@@ -60,25 +60,25 @@ level(#{level:=L1}=Log,{Action,Op,L2})
Op==lteq orelse
Op==gteq) andalso
?IS_LEVEL(L2) ->
- filter_level(Op,L1,L2,on_match(Action,Log));
-level(Log,Extra) ->
- erlang:error(badarg,[Log,Extra]).
+ filter_level(Op,L1,L2,on_match(Action,LogEvent));
+level(LogEvent,Extra) ->
+ erlang:error(badarg,[LogEvent,Extra]).
--spec progress(Log,Extra) -> logger:filter_return() when
- Log :: logger:log(),
+-spec progress(LogEvent,Extra) -> logger:filter_return() when
+ LogEvent :: logger:log_event(),
Extra :: log | stop.
-progress(Log,Action) when ?IS_ACTION(Action) ->
- filter_progress(Log,on_match(Action,Log));
-progress(Log,Action) ->
- erlang:error(badarg,[Log,Action]).
+progress(LogEvent,Action) when ?IS_ACTION(Action) ->
+ filter_progress(LogEvent,on_match(Action,LogEvent));
+progress(LogEvent,Action) ->
+ erlang:error(badarg,[LogEvent,Action]).
--spec remote_gl(Log,Extra) -> logger:filter_return() when
- Log :: logger:log(),
+-spec remote_gl(LogEvent,Extra) -> logger:filter_return() when
+ LogEvent :: logger:log_event(),
Extra :: log | stop.
-remote_gl(Log,Action) when ?IS_ACTION(Action) ->
- filter_remote_gl(Log,on_match(Action,Log));
-remote_gl(Log,Action) ->
- erlang:error(badarg,[Log,Action]).
+remote_gl(LogEvent,Action) when ?IS_ACTION(Action) ->
+ filter_remote_gl(LogEvent,on_match(Action,LogEvent));
+remote_gl(LogEvent,Action) ->
+ erlang:error(badarg,[LogEvent,Action]).
%%%-----------------------------------------------------------------
%%% Internal
@@ -123,5 +123,5 @@ filter_remote_gl(#{meta:=#{gl:=GL}},OnMatch) when node(GL)=/=node() ->
filter_remote_gl(_,_) ->
ignore.
-on_match(log,Log) -> Log;
+on_match(log,LogEvent) -> LogEvent;
on_match(stop,_) -> stop.
diff --git a/lib/kernel/src/logger_formatter.erl b/lib/kernel/src/logger_formatter.erl
index 5882c70ddf..95cb6e35fc 100644
--- a/lib/kernel/src/logger_formatter.erl
+++ b/lib/kernel/src/logger_formatter.erl
@@ -30,8 +30,8 @@
%%%-----------------------------------------------------------------
%%% API
--spec format(Log,Config) -> unicode:chardata() when
- Log :: logger:log(),
+-spec format(LogEvent,Config) -> unicode:chardata() when
+ LogEvent :: logger:log_event(),
Config :: #{single_line=>boolean(),
legacy_header=>boolean(),
report_cb=>fun((logger:report()) -> {io:format(),[term()]}),
diff --git a/lib/kernel/src/logger_h_common.erl b/lib/kernel/src/logger_h_common.erl
index 70531c0e34..336398cd4a 100644
--- a/lib/kernel/src/logger_h_common.erl
+++ b/lib/kernel/src/logger_h_common.erl
@@ -39,8 +39,8 @@
%%%-----------------------------------------------------------------
%%% Covert log data on any form to binary
--spec log_to_binary(Log,Config) -> LogString when
- Log :: logger:log(),
+-spec log_to_binary(LogEvent,Config) -> LogString when
+ LogEvent :: logger:log_event(),
Config :: logger:config(),
LogString :: binary().
log_to_binary(#{msg:={report,_},meta:=#{report_cb:=_}}=Log,Config) ->
@@ -58,7 +58,7 @@ do_log_to_binary(Log,Config) ->
catch _:_ ->
?LOG_INTERNAL(debug,[{formatter_error,Formatter},
{config,FormatterConfig},
- {log,Log},
+ {log_event,Log},
{bad_return_value,String}]),
<<"FORMATTER ERROR: bad_return_value">>
end.
@@ -69,7 +69,7 @@ try_format(Log,Formatter,FormatterConfig) ->
C:R:S ->
?LOG_INTERNAL(debug,[{formatter_crashed,Formatter},
{config,FormatterConfig},
- {log,Log},
+ {log_event,Log},
{reason,
{C,R,logger:filter_stacktrace(?MODULE,S)}}]),
case {?DEFAULT_FORMATTER,#{}} of
diff --git a/lib/kernel/src/logger_std_h.erl b/lib/kernel/src/logger_std_h.erl
index fc8ca1535b..63c3ab2dac 100644
--- a/lib/kernel/src/logger_std_h.erl
+++ b/lib/kernel/src/logger_std_h.erl
@@ -219,15 +219,15 @@ swap_buffer(Name,Buffer) ->
%%%-----------------------------------------------------------------
%%% Log a string or report
--spec log(Log, Config) -> ok | dropped when
- Log :: logger:log(),
+-spec log(LogEvent, Config) -> ok | dropped when
+ LogEvent :: logger:log_event(),
Config :: logger:config().
-log(Log,Config=#{id:=Name}) ->
+log(LogEvent,Config=#{id:=Name}) ->
%% if the handler has crashed, we must drop this request
%% and hope the handler restarts so we can try again
true = is_pid(whereis(Name)),
- Bin = logger_h_common:log_to_binary(Log,Config),
+ Bin = logger_h_common:log_to_binary(LogEvent,Config),
logger_h_common:call_cast_or_drop(Name, Bin).
%%%===================================================================
diff --git a/lib/kernel/test/logger_formatter_SUITE.erl b/lib/kernel/test/logger_formatter_SUITE.erl
index eaa6c0aca5..7a93f2ca79 100644
--- a/lib/kernel/test/logger_formatter_SUITE.erl
+++ b/lib/kernel/test/logger_formatter_SUITE.erl
@@ -514,7 +514,7 @@ level_or_msg_in_meta(_Config) ->
ok.
faulty_log(_Config) ->
- %% Unexpected log (should be type logger:log()) - print error
+ %% Unexpected log (should be type logger:log_event()) - print error
{error,
function_clause,
{logger_formatter,format,[_,_],_}} =
--
cgit v1.2.3
From 53539ee751da408029c9dfae80384fdec6c7a552 Mon Sep 17 00:00:00 2001
From: Siri Hansen In OTP-21, a new API for logging was added to Erlang/OTP. The
+ In Erlang/OTP 21.0, a new API for logging was added. The
old The event handler must be able to handle the events in this module, see
section The first time this function is called,
+ Deletes an event handler from the error logger by calling
If no more event handlers exist after the deletion,
+ Sends a standard error event to the error logger.
- The Log a standard error event. The
+ log(logger:log(),logger:config()) ->ok
+ log(logger:log_event(),logger:config()) -> ok
adding_handler(logger:config()) -> {ok,logger:config()} | {error,term()}
@@ -763,8 +763,8 @@ changing_config(logger:config(),logger:config()) -> {ok,logger:config()} | {erro
-module(myhandler).
-export([log/2]).
-log(Log,#{formatter:={FModule,FConfig}) ->
- io:put_chars(FModule:format(Log,FConfig)).
+log(LogEvent,#{formatter:={FModule,FConfig}) ->
+ io:put_chars(FModule:format(LogEvent,FConfig)).
Error logger forwards the event to Logger, including + metadata that allows backwards compatibility with legacy + error logger event handlers.
+The event is handled by the default Logger handler.
+These functions are kept for backwards compatibility and
+ must not be used by new code. Use the
Example:
-1> error_logger:error_msg("An error occurred in ~p~n", [a_module]).
-
-=ERROR REPORT==== 11-Aug-2005::14:03:19 ===
+1> error_logger:error_msg("An error occurred in ~p", [a_module]).
+=ERROR REPORT==== 22-May-2018::11:18:43.376917 ===
An error occurred in a_module
ok
- If called with bad arguments, this function can crash
- the standard event handler, meaning no further events are
- logged. When in doubt, use
-
If the Unicode translation modifier (
Sends a standard error report event to the error logger. - The event is handled by the standard event handler.
+Log a standard error event. Error logger forwards the event + to Logger, including metadata that allows backwards + compatibility with legacy error logger event handlers.
+The event is handled by the default Logger handler.
+This functions is kept for backwards compatibility and
+ must not be used by new code. Use the
Example:
2> error_logger:error_report([{tag1,data1},a_term,{tag2,data}]).
-
-=ERROR REPORT==== 11-Aug-2005::13:45:41 ===
+=ERROR REPORT==== 22-May-2018::11:24:23.699306 ===
tag1: data1
a_term
tag2: data
ok
3> error_logger:error_report("Serious error in my module").
-
-=ERROR REPORT==== 11-Aug-2005::13:45:49 ===
+=ERROR REPORT==== 22-May-2018::11:24:45.972445 ===
Serious error in my module
ok
Sends a user-defined error report event to the error logger. - An event handler to handle the event is supposed to have been - added. The event is ignored by the standard event handler.
+Log a user-defined error event. Error logger forwards the + event to Logger, including metadata that allows backwards + compatibility with legacy error logger event handlers.
+Error logger also adds a
It is recommended that
This functions is kept for backwards compatibility and
+ must not be used by new code. Use the
The
Sends a standard information event to the error logger.
- The
Log a standard information event. The
Error logger forwards the event to Logger, including + metadata that allows backwards compatibility with legacy + error logger event handlers.
+The event is handled by the default Logger handler.
+These functions are kept for backwards compatibility and
+ must not be used by new code. Use the
Example:
-1> error_logger:info_msg("Something happened in ~p~n", [a_module]).
-
-=INFO REPORT==== 11-Aug-2005::14:06:15 ===
+1> error_logger:info_msg("Something happened in ~p", [a_module]).
+=INFO REPORT==== 22-May-2018::12:03:32.612462 ===
Something happened in a_module
ok
- If called with bad arguments, this function can crash
- the standard event handler, meaning no further events are
- logged. When in doubt, use
If the Unicode translation modifier (
Sends a standard information report event to the error - logger. The event is handled by the standard event handler.
+Log a standard information event. Error logger forwards the + event to Logger, including metadata that allows backwards + compatibility with legacy error logger event handlers.
+The event is handled by the default Logger handler.
+This functions is kept for backwards compatibility and
+ must not be used by new code. Use the
Example:
2> error_logger:info_report([{tag1,data1},a_term,{tag2,data}]).
-
-=INFO REPORT==== 11-Aug-2005::13:55:09 ===
+=INFO REPORT==== 22-May-2018::12:06:35.994440 ===
tag1: data1
a_term
tag2: data
ok
3> error_logger:info_report("Something strange happened").
-
-=INFO REPORT==== 11-Aug-2005::13:55:36 ===
+=INFO REPORT==== 22-May-2018::12:06:49.066872 ===
Something strange happened
ok
Sends a user-defined information report event to the error - logger. An event handler to handle the event is supposed to - have been added. The event is ignored by the standard event - handler.
+Log a user-defined information event. Error logger forwards + the event to Logger, including metadata that allows + backwards compatibility with legacy error logger event + handlers.
+Error logger also adds a
It is recommended that
This functions is kept for backwards compatibility and
+ must not be used by new code. Use the
Sends a standard warning event to the error logger.
- The
Log a standard warning event. The
Error logger forwards the event to Logger, including + metadata that allows backwards compatibility with legacy + error logger event handlers.
+The event is handled by the default Logger handler. The log
+ level can be changed to error or info, see
If called with bad arguments, this function can crash
- the standard event handler, meaning no further events are
- logged. When in doubt, use
These functions are kept for backwards compatibility and
+ must not be used by new code. Use the
If the Unicode translation modifier (
Sends a standard warning report event to the error logger. - The event is handled by the standard event handler. It is - tagged as an error, warning, or info, see +
Log a standard warning event. Error logger forwards the event + to Logger, including metadata that allows backwards + compatibility with legacy error logger event handlers.
+The event is handled by the default Logger handler. The log
+ level can be changed to error or info, see
This functions is kept for backwards compatibility and
+ must not be used by new code. Use the
Sends a user-defined warning report event to the error - logger. An event handler to handle the event is supposed to - have been added. The event is ignored by the standard event - handler. It is tagged as an error, warning, or info, - depending on the value of +
Log a user-defined warning event. Error logger forwards the + event to Logger, including metadata that allows backwards + compatibility with legacy error logger event handlers.
+Error logger also adds a
The log level can be changed to error or info, see
It is recommended that
This functions is kept for backwards compatibility and
+ must not be used by new code. Use the
In OTP-21, a new API for logging was added to Erlang/OTP. The +
In Erlang/OTP 21.0, a new API for logging was added. The
old
The following application configuration parameters can still be - set, but they will only be used if the corresponding new logger - variables are not set.
+ set, but they are only used if the corresponding configuration + parameters for Logger are not set.The following custom metadata keys have special meaning:
+The value associated with this key is used by filters
+ for grouping log events originating from, for example,
+ specific functional
+ areas. See
If the log message is specified as
+ a
See the See the This callback function is optional. The function is called by a Logger when formatter
+ configuration is set or modified. The formatter must
+ validate the given configuration and return See As of OTP-21, Erlang/OTP provides a standard API for logging
+ Erlang/OTP 21.0 provides a new standard API for logging
through In accordance with the Syslog protocol, RFC-5424, eight log
- levels can be specified: A log event passes the level check if the integer value of its
- log level is less than or equal to the currently configured log
- level, that is, if the event is equally or more severe than the
- configured level. Log levels are expressed as atoms. Internally in Logger, the
+ atoms are mapped to integer values, and a log event passes the
+ log level check if the integer value of its log level is less
+ than or equal to the currently configured log level. That is,
+ the check pases if the event is equally or more severe than the
+ configured level. See section The global log level can be overridden by a log level
configured per module. This is to, for instance, allow more
verbose logging from a specific part of the system.
-
-
-
Everything upto and including the call to the handler callbacks - is executed on the client process, that is, the process where - the log event was issued. It is up to the handler implementation - if other processes are to be involved or not.
+Everything up to and including the call to the handler + callbacks is executed on the client process, that is, the + process where the log event was issued. It is up to the handler + implementation if other processes are involved or not.
The handlers are called in sequence, and the order is not defined.
+The API for logging consists of a set
+ of
The difference between using the macros and the exported + functions is that macros add location (originator) information + to the metadata, and performs lazy evaluation by wrapping the + logger call in a case statement, so it is only evaluated if the + log level of the event passes the global log level check.
+The log level indicates the severity of a event. In + accordance with the Syslog protocol, RFC-5424, eight log + levels can be specified. The following table lists all + possible log levels by name (atom), integer value, and + description:
+ +Notice that the integer value is only used internally in
+ Logger. In the API, you must always use the atom. To compare
+ the severity of two log levels,
+ use
The log message contains the information to be logged. The
+ message can consist of a format string and arguments (given as
+ two separate parameters in the Logger API), a string or a
+ report. The latter, which is either a map or a key-value list,
+ can be accompanied by a report callback specified in the log
+ event's
Example, format string and arguments:
+logger:error("The file does not exist: ~ts",[Filename])
+ Example, string:
+logger:notice("Something strange happened!")
+ Example, report, and metadata with report callback:
+
+logger:debug(#{got => connection_request, id => Id, state => State},
+ #{report_cb => fun(R) -> {"~p",[R]} end})
+ The log message can also be provided through a fun for lazy + evaluation. The fun is only evaluated if the global log level + check passes, and is therefore recommended if it is expensive + to generate the message. The lazy fun must return a string, a + report, or a tuple with format string and arguments.
+Metadata contains additional data associated with a log + message. Logger inserts some metadata fields by default, and + the client can add custom metadata in two different ways:
+Process metadata is set and updated
+ with
Metadata associated with one specifc log event is given + as the last parameter to the log macro or Logger API + function when the event is issued. For example:
+?LOG_ERROR("Connection closed",#{context => server})
+ See the description of
+ the
If the log event is returned, the next filter function is called with the returned value as the first argument. That is, if a filter function modifies the log event, the next filter - function receivea the modified event. The value returned from - the last filter funcion is the value that the handler callback + function receives the modified event. The value returned from + the last filter function is the value that the handler callback receives.
If the filter function returns
The configuration
option
Filters are applied in the reverse order of installation, - meaning that the last added filter is applied first.
- + returnGlobal filters are added
with
Handler filters are added with +
Handler filters are added
with
To see which filters are currently installed in the system,
@@ -215,35 +300,37 @@
For convenience, the following built-in filters exist:
-Provides a way of filtering log events based on a
+
Provides a way of filtering log events based on the log + level.
+Stops or allows progress reports from
Stops or allows log events originating from a process + that has its group leader on a remote node.
+A handler is defined as a module exporting at least the following function:
-+log(LogEvent, Config)
log(LogEvent, Config) -> void()
This function is called when a log event has passed through all global filters, and all handler filters attached to the handler in question. The function call is executed on the client process, and it is up to the handler implementation if other - processes are to be involved or not.
+ processes are involved or not.Logger allows adding multiple instances of a handler - callback. That is, the callback module might be implemented in - such a way that, by using different handler identities, the same - callback module can be used for multiple handler - instances. Handler configuration is per instance.
+ callback. That is, if a callback module implementation allows + it, you can add multiple handler instances using the same + callback module. The different instances are identified by + unique handler identities.In addition to the mandatory callback function This is the default handler used by OTP. Multiple instances
can be started, and each instance will write log events to a
- given destination, console or file. Filters can be used for
- selecting which event to send to which handler instance.
This handler behaves much like logger_std_h, except it uses +
This handler behaves much like
This handler is to be used for backwards compatibility +
This handler is provided for backwards compatibility
only. It is not started by default, but will be
automatically started the first time an
The old
A formatter can be used by the handler implementation to do the
final formatting of a log event, before printing to the
- handler's destination. The handler callback gets the formatter
- information in the handler configuration, which is passed as the
- second argument to
The formatter information consits of a formatter
module,
-format(LogEvent,FConfig) -> FormattedLogEntry
See the
The formatter information for a handler is set as a part of its
+ configuration when the handler is added. It can also be changed
+ during runtime
+ with
If the formatter module exports the optional callback
+ function
If no formatter information is specified for a handler, Logger
+ uses
Specifies the global log level to log.
-See table
See section
The initial value of this option is set by the Kernel
configuration
parameter Specifies what to do with an event if all filters
- return
See section
Default is
Specifies the log level which the handler logs.
-See table
See section
The log level can be specified when adding the handler,
or changed during runtime with, for
instance, Specifies what to do with an event if all filters
- return
See section
Default is
Logger provides backwards compatibility with the old +
Logger provides backwards compatibility with
The old
The
Calls
to To get log events on the same format as produced
by
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 behaviour is as follows:
+As of Erlang/OTP 21.0, the concept of SASL reports is + removed, meaning that the default behaviour is as + follows:
All SASL reports have a metadata
- field
See the
-#{level=>info,
- filter_default=>log,
- filters=>[]}.
+#{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 @@ -686,18 +790,17 @@ error_logger:add_report_handler/1,2. that it does not crash due to bad input data or faulty callbacks.
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, - and can be seen if a handler is installed which logs on debug - level.
+ filter or handler in question from the configuration, and print + a short error message to the terminal. A debug event containing + the crash reason and other details is also issued, and can be + seen if a handler logging debug events is installed.When starting an erlang node, the default behaviour 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
+ terminal. In order to also log debug events, you can either
change the global log level to
-1> Config = #{level=>debug,logger_std_h=>#{type=>{file,"./debug.log"}}}.
+1> Config = #{level => debug, logger_std_h => #{type => {file,"./debug.log"}}}.
#{logger_std_h => #{type => {file,"./debug.log"}},
level => debug}
2> logger:add_handler(debug_handler,logger_std_h,Config).
ok
By default, the handler receives all events
- (
-3> Fun = fun(#{level:=debug}=Log,_) -> Log; (_,_) -> stop end.
-#Fun<erl_eval.12.98642416>
-4> logger:add_handler_filter(debug_handler,allow_debug,{Fun,[]}).
+3> logger:add_handler_filter(debug_handler,stop_non_debug,
+ {fun logger_filters:level/2,{stop,neq,debug}}).
ok
And finally, we need to make sure that Logger itself allows debug events. This can either be done by setting the global log level:
-5> logger:set_logger_config(level,debug). +4> logger:set_logger_config(level,debug). ok
Or by allowing debug events from one or a few modules only:
-6> logger:set_module_level(mymodule,debug). +5> logger:set_module_level(mymodule,debug). ok
The only requirement that a handler MUST fulfill is to export the following function:
log(logger:log_event(),logger:config()) -> ok
- It may also implement the following callbacks:
+It can optionally also implement the following callbacks:
adding_handler(logger:config()) -> {ok,logger:config()} | {error,term()}
removing_handler(logger:config()) -> ok
changing_config(logger:config(),logger:config()) -> {ok,logger:config()} | {error,term()}
- When
When
A handler can be removed by calling
-
When
A simple handler that prints to the console could be - implemented as follows:
+A simple handler that prints to the terminal can be implemented + as follows:
-module(myhandler).
-export([log/2]).
@@ -776,7 +885,7 @@ log(LogEvent,#{formatter:={FModule,FConfig}) ->
adding_handler(Config) ->
{ok,Fd} = file:open(File,[append,{encoding,utf8}]),
- {ok,Config#{myhandler_fd=>Fd}}.
+ {ok,Config#{myhandler_fd => Fd}}.
removing_handler(#{myhandler_fd:=Fd}) ->
_ = file:close(Fd),
@@ -790,10 +899,12 @@ log(LogEvent,#{myhandler_fd:=Fd,formatter:={FModule,FConfig}}) ->
protection, and all log events are printed directly from the
client process.
- For examples of overload protection, please refer to the
- implementation
- of logger_std_h
- and logger_disk_log_h
+ For information and examples of overload protection, please
+ refer to
+ section Protecting the
+ Handler from Overload , and the implementation
+ of logger_std_h(3)
+ and logger_disk_log_h(3)
.
Below is a simpler example of a handler which logs through one
@@ -805,7 +916,7 @@ log(LogEvent,#{myhandler_fd:=Fd,formatter:={FModule,FConfig}}) ->
adding_handler(Config) ->
{ok,Pid} = gen_server:start(?MODULE,Config),
- {ok,Config#{myhandler_pid=>Pid}}.
+ {ok,Config#{myhandler_pid => Pid}}.
removing_handler(#{myhandler_pid:=Pid}) ->
gen_server:stop(Pid).
@@ -815,7 +926,7 @@ log(LogEvent,#{myhandler_pid:=Pid} = Config) ->
init(#{myhandler_file:=File}) ->
{ok,Fd} = file:open(File,[append,{encoding,utf8}]),
- {ok,#{file=>File,fd=>Fd}}.
+ {ok,#{file => File, fd => Fd}}.
handle_call(_,_,State) ->
{reply,{error,bad_request},State}.
@@ -949,7 +1060,7 @@ logger:add_handler(my_standard_h, logger_std_h,
both built-in handlers offer the possibility to set a maximum level of how
many requests to process with a certain time frame. With this burst control
feature enabled, the handler will take care of bursts of log requests
- without choking log files, or the console, with massive amounts of
+ without choking log files, or the terminal, with massive amounts of
printouts. These are the configuration parameters:
diff --git a/lib/kernel/doc/src/logger_formatter.xml b/lib/kernel/doc/src/logger_formatter.xml
index ee43634cf9..02f89b26be 100644
--- a/lib/kernel/doc/src/logger_formatter.xml
+++ b/lib/kernel/doc/src/logger_formatter.xml
@@ -46,97 +46,150 @@
Logger.
-
- Configuration
- The configuration term for logger_formatter is a
- map ,
- and the following keys can be set as configuration
- parameters:
-
- chars_limit = pos_integer() | unlimited
- -
-
A positive integer representing the value of the option
- with the same name to be used when calling
- io_lib:format/3 .
- This value limits the total number of characters printed
- for each log event. Notice that this is a soft limit. For a
- hard truncation limit, see option max_size .
- Default is unlimited .
-
- chars_limit has no effect on log messages on
- string form. These are expected to be short, but can still
- be truncated by the max_size parameter.
-
-
- depth = pos_integer() | unlimited
- -
-
A positive integer representing the maximum depth to
- which terms shall be printed by this formatter. Format
- strings passed to this formatter are rewritten. The format
- controls ~p and ~w are replaced with ~P and ~W,
- respectively, and the value is used as the depth
- parameter. For details, see
- io:format/2,3
- in STDLIB.
- Default is unlimited .
-
- depth has no effect on log messages on string
- form. These are expected to be short, but can still be
- truncated by the max_size parameter.
-
-
- max_size = pos_integer() | unlimited
- -
-
A positive integer representing the absolute maximum size a
- string returned from this formatter can have. If the
- formatted string is longer, after possibly being limited
- by chars_limit or depth , it is truncated.
- Default is unlimited .
-
- single_line = boolean()
- -
-
If set to true , all newlines in the message are
- replaced with ", " , and whitespaces following
- directly after newlines are removed. Note that newlines
- added by the template parameter are not replaced.
- Default is true .
-
- legacy_header = boolean()
- -
-
If set to true a header field is added to
- logger_formatter's part of Metadata . The value of
- this field is a string similar to the header created by the
- old error_logger event handlers. It can be included
- in the log event by adding the
- tuple {logger_formatter,header} to the template. See
- section Default
- Templates for more information.
- Default is false .
-
- report_cb = fun(( logger:report() ) -> { io:format() ,[term()]})
- -
-
A report callback is used by the formatter to transform log
- messages on report form to a format string and
- arguments. The report callback can be specified in the
- metadata for the log event. If no report callback exist in
- metadata, logger_formatter will
- use
- logger:format_report/1 as default
- callback.
- If this configuration parameter is set, it replaces both
- the default report callback, and any report callback found
- in metadata. That is, all reports are converted by this
- configured function.
- The value must be a function with arity 1,
- returning {Format,Args} , and it will be called with a
- report as only argument.
-
- template = template()
- -
+
+
+
+
+
+ The configuration term for logger_formatter is a
+ map , and the
+ following keys can be set as configuration parameters:
+
+ chars_limit = pos_integer() | unlimited
+ -
+
A positive integer representing the value of the option
+ with the same name to be used when calling
+
+ io_lib:format/3 .
+ This value limits the total number of characters printed
+ for each log event. Notice that this is a soft limit. For a
+ hard truncation limit, see option max_size .
+ Defaults to unlimited .
+
+ chars_limit has no effect on log messages on
+ string form. These are expected to be short, but can
+ still be truncated by the max_size
+ parameter.
+
+
+ depth = pos_integer() | unlimited
+ -
+
A positive integer representing the maximum depth to
+ which terms shall be printed by this formatter. Format
+ strings passed to this formatter are rewritten. The
+ format controls ~p and ~w are replaced with ~P and ~W,
+ respectively, and the value is used as the depth
+ parameter. For details, see
+ io:format/2,3
+ in STDLIB.
+ Defaults to unlimited .
+
+ depth has no effect on log messages on string
+ form. These are expected to be short, but can still be
+ truncated by the max_size parameter.
+
+
+ legacy_header = boolean()
+ -
+
If set to true a header field is added to
+ logger_formatter's part of Metadata . The value of
+ this field is a string similar to the header created by
+ the old error_logger event handlers. It can be
+ included in the log event by adding the
+ tuple {logger_formatter,header} to the
+ template. See the description of
+ the template()
+ type for more information.
+ Defaults to false .
+
+ max_size = pos_integer() | unlimited
+ -
+
A positive integer representing the absolute maximum size a
+ string returned from this formatter can have. If the
+ formatted string is longer, after possibly being limited
+ by chars_limit or depth , it is truncated.
+ Defaults to unlimited .
+
+ report_cb = fun(( logger:report() ) -> { io:format() ,[term()]})
+ -
+
A report callback is used by the formatter to transform
+ log messages on report form to a format string and
+ arguments. The report callback can be specified in the
+ metadata for the log event. If no report callback exist
+ in metadata, logger_formatter will
+ use
+ logger:format_report/1 as default
+ callback.
+ If this configuration parameter is set, it replaces
+ both the default report callback, and any report
+ callback found in metadata. That is, all reports are
+ converted by this configured function.
+ The value must be a function with arity 1,
+ returning {Format,Args} , and it will be called
+ with a report as only argument.
+
+ single_line = boolean()
+ -
+
If set to true , all newlines in the message are
+ replaced with ", " , and whitespaces following
+ directly after newlines are removed. Note that newlines
+ added by the template parameter are not replaced.
+ Defaults to true .
+
+ template = template()
+ -
+
The template describes how the formatted string is
+ composed by combining different data values from the log
+ event. See the description of
+ the template()
+ type for more information about this.
+
+ time_designator = byte()
+ -
+
Timestamps are formatted according to RFC3339, and the
+ time designator is the character used as date and time
+ separator.
+ Defaults to $T .
+ The value of this parameter is used as
+ the time_designator option
+ to
+ calendar:system_time_to_rcf3339/2 .
+
+ time_offset = integer() | [byte()]
+ -
+
The time offset, either a string or an integer, to be
+ used when formatting the timestamp.
+ An empty string is interpreted as local time. The
+ values "Z" , "z" or 0 are
+ interpreted as Universal Coordinated Time (UTC).
+ Strings, other than "Z" , "z" ,
+ or "" , must be on the form ±[hh]:[mm] , for
+ example "-02:00" or "+00:00" .
+ Integers must be in microseconds, meaning that the
+ offset 7200000000 is equivalent
+ to "+02:00" .
+ Defaults to an empty string, meaning that timestamps
+ are displayed in local time. However, for backwards
+ compatibility, if the SASL configuration
+ parameter
+ utc_log =true , the default is
+ changed to "Z" , meaning that timestamps are displayed
+ in UTC.
+ The value of this parameter is used as
+ the offset option
+ to
+ calendar:system_time_to_rcf3339/2 .
+
+
+
+
+
+
+
The template is a list of atoms, tuples and strings. The
atoms level or msg , are treated as
placeholders for the severity level and the log message,
- repectively. Other atoms or tuples are interpreted as
+ respectively. Other atoms or tuples are interpreted as
placeholders for metadata, where atoms are expected to match
top level keys, and tuples represent paths to sub keys when
the metadata is a nested map. For example the
@@ -154,120 +207,84 @@
Strings in the template are printed literally.
The default template differs depending on the values
of legacy_header
- and single_line . See Default
- Templates for more information
-
- time_designator = byte()
- -
-
Timestamps are formatted according to RFC3339, and the time
- designator is the character used as date and time
- separator.
- Default is $T .
- The value of this parameter is used as
- the time_designator option
- to
- calendar:system_time_to_rcf3339/2 .
-
- time_offset = integer() | [byte()]
- -
-
The time offset, either a string or an integer, to be
- used when formatting the timestamp.
- An empty string is interpreted as local time. The
- values "Z" , "z" or 0 are interpreted as
- Universal Coordinated Time (UTC).
- Strings, other than "Z" , "z" , or "" ,
- must be on the form ±[hh]:[mm] , for
- example "-02:00" or "+00:00" .
- Integers must be in microseconds, meaning that the
- offset 7200000000 is equivalent
- to "+02:00" .
- The default value is an empty string, meaning that
- timestamps are displayed in local time. However, for
- backwards compatibility, if the SASL configuration
- parameter
- utc_log =true , the default is
- changed to "Z" , meaning that timestamps are displayed
- in UTC.
- The value of this parameter is used as the offset
- option to
- calendar:system_time_to_rcf3339/2 .
-
-
-
-
-
-
- Default templates
+ and single_line :
- The default value for the template configuration
- parameter depends on the value of single_line
- and legacy_header as follows.
+ The default value for the template configuration
+ parameter depends on the value of the single_line
+ and legacy_header configuration parameters as
+ follows.
- The log event used in the examples is:
-
+ The log event used in the examples is:
+
?LOG_ERROR("name: ~p~nexit_reason: ~p",[my_name,"It crashed"])
-
- legacy_header=true, single_line=false
- -
-
Default template: [{logger_formatter,header},"\n",msg,"\n"]
+
+ legacy_header=true, single_line=false
+ -
+
Default
+ template: [{logger_formatter,header},"\n",msg,"\n"]
- Example log entry:
-
+ Example log entry:
+
=ERROR REPORT==== 17-May-2018::18:30:19.453447 ===
name: my_name
exit_reason: "It crashed"
- Notice that all eight levels can occur in the heading,
- not only ERROR , WARNING or INFO as the
- old error_logger produced. And microseconds are
- added at the end of the timestamp.
-
+ Notice that all eight levels can occur in the heading,
+ not only ERROR , WARNING or INFO as the
+ old error_logger produced. And microseconds are
+ added at the end of the timestamp.
+
- legacy_header=true, single_line=true
- -
-
Default template: [{logger_formatter,header},"\n",msg,"\n"]
+ legacy_header=true, single_line=true
+ -
+
Default
+ template: [{logger_formatter,header},"\n",msg,"\n"]
- Notice that the template is here the same as
- for single_line=false , but the resulting log entry
- differs in that there is only one line after the
- heading:
-
+ Notice that the template is here the same as
+ for single_line=false , but the resulting log entry
+ differs in that there is only one line after the
+ heading:
+
=ERROR REPORT==== 17-May-2018::18:31:06.952665 ===
name: my_name, exit_reason: "It crashed"
-
+
- legacy_header=false, single_line=true
- -
-
Default template: [time," ",level,": ",msg,"\n"]
+ legacy_header=false, single_line=true
+ -
+
Default template: [time," ",level,": ",msg,"\n"]
- Example log entry:
-
+ Example log entry:
+
2018-05-17T18:31:31.152864+02:00 error: name: my_name, exit_reason: "It crashed"
-
+
- legacy_header=false, single_line=false
- -
-
Default template: [time," ",level,":\n",msg,"\n"]
+ legacy_header=false, single_line=false
+ -
+
Default template: [time," ",level,":\n",msg,"\n"]
- Example log entry:
-
+ Example log entry:
+
2018-05-17T18:32:20.105422+02:00 error:
name: my_name
exit_reason: "It crashed"
-
-
-
-
-
-
-
-
+ This callback function is called by Logger when the
+ formatter configuration for a handler is set or modified. It
+ returns