Warning
This document is for an old release of Galaxy. You can alternatively view this page in the latest release if it exists or view the top of the latest release's documentation.
Logging Configuration
Overview
There are two ways in which you can configure logging for Galaxy servers:
Basic/automatic configuration with control over log level and log destination (standard output or a named log file).
More complex configuration using the Python
logging
module’slogging.config.dictConfig()
orlogging.config.fileConfig()
.
Basic Configuration
Basic logging configuration can be used to modify the level of log messages and the file to which Galaxy logs.
The logging level is controlled by the log_level
configuration option. By default, Galaxy logs all messages at the
DEBUG
level.
Galaxy logs all messages to standard output by default if running in the foreground. If running in the background (e.g.
by passing the --daemon
argument to run.sh
), the log is written to a location configured in
gravity.
Gravity and related terminology are explained in detail in the Scaling and Load Balancing documentation.
Setting the log level:
In galaxy.yml
, set log_level
:
galaxy:
log_level: LEVEL
Where LEVEL
is one of the logging levels documented in the logging
module.
Logging to a file:
To change the log file name or location, use the $GALAXY_LOG
environment variable like so:
$ GALAXY_LOG=/path/to/galaxy/logfile sh run.sh --daemon
It is also possible to specify the path to the log file using the log_destination
configuration option in
galaxy.yml
. Additionally, it is possible to automatically rotate logs once the log file reaches a given size, using
the log_rotate_size
and log_rotate_count
options, which control the size at which the log is rotated, and the
number of rotated logs to keep, respectively:
galaxy:
# Set log file path
log_destination: /srv/galaxy/log/galaxy.log
# Rotate once log reaches 100 MB
log_rotate_size: 100 MB
# Keep the 10 most recent log files
log_rotate_count: 10
Advanced Configuration
For more useful and manageable logging when running Galaxy with forking application stacks where multiple
Galaxy server processes are forked after the Galaxy application is loaded, a custom filename_template
config option
is available to logging.FileHandler
(or derivative class) log handler definitions so that multiple file logging is possible.
Without this custom option, all forked Galaxy server processes would only be able to log to a single combined log file,
which can be very difficult to work with.
YAML
Advanced logging configuration is performed under the logging
key in the galaxy
section of galaxy.yml
. The
syntax is a YAML dictionary in the syntax of Python’s logging.config.dictConfig()
. This section covers a few of
the most common configurations as well as Galaxy’s customizations. Consult the logging.config.dictConfig()
documentation for a complete explanation of the syntax and possibilities.
Default
The default as of this Galaxy release can be found (in Python syntax) in the
galaxy.config.LOGGING_CONFIG_DEFAULT
constant and (in YAML) below:
galaxy:
logging:
disable_existing_loggers: false
filters:
stack:
(): galaxy.web_stack.application_stack_log_filter
formatters:
stack:
(): galaxy.web_stack.application_stack_log_formatter
handlers:
console:
class: logging.StreamHandler
filters:
- stack
formatter: stack
level: DEBUG
stream: ext://sys.stderr
loggers:
amqp:
level: INFO
qualname: amqp
botocore:
level: INFO
qualname: botocore
gunicorn.access:
handlers:
- console
level: INFO
propagate: false
qualname: gunicorn.access
paste.httpserver.ThreadPool:
level: WARN
qualname: paste.httpserver.ThreadPool
routes.middleware:
level: WARN
qualname: routes.middleware
sqlalchemy_json.track:
level: WARN
qualname: sqlalchemy_json.track
urllib3.connectionpool:
level: WARN
qualname: urllib3.connectionpool
watchdog.observers.inotify_buffer:
level: INFO
qualname: watchdog.observers.inotify_buffer
root:
handlers:
- console
level: DEBUG
version: 1