Tarantool CE/EE Documentation portal logo
Support
Updated at July 17, 2026   02:08 PM

Logging example

This section provides information on how to configure options related to logging. You can also use the log module to configure logging in your application.

log_level

Since version 1.6.2.

Specify the level of detail the log has. There are the following levels:

  • 0 – fatal
  • 1 – syserror
  • 2 – error
  • 3 – crit
  • 4 – warn
  • 5 – info
  • 6 – verbose
  • 7 – debug

By setting log_level, you can enable logging of all events with severities above or equal to the given level. Tarantool prints logs to the standard error stream by default. This can be changed with the log configuration parameter.

Type: integer, string

Default: 5

Environment variable: TT_LOG_LEVEL

Dynamic: yes

log_modules

Since version 2.11.0.

Configure the specified log levels (log_level) for different modules.

You can specify a logging level for the following module types:

Type: table

Default: blank

Environment variable: TT_LOG_MODULES

Dynamic: yes

Example 1: Set log levels for files that use the default logger

Suppose you have two identical modules placed by the following paths: test/logging/module1.lua and test/logging/module2.lua. These modules use the default logger and look as follows:

return {    say_hello = function()        local log = require('log')        log.info('Info message from module1')    end}

To load these modules in your application, you need to add the corresponding require directives:

module1 = require('test.logging.module1')module2 = require('test.logging.module2')

To configure logging levels, you need to provide module names corresponding to paths to these modules. In the example below, the box_cfg variable contains logging settings that can be passed to the box.cfg() function:

box_cfg = { log_modules = {    ['test.logging.module1'] = 'verbose',    ['test.logging.module2'] = 'error' }}

Given that module1 has the verbose logging level and module2 has the error level, calling module1.say_hello() shows a message but module2.say_hello() is swallowed:

-- Prints 'info' messages --module1.say_hello()--[[[92617] main/103/interactive/test.logging.module1 I> Info message from module1---...--]]-- Swallows 'info' messages --module2.say_hello()--[[---...--]]

Example 2: Set log levels for modules that use custom loggers

In the example below, the box_cfg variable contains logging settings that can be passed to the box.cfg() function. This example shows how to set the verbose level for module1 and the error level for module2:

box_cfg = { log_level = 'warn',            log_modules = {                module1 = 'verbose',                module2 = 'error' }}

To create custom loggers, call the log.new() function:

-- Creates new loggers --module1_log = require('log').new('module1')module2_log = require('log').new('module2')

Given that module1 has the verbose logging level and module2 has the error level, calling module1_log.info() shows a message but module2_log.info() is swallowed:

-- Prints 'info' messages --module1_log.info('Info message from module1')--[[[16300] main/103/interactive/module1 I> Info message from module1---...--]]-- Swallows 'debug' messages --module1_log.debug('Debug message from module1')--[[---...--]]-- Swallows 'info' messages --module2_log.info('Info message from module2')--[[---...--]]

Example 3: Set a log level for C modules

In the example below, the box_cfg variable contains logging settings that can be passed to the box.cfg() function. This example shows how to set the info level for the tarantool module:

box_cfg = { log_level = 'warn',            log_modules = { tarantool = 'info' } }

The specified level affects messages logged from C modules:

ffi = require('ffi')-- Prints 'info' messages --ffi.C._say(ffi.C.S_INFO, nil, 0, nil, 'Info message from C module')--[[[6024] main/103/interactive I> Info message from C module---...--]]-- Swallows 'debug' messages --ffi.C._say(ffi.C.S_DEBUG, nil, 0, nil, 'Debug message from C module')--[[---...--]]

The example above uses the LuaJIT ffi library to call C functions provided by the say module.

Logging example

This example illustrates how "rotation" works, that is, what happens when the server instance is writing to a log and signals are used when archiving it.

  1. Start with two terminal shells: Terminal #1 and Terminal #2.

  2. In Terminal #1, start an interactive Tarantool session. Then, use the log property to send logs to Log_file and call log.info to put a message in the log file.

    box.cfg{log='Log_file'}log = require('log')log.info('Log Line #1')
  3. In Terminal #2, use the mv command to rename the log file to Log_file.bak.

cssclass

highlight

parsed-literal

mv Log_file Log_file.bakAs a result, the next log message will go to`Log_file.bak`.

4. Go back to Terminal #1 and put a message "Log Line #2" in the log file.

``` lualog.info('Log Line #2')```

5. In Terminal #2, use ps to find the process ID of the Tarantool instance.

cssclass

highlight

parsed-literal

ps -A \| grep tarantool

6. In Terminal #2, execute kill -HUP to send a SIGHUP signal to the Tarantool instance. Tarantool will open Log_file again, and the next log message will go to Log_file.

cssclass

highlight

parsed-literal

kill -HUP *process_id*The same effect could be accomplished by calling[log.rotate](../../reference_lua/log#log-rotate).

7. In Terminal #1, put a message "Log Line #3" in the log file.

``` lualog.info('Log Line #3')```

8. In Terminal #2, use less to examine files. Log_file.bak will have the following lines ...

cssclass

highlight

parsed-literal

2015-11-30 15:13:06.373 [27469] main/101/interactive I> Log Line#1\` 2015-11-30 15:14:25.973 [27469] main/101/interactive I> LogLine #2\`... and `Log_file` will look like this:

cssclass

highlight

parsed-literal

log file has been reopened 2015-11-30 15:15:32.629 [27469]main/101/interactive I> Log Line #3