Warning
This document is for an in-development version 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 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 Postgres database, experimental support for MySQL is available but sqlite is not supported at all.
- The default port for the reports application is
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/)
Configuration Options¶
cookie_path
¶
Description: | When running multiple Galaxy Reports instances under separate URL prefixes on a single hostname, you will want to set this to the same path as the prefix set in the uWSGI “mount” configuration option above. This value becomes the “path” attribute set in the cookie so the cookies from one instance will not clobber those from another. |
---|---|
Default: | None |
Type: | str |
log_level
¶
Description: | Verbosity of console log messages. Acceptable values can be found here: https://docs.python.org/2/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/files |
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_interactive
¶
Description: | NEVER enable this on a public site (even test or QA) |
---|---|
Default: | true |
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: | |
---|---|
Default: | yourserver@yourfacility.edu |
Type: | str |
error_email_to
¶
Description: | |
---|---|
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 |