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 uWSGI YAML configuration file and should contain a reports 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 configuration
- database_connection should point at a PostgreSQL database, experimental support for MySQL is available but SQLite is not supported at all.
Run reports in a uWSGI 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 to reports_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

`debug`¶

Description: Configuration for debugging middleware
Default: false
Type: bool

`use_lint`¶

Description: Check for WSGI compliance.
Default: false
Type: bool

`use_heartbeat`¶

Description: Write thread status periodically to ‘heartbeat.log’ (careful, uses disk space rapidly!)
Default: true
Type: bool

`use_profile`¶

Description: Profiling middleware (cProfile based)
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

Galaxy Reports¶

Overview¶

Configuration¶

Configuration Options¶

log_level¶

database_connection¶

file_path¶

new_file_path¶

template_cache_path¶

debug¶

use_lint¶

use_heartbeat¶

use_profile¶

smtp_server¶

error_email_to¶

enable_beta_gdpr¶