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.
Galaxy Reports¶
Overview¶
For admins wishing to have more information on the usage of a Galaxy instance, one can configure and use the Galaxy Reports application. This is a separate application that can run beside Galaxy and must target the same database.
The Galaxy Reports application’s easy to use web interface will give you information on the following (and more):
Jobs
Today’s jobs
Jobs per day this month
Jobs in error per day this month
All unfinished jobs
Jobs per month
Jobs in error per month
Jobs per user
Jobs per tool
Workflows
Workflows per month
Workflows per user
Users
Registered users
Date of last login
User disk usage
System
Disk space maintenance
Configuration¶
Configure
config/reports.yml
in the same manner as your main galaxy instance (i.e., same database connection, but different web server port). This is a YAML configuration file and should contain areports
section with app-specific configuration (options described below).The default port for the reports application is
9001
, and like Galaxy it only binds to localhost by default.database_connection
should match the value used in your Galaxy configurationdatabase_connection
should point at a PostgreSQL database, experimental support for MySQL is available but SQLite is not supported at all.
Run reports in a Gunicorn server with
sh run_reports.sh
Use a web browser and go to the address you configured in
reports.yml
(defaults to http://localhost:9001/)If you’d like the report tool to persist between sessions then use
sh run_reports.sh --daemon
to run it as a background process. As with Galaxy itself, use the--stop-daemon
option to halt the background process. (The process output is written toreports_webapp.log
if you have to debug a problem.)To make your reports available from outside of the localhost using the NGINX proxy server, you can check out the documentation on how to protect Galaxy reports using authentication.
Configuration Options¶
log_level
¶
- Description:
Verbosity of console log messages. Acceptable values can be found here: https://docs.python.org/library/logging.html#logging-levels
- Default:
DEBUG
- Type:
str
database_connection
¶
- Description:
Database connection. Galaxy Reports are intended for production Galaxy instances, so sqlite (and the default value below) is not supported. An SQLAlchemy connection string should be used specify an external database.
- Default:
sqlite:///./database/universe.sqlite?isolation_level=IMMEDIATE
- Type:
str
file_path
¶
- Description:
Where dataset files are stored.
- Default:
database/objects
- Type:
str
new_file_path
¶
- Description:
Where temporary files are stored.
- Default:
database/tmp
- Type:
str
template_cache_path
¶
- Description:
Mako templates are compiled as needed and cached for reuse, this directory is used for the cache
- Default:
database/compiled_templates/reports
- Type:
str
use_heartbeat
¶
- Description:
Write thread status periodically to ‘heartbeat.log’ (careful, uses disk space rapidly!)
- Default:
true
- Type:
bool
smtp_server
¶
- Description:
Mail
- Default:
yourserver@yourfacility.edu
- Type:
str
error_email_to
¶
- Description:
Mail
- Default:
your_bugs@bx.psu.edu
- Type:
str
enable_beta_gdpr
¶
- Description:
Enables GDPR Compliance mode. This makes several changes to the way Galaxy logs and exposes data externally such as removing emails/usernames from logs and bug reports. You are responsible for removing personal data from backups. Please read the GDPR section under the special topics area of the admin documentation.
- Default:
false
- Type:
bool