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’s logging.config.dictConfig() or logging.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
    root:
      handlers:
      - console
      level: DEBUG
    version: 1