This module implements the main API for logging in
Erlang/OTP. To create a log event, use the
?LOG_ERROR("error happened because: ~p", [Reason]). % With macro
logger:error("error happened because: ~p", [Reason]). % Without macro
To configure the Logger backend,
use
By default, the Kernel application installs one log handler at
system start. This handler is named
If you want your systems logs to be printed to a file instead,
you must configure the default handler to do so. The simplest
way is to include the following in
your
[{kernel,
[{logger,
[{handler, default, logger_std_h,
#{config => #{type => {file, "path/to/file.log"}}}}]}]}].
For more information about:
Since Logger is new in Erlang/OTP 21.0, we do reserve the right to introduce changes to the Logger API and functionality in patches following this release. These changes might or might not be backwards compatible with the initial version.
A filter which can be installed as a handler filter, or as a primary filter in Logger.
The second argument to the filter fun.
A unique identifier for a filter.
The return value from the filter fun.
Configuration data for the
formatter. See
Handler configuration data for Logger. The following default values apply:
In addition to these, the following fields are
automatically inserted by Logger, values taken from the
two first parameters
to
These are read-only and cannot be changed in runtime.
Handler specific configuration data is inserted by the
handler callback itself, in a sub structure associated with
the field named
See the
A unique identifier for a handler instance.
The severity level for the message to be logged.
Metadata for the log event.
Logger adds the following metadata to each log event:
When a log macro is used, Logger also inserts location information:
You can add custom metadata, either by specifying a map as
the last parameter to any of the log macros or the API
functions, or by setting process metadata
with
Logger merges all the metadata maps before forwarding the log event to the handlers. If the same keys occur, values from the log call overwrite process metadata, which in turn overwrite values set by Logger.
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
Primary configuration data for Logger. The following default values apply:
A fun which converts a
A timestamp produced
with
The following macros are defined:
All macros expand to a call to Logger, where
The call is wrapped in a case statement and will be evaluated
only if
Equivalent to
Equivalent to
Equivalent to
Equivalent to
Equivalent to
Equivalent to
Equivalent to
Equivalent to
Log the given message.
Add a handler with the given configuration.
Add a filter to the specified handler.
The filter fun is called with the log event as the first
parameter, and the specified
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 handler, the log event is forwarded to the handler callback.
The filter did not pass, and the log event is immediately discarded.
The filter has no knowledge of the log event. The next
handler filter, if any, is applied. If no more filters
exist for this handler, the value of
the
See
section
Some built-in filters exist. These are defined in
Reads the application configuration parameter
This function should be used by custom Logger handlers to make
configuration consistent no matter which handler the system uses.
Normal usage is to add a call to
-behaviour(application).
start(_, []) ->
case supervisor:start_link({local, my_sup}, my_sup, []) of
{ok, Pid} ->
ok = logger:add_handlers(my_app),
{ok, Pid, []};
Error -> Error
end.
This reads the
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
[{handler, default, undefined}]}]},
{my_app,
[{logger,
%% Enable this handler as the default
[{handler, default, my_handler, #{}}]}]}].
Add a primary filter to Logger.
The filter fun is called with the log event as the first
parameter, and the specified
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 primary filter, if any, is applied. If no more primary filters exist, the log event is forwarded to the handler part of Logger, where handler filters are applied.
The filter did not pass, and the log event is immediately discarded.
The filter has no knowledge of the log event. The next
primary filter, if any, is applied. If no more primary
filters exist, the value of the
primary
See section
Some built-in filters exist. These are defined
in
Look up all current Logger configuration, including primary and handler configuration, and module level settings.
Look up the current configuration for all handlers.
Look up the current configuration for the given handler.
Look up the identities for all installed handlers.
Look up the current primary configuration for Logger.
Look up all current module levels. Returns a list
containing one
Look up the current level for the given modules. Returns a
list containing one
Retrieve data set
with
Remove the handler identified by
Remove the filter identified
by
Remove the primary filter identified
by
Set the log level for all the modules of the specified application.
This function is a convenience function that calls
Set configuration data for the specified handler. This overwrites the current handler configuration.
To modify the existing configuration,
use
If a key is removed compared to the current configuration, 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.
Add or update configuration data for the specified
handler. If the given
See the definition of
the
Set primary configuration data for Logger. This overwrites the current configuration.
To modify the existing configuration,
use
If a key is removed compared to the current configuration, the default value is used.
Add or update primary configuration data for Logger. If the
given
Set the log level for the specified modules.
The log level for a module overrides the primary log level 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 primary log level for Logger
is
With this configuration, no debug messages will be logged, since they are all stopped by the primary log level.
If the level for
Debug events from other modules are still not logged.
To change the primary log level for Logger, use
To change the log level for a handler, use
The originating module for a log event is only detected
if the key
Set metadata which Logger shall automatically insert in all log events produced on the current process.
Location data produced by the log macros, and/or metadata given as argument to the log call (API function or macro), are merged with the process metadata. If the same keys occur, values from the metadata argument to the log call overwrite values from the process metadata, which in turn overwrite values from the location data.
Subsequent calls to this function overwrites previous data
set. To update existing data instead of overwriting it,
see
Unset the log level for all the modules of the specified application.
This function is a convinience function that calls
Remove module specific log settings. After this, the primary log level is used for all modules.
Remove module specific log settings. After this, the primary log level is used for the specified modules.
Delete data set
with
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
set_handler_config(HandlerId, formatter, {FormatterModule, FormatterConfig}) .
Update the formatter configuration for the specified handler.
This is equivalent to
update_formatter_config( HandlerId , #{Key =>Value })
Update configuration data for the specified handler. This function behaves as if it was implemented as follows:
{ok, {_, Old}} = logger:get_handler_config(HandlerId),
logger:set_handler_config(HandlerId, maps:merge(Old, Config)).
To overwrite the existing configuration without any merge,
use
Update primary configuration data for Logger. This function behaves as if it was implemented as follows:
Old = logger:get_primary_config(),
logger:set_primary_config(maps:merge(Old, Config)).
To overwrite the existing configuration without any merge,
use
Set or update metadata to use when logging from current process
If process metadata exists for the current process, this function behaves as if it was implemented as follows:
logger:set_process_metadata(maps:merge(logger:get_process_metadata(), Meta)).
If no process metadata exists, the function behaves as
Compare the severity of two log levels. Returns
Convert a log message on report form to
The function produces lines of
If
The following functions are to be exported from a handler callback module.
This callback function is optional.
The function is called on a temporary process when an new handler is about to be added. 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
in
If the configuration is faulty, or if the initiation fails,
the callback function must return
This callback function is optional.
The function is called on a temporary process when the configuration for a handler is about to change. The purpose is to verify and act on the new configuration.
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
return
This callback function is mandatory.
The function is called when all primary filters and all handler filters for the handler in question have passed for the given log event. It is called on the client process, that is, the process that issued the 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.
This callback function is optional.
The function is called on a temporary process when a handler is about to be removed. The purpose is to release all resources used by the handler.
The handler identity is associated with the
The return value is ignored by Logger.
The following functions are to be exported from a formatter callback module.
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
The following Logger API functions can trigger this callback:
See
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