2017 Ericsson AB. All Rights Reserved. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. logger A logger.xml
logger API module for logging in Erlang/OTP.

This module is the main API for logging in Erlang/OTP. It contains functions that allow applications to use a single log API and the system to manage those log events independently. Use the API functions or the log macros to log events. For instance, to log a new error event:

?LOG_ERROR("error happened because: ~p",[Reason]). %% With macro logger:error("error happened because: ~p",[Reason]). %% Without macro

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 must configure the default handler to do so. The simplest way is to include the following in your sys.config.

[{kernel, [{logger, [{handler,default,logger_std_h, #{logger_std_h=>#{type=>{file,"path/to/file.log"}}}}]}]}].

For more information about:

how to use the API, see the User's Guide. how to configure Logger, see the Configuration section in the User's Guide. the convinience macros in logger.hrl, see the macro section. what the builtin formatter can do, see logger_formatter. what the builtin handlers can do, see logger_std_h and logger_disk_log_h. what builtin filters are available, see logger_filters.

The severity level for the message to be logged.

Metadata for the log event.

Logger adds the following metadata to each log event:

pid => self() gl => group_leader() time => erlang:system_time(microsecond)

When a log macro is used, Logger also inserts location information:

mfa => {?MODULE,?FUNCTION_NAME,?FUNCTION_ARITY} file => ?FILE line => ?LINE

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 set_process_metadata/1 or 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 overwrite process metadata, which in turn overwrite values set by Logger.

Configuration data for the logger part of Logger, or for a handler.

The following default values apply:

level => info filter_default => log filters => [] formatter => {logger_formatter,DefaultFormatterConfig}

See the logger_formatter(3) manual page for information about the default configuration for this formatter.

A unique identifier for a handler instance.

A unique identifier for a filter.

A filter which can be installed for the logger part of Logger, or for a handler.

The second argument to the filter fun.

The return value from the filter fun.

A timestamp produced with erlang:system_time(microsecond).

Configuration data for the formatter. See logger_formatter(3) for an example of a formatter implementation.

Macros

The following macros are defined:

?LOG_EMERGENCY(StringOrReport[,Metadata]) ?LOG_EMERGENCY(FunOrFormat,Args[,Metadata]) ?LOG_ALERT(StringOrReport[,Metadata]) ?LOG_ALERT(FunOrFormat,Args[,Metadata]) ?LOG_CRITICAL(StringOrReport[,Metadata]) ?LOG_CRITICAL(FunOrFormat,Args[,Metadata]) ?LOG_ERROR(StringOrReport[,Metadata]) ?LOG_ERROR(FunOrFormat,Args[,Metadata]) ?LOG_WARNING(StringOrReport[,Metadata]) ?LOG_WARNING(FunOrFormat,Args[,Metadata]) ?LOG_NOTICE(StringOrReport[,Metadata]) ?LOG_NOTICE(FunOrFormat,Args[,Metadata]) ?LOG_INFO(StringOrReport[,Metadata]) ?LOG_INFO(FunOrFormat,Args[,Metadata]) ?LOG_DEBUG(StringOrReport[,Metadata]) ?LOG_DEBUG(FunOrFormat,Args[,Metadata])

All macros expand to a call to Logger, where Level is taken from the macro name, and location data is added to the metadata. See the description of the metadata() type for more information about the location data.

The call is wrapped in a case statement and will be evaluated only if Level is equal to or below the configured log level.

emergency(StringOrReport[,Metadata]) emergency(Format,Args[,Metadata]) emergency(Fun,FunArgs[,Metadata]) Logs the given message as level emergency.

Equivalent to log(emergency,...).

alert(StringOrReport[,Metadata]) alert(Format,Args[,Metadata]) alert(Fun,FunArgs[,Metadata]) Logs the given message as level alert.

Equivalent to log(alert,...).

critical(StringOrReport[,Metadata]) critical(Format,Args[,Metadata]) critical(Fun,FunArgs[,Metadata]) Logs the given message as level critical.

Equivalent to log(critical,...).

error(StringOrReport[,Metadata]) error(Format,Args[,Metadata]) error(Fun,FunArgs[,Metadata]) Logs the given message as level error.

Equivalent to log(error,...).

warning(StringOrReport[,Metadata]) warning(Format,Args[,Metadata]) warning(Fun,FunArgs[,Metadata]) Logs the given message as level warning.

Equivalent to log(warning,...).

notice(StringOrReport[,Metadata]) notice(Format,Args[,Metadata]) notice(Fun,FunArgs[,Metadata]) Logs the given message as level notice.

Equivalent to log(notice,...).

info(StringOrReport[,Metadata]) info(Format,Args[,Metadata]) info(Fun,FunArgs[,Metadata]) Logs the given message as level info.

Equivalent to log(info,...).

debug(StringOrReport[,Metadata]) debug(Format,Args[,Metadata]) debug(Fun,FunArgs[,Metadata]) Logs the given message as level debug.

Equivalent to log(debug,...).

Logs the given message.

Log the given message.

Look up the current configuration for the logger part of Logger.

Look up the current configuration for the logger part of Logger.

Look up the current configuration for the given handler.

Look up the current configuration for the given handler.

Get all Logger configurations

Same as logger:i(term)

Get all Logger configurations

Display or return all current Logger configurations.

Action = string

Return the pretty printed current Logger configuration as iodata.

Action = term

Return the current Logger configuration as a term. The format of this term may change between releases. For a stable format use logger:get_handler_config/1 and logger:get_logger_config/0.

The same as calling logger:i().

Action = print

Pretty print all the current Logger configuration to standard out. Example:

logger:i(print). Current logger configuration: Level: info Filter Default: log Filters: Handlers: Id: default Module: logger_std_h Level: info Formatter: Module: logger_formatter Config: #{legacy_header => true,single_line => false, template => [{logger_formatter,header},"\n",msg,"\n"]} Filter Default: stop Filters: Id: stop_progress Fun: fun logger_filters:progress/2 Config: stop Id: remote_gl Fun: fun logger_filters:remote_gl/2 Config: stop Id: domain Fun: fun logger_filters:domain/2 Config: {log,prefix_of,[beam,erlang,otp,sasl]} Id: no_domain Fun: fun logger_filters:domain/2 Config: {log,no_domain,[]} Handler Config: logger_std_h: #{type => standard_io} Level set per module: Module: my_module Level: debug]]>
Add a filter to the logger part of 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.

The return value of the fun specifies if a log event is to be discarded or forwarded to the handlers:

log()

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 Logger, where handler filters are applied.

stop

The filter did not pass, and the log event is immediately discarded.

ignore

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 part specifies if the log event shall be discarded or forwarded to the handler part.

See section Filters in the User's Guide for more information about filters.

Some built-in filters exist. These are defined in logger_filters.

Add a filter to the specified handler.

Add a filter to the specified handler.

The filter fun is called with the log event as the first parameter, and the specified filter_args() as the second parameter.

The return value of the fun specifies if a log event is to be discarded or forwarded to the handler callback:

log()

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.

stop

The filter did not pass, and the log event is immediately discarded.

ignore

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 filter_default configuration parameter for the handler specifies if the log event shall be discarded or forwarded to the handler callback.

See section Filters in the User's Guide for more information about filters.

Some built-in filters exist. These are defined in logger_filters.

Remove a filter from the logger part of Logger.

Remove the filter identified by FilterId from the logger part of Logger.

Remove a filter from the specified handler.

Remove the filter identified by FilterId from the handler identified by HandlerId.

Add a handler with the given configuration.

Add a handler with the given configuration.

HandlerId is a unique identifier which must be used in all subsequent calls reffering to this handler.

Remove the handler with the specified identity.

Remove the handler identified by HandlerId.

Set the log level for the specified module.

Set the log level for the specified Module.

The log level for a module overrides the global 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 global log level for Logger is info, and there is one handler, h1, with level info and one handler, h2, with level debug.

With this configuration, no debug messages will be logged, since they are all stopped by the global log level.

If the level for mymodule is now set to debug, then debug events from this module will be logged by the handler h2, but not by handler h1.

Debug events from other modules are still not logged.

To change the global log level for Logger, use logger:set_logger_config(level,Level).

To change the log level for a handler, use logger:set_handler_config(HandlerId,level,Level).

The originating module for a log event is only detected if mfa=>{Module,Function,Arity} exists in the metadata. When log macros are used, this association is automatically added to all log events. If an API function is called directly, without using a macro, the logging client must explicitly add this information if module levels shall have any effect.

Remove a module specific log setting.

Remove a module specific log setting. After this, the global log level is used for the specified module.

Set up log handlers from the application's configuration parameters.

Reads the application configuration parameter logger and calls logger:add_handlers/1 with its contents.

Setup logger handlers.

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 logger:add_handlers/1 just after the processes that the handler needs are started, and pass the application's logger configuration as the argument. For example:

-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 logger configuration parameter from the my_all application and starts the configured handlers. The contents of the configuration use the same rules as the logger handler configuration.

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 sys.config file that disables the Kernel handler and adds a custom handler could look like this:

[{kernel, [{logger, %% Disable the default Kernel handler [{handler,default,undefined}]}]}, {my_app, [{logger, %% Enable this handler as the default [{handler,default,my_handler,#{}}]}]}].
Set configuration data for the logger part of Logger.

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 complex merge is needed, read the current configuration with get_logger_config/0 , then do the merge before writing the new configuration back with this function.

If a key is removed compared to the current configuration, the default value is used.

Add or update configuration data for the logger part of Logger.

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 part of Logger.

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)).

To overwrite the existing configuration without any merge, use set_logger_config/1 .

Set configuration data for the specified handler.

Set configuration data for the specified handler. This overwrites the current handler configuration.

To modify the existing configuration, use update_handler_config/2, or, if a more complex merge is needed, read the current configuration with get_handler_config/1 , 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 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.

Add or update configuration data for the specified handler. 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 specified handler.

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 set_handler_config/2 .

Update the formatter configuration for the specified handler.

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.

Update the formatter configuration for the specified handler.

This is equivalent to
update_formatter_config(HandlerId,#{Key=>Value})

Compare the severity of two log levels.

Compare the severity of two log levels. Returns gt if Level1 is more severe than Level2, lt if Level1 is less severe, and eq if the levels are equal.

Set metadata to use when logging from current process.

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 update_process_metadata/1.

Set or update metadata to use when logging from current process.

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 set_process_metadata/1 .

Retrieve data set with set_process_metadata/1.

Retrieve data set with set_process_metadata/1 or update_process_metadata/1.

Delete data set with set_process_metadata/1.

Delete data set with set_process_metadata/1 or update_process_metadata/1.

Convert a log message on report form to {Format,Args}.

Convert a log message on report form to {Format,Args}.

This is the default report callback used by logger_formatter when no custom report callback is found.

The function produces lines of Key: Value from key-value lists. Strings are printed with ~ts and other terms with ~tp.

If the Report is a map, it is converted to a key-value list before formatting as such.

Handler Callback Functions

The following functions are to be exported from a handler callback module.

HModule:adding_handler(HandlerId,Config1) -> {ok,Config2} | {error,Reason} An instance of this handler is about to be added. HandlerId = handler_id() Config1 = Config2 = config() Reason = term()

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 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 in {ok,Config2}.

If the configuration is faulty, or if the initiation fails, the callback function must return {error,Reason}.

HModule:changing_config(HandlerId,Config1,Config2) -> {ok,Config3} | {error,Reason} The configuration for this handler is about to change. HandlerId = handler_id() Config1 = Config2 = Config3 = config() Reason = term()

This callback function is optional.

The function is called when the configuration for a handler is about to change, and the purpose is to verify and act on the new configuration.

Config1 is the existing configuration and Config2 is the new configuration.

If everything succeeds, the callback function must return a possibly adjusted configuration in {ok,Config3}.

If the configuration is faulty, the callback function must return {error,Reason}.

HModule:log(Log,Config) -> void() Log the given log event. Log = log() Config = config()

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.

HModule:removing_handler(HandlerId,Config) -> ok The given handler is about to be removed. HandlerId = handler_id() Config = config()

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.

Formatter Callback Functions

The following functions are to be exported from a formatter callback module.

FModule:format(Log,FConfig) -> FormattedLogEntry Format the given log event. Log = log() FConfig = formatter_config() FormattedLogEntry = unicode:chardata()

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 io:put_chars/1,2.

See logger_formatter(3) for an example implementation. logger_formatter is the default formatter used by Logger.