ArangoDB v3.4 reached End of Life (EOL) and is no longer supported.
This documentation is outdated. Please see the most recent version here: Latest Docs
ArangoDB Server Log Options
Log levels and topics
ArangoDB’s log output is grouped into topics.
--log.level can be specified
multiple times at startup, for as many topics as needed. The log verbosity and
output files can be adjusted per log topic. For example
--log.level startup=trace --log.level queries=trace --log.level info
will log messages concerning startup at trace level, AQL queries at trace level and everything else at info level.
In a configuration file, it is written like this:
[log] level = startup=trace level = queries=trace level = info
The available log levels are:
fatal: only logs fatal errors
error: only logs errors
warning: only logs warnings and errors
info: logs information messages, warnings and errors
debug: logs debug and information messages, warnings and errors
trace: logs trace, debug and information messages, warnings and errors
Note that levels
trace will be very verbose.
See Log Levels in the Monitoring chapter for a detailed description of the different levels.
Some relevant log topics available in ArangoDB 3 are:
agency: information about the agency
collector: information about the WAL collector’s state
compactor: information about the collection datafile compactor
datafiles: datafile-related operations
mmap: information about memory-mapping operations (including msync)
performance: performance-related messages
queries: executed AQL queries, slow queries
replication: replication-related info
requests: HTTP requests
startup: information about server startup and shutdown
threads: information about threads
See more log levels
The log option
--log.output <definition> allows directing the global
or per-topic log output to different outputs. The output definition
can be one of
The option can be specified multiple times in order to configure the output
for different log topics. To set up a per-topic output configuration, use
--log.output <topic>=<definition>, e.g.
logs all queries to the file “queries.txt”.
The old option
--log.file is still available in 3.0 for convenience reasons. In
3.0 it is a shortcut for the more general option
The old option
--log.requests-file is still available in 3.0. It is now a shortcut
for the more general option
--log.output also allows directing log output to different files based on
topics. For example, to log all AQL queries to a file “queries.log” one can use the
--log.level queries=trace --log.output queries=file:///path/to/queries.log
To additionally log HTTP request to a file named “requests.log” add the options:
--log.level requests=info --log.output requests=file:///path/to/requests.log
If you specify
--log.file-mode octalvalue then any newly created log
file will use “octalvalue” as file mode. Please note that the
value will be applied as well.
If you specify
--log.file-group name then any newly created log file
will try to use “name” as group name. Please note that you have to be
a member of that group. Otherwise the group ownership will not be
changed. Please note that this option is only available under Linux
and Mac. It is not available under Windows.
Forcing direct output
--log.force-direct can be used to disable logging in an extra
logging thread. If set to
true, any log messages are immediately printed in the
thread that triggered the log message. This is non-optimal for performance but
can aid debugging. If set to
false, log messages are handed off to an extra
logging thread, which asynchronously writes the log messages.
Log dates and times in local time zone:
If specified, all dates and times in log messages will use the server’s
local time-zone. If not specified, all dates and times in log messages
will be printed in UTC / Zulu time. The date and time format used in logs
YYYY-MM-DD HH:MM:SS, regardless of this setting. If UTC time
is used, a
Z will be appended to indicate Zulu time.
This option toggles the escaping of log output.
If set to
true, the following characters in the log output are escaped:
- the carriage return character (hex 0d)
- the newline character (hex 0a)
- the tabstop character (hex 09)
- any other characters with an ordinal value less than hex 20
If the option is set to
false, no characters are escaped. Characters with
an ordinal value less than hex 20 will not be printed in this mode but will
be replaced with a space character (hex 20).
A side effect of turning off the escaping is that it will reduce the CPU overhead for the logging. However, this will only be noticeable when logging is set to a very verbose level (e.g. debug or trace).
The default value for this option is
Logging to terminal output is by default colored. Colorful logging can be turned off by setting the value to false.
Source file and Line number
Log line number:
Normally, if an human readable fatal, error, warning or info message is logged, no information about the file and line number is provided. The file and line number is only logged for debug and trace message. This option can be use to always log these pieces of information.
This option is used specify an prefix to logged text.
Log thread identifier:
Whenever log output is generated, the process ID is written as part of the log information. Setting this option appends the thread id of the calling thread to the process id. For example,
2010-09-20T13:04:01Z  INFO ready for business
when no thread is logged and
2010-09-20T13:04:17Z [19371-18446744072487317056] ready for business
when this command line option is set.
To also log thread names, it is possible to set the
option. By default
--log.thread-name is set to
When set to
true, this option will make the ArangoDB logger print a single
character with the server’s role into each logged message. The roles are:
- U: Undefined / unclear (used at startup)
- S: Single server
- C: Coordinator
- P: Primary / DB-Server
- A: Agent
The default value for this option is
false, so no roles will be logged.
Log API Access
Introduced in: v3.4.11
Credentials data is not written to log files. Nevertheless, some logged data might be sensitive depending on the context of the deployment. For example, if request logging is switched on, user requests and corresponding data might end up in log files. Therefore, a certain care with log files is recommended.
Since the database server offers an API to control logging and query
logging data, this API has to be secured properly. By default, the API
is accessible for admin users (administrative access to the
database). However, one can lock this down further.
The possible values for this option are:
true: The API
/_admin/logis accessible for admin users.
jwt: The API
/_admin/logis accessible only for the superuser (authentication with JWT token and empty username).
false: The API
/_admin/logis not accessible at all.
The default value is