Galaxy Monitoring with gxadmin


question Questions
  • What is gxadmin

  • What can it do?

  • How to write a query?

objectives Objectives
  • Learn gxadmin basics

  • See some queries and learn how they help debug production issues

time Time estimation: 30 minutes

Supporting Materials

last_modification Last modification: Sep 3, 2020


We will just briefly cover the features available in gxadmin, there are lots of queries that may or may not be useful for your Galaxy instance and you will have to read the documentation before using them.

It started life as a small shell script that Helena wrote because she couldn’t remember what Gravity was called or where it could be found. Some of the functions needed for things like swapping zerglings are still included in gxadmin but are highly specific to and not generally useful.

Since then it became the home for “all of the SQL queries we [galaxy admins] run regularly.” @hexylena and @natefoo often shared SQL queries with each other in private chats, but this wasn’t helpful to the admin community at large, so they decided to put them all in gxadmin and make it as easy to install as possible. We are continually trying to make this tool more generic and generally useful, if you notice something that’s missing or broken, or have a new query you want to run, just let us know.


  1. Installing gxadmin
  2. Configuration
  3. Overview
  4. Admin Favourite Queries
  5. gxadmin for Monitoring
  6. Implementing a Query
    1. A basic function
    2. Adding help
    3. Adding a query
  7. Summary

Installing gxadmin

It’s simple to install gxadmin. Here’s how you do it, if you haven’t done it already.

hands_on Hands-on: Installing gxadmin with Ansible

  1. Edit your requirements.yml and add the following:

    - src: usegalaxy_eu.gxadmin
      version: 0.0.3
  2. Install the role with ansible-galaxy install -p roles -r requirements.yml

  3. Add the role to your playbook, it should run as root

  4. Run the playbook


If psql runs without any additional arguments, and permits you to access your galaxy database then you do not need to do any more configuration for gxadmin. Otherwise, you may need to set some of the PostgreSQL environment variables


gxadmin has several categories of commands, each with different focuses. This is not a technically meaningful separation, it is just done to make the interface easier for end users.

Category Keyword Purpose
Configuration config Commands relating to galaxy’s configuration files like XML validation.
Filters filter Transforming streams of text.
Galaxy Admin galaxy Miscellaneous galaxy related commands like a cleanup wrapper.
uWSGI uwsgi If you’re using systemd for Galaxy and a handler/zergling setup, then this lets you manage your handlers and zerglings.
DB Queries {csv,tsv,i,}query Queries against the database which return tabular output.
Report report Queries which return more complex and structured markdown reports.
Mutations mutate These are like queries, except they mutate the database. All other queries are read-only.
Meta meta More miscellaneous commands, and a built-in updating function.

Admin Favourite Queries

@slugger70’s favourite: gxadmin query old-histories. He contributed this function to find old histories, as their instance has a 90 day limit on histories, anything older than that might be automatically removed. This helps their group identify any histories that can be purged in order to save space. Running this on, we have some truly ancient histories, and maybe could benefit from a similar policy.

id update-time user-id email name published deleted purged hid-counter
361 2013-02-24 16:27:29.197572 xxx xxxx Unnamed history f f f 6
362 2013-02-24 15:31:05.804747 xxx xxxx Unnamed history f f f 1
347 2013-02-22 15:59:12.044169 xxx xxxx Unnamed history f f f 19
324 2013-02-22 15:57:54.500637 xxx xxxx Exercise 5 f f f 64
315 2013-02-22 15:50:51.398894 xxx xxxx day5 practical f f f 90
314 2013-02-22 15:45:47.75967 xxx xxxx 5. Tag Galaxy-Kurs f f f 78

@natefoo’s favourite: gxadmin query job-inputs. He contributed this function which helps him debug jobs which are not running and should be. The query can

hda-id hda-state hda-deleted hda-purged d-id d-state d-deleted d-purged object-store-id
8638197   f f 8246854 running f f files9
8638195   f f 8246852 running f f files9
8638195   f f 8246852 running f f files9

@bgruening’s favourite: gxadmin query latest-users let’s us see who has recently joined our server. We sometimes notice that people are running a training on our infrastructure and they haven’t registered for training infrastructure as a service which helps us coordinate infrastructure for them so they don’t have bad experiences.

id create_time disk_usage username email groups active
3937 2019-01-27 14:11:12.636399 291 MB xxxx xxxx   t
3936 2019-01-27 10:41:07.76126 1416 MB xxxx xxxx   t
3935 2019-01-27 10:13:01.499094 2072 kB xxxx xxxx   t
3934 2019-01-27 10:06:40.973938 0 bytes xxxx xxxx   f
3933 2019-01-27 10:01:22.562782   xxxx xxxx   f

@hexylena’s favourite gxadmin report job-info. This command gives more information than you probably need on the execution of a specific job, formatted as markdown for easy sharing with fellow administrators.

# Galaxy Job 5132146

Property      | Value
------------- | -----
         Tool |
        State | running
      Handler | handler_main_2
      Created | 2019-04-20 11:04:40.854975+02 (3 days 05:49:30.451719 ago)
Job Runner/ID | condor / 568537
        Owner | e08d6c893f5

## Destination Parameters

Key                     |   Value
---                     |   ---
description             |   `canu`
priority                |   `-128`
request_cpus            |   `20`
request_memory          |   `64G`
requirements            |   `GalaxyGroup == "compute"`
tmp_dir                 |   `True`

## Dependencies

Name   |   Version   |   Dependency Type   |   Cacheable   |   Exact   |   Environment Path                          |   Model Class
---    |   ---       |   ---               |   ---         |   ---     |   ---                                       |   ---
canu   |   1.7       |   conda             |   false       |   true    |   /usr/local/tools/_conda/envs/__canu@1.7   |   MergedCondaDependency

## Tool Parameters

Name                 |   Settings
---------            |   ------------------------------------
minOverlapLength     |   500
chromInfo            |   /opt/galaxy/tool-data/shared/ucsc/chrom/?.len
stage                |   all
contigFilter         |   {lowCovDepth: 5, lowCovSpan: 0.5, minLength: 0, minReads: 2, singleReadSpan: 1.0}
s                    |   null
mode                 |   -nanopore-raw
dbkey                |   ?
genomeSize           |   300000
corOutCoverage       |   40
rawErrorRate         |
minReadLength        |   1000
correctedErrorRate   |

## Inputs

Job ID    |   Name                |   Extension     |   hda-id    |   hda-state   |   hda-deleted   |   hda-purged   |   ds-id     |   ds-state   |   ds-deleted   |   ds-purged   |   Size
----      |   ----                |   ----          |   ----      |   ----        |   ----          |   ----         |   ----      |   ----       |   ----         |   ----        |   ----
4975404   |   Osur_record.fastq   |   fastqsanger   |   9517188   |               |   t             |   f            |   9015329   |   ok         |   f            |   f           |   3272 MB
4975404   |   Osur_record.fastq   |   fastqsanger   |   9517188   |               |   t             |   f            |   9015329   |   ok         |   f            |   f           |   3272 MB

## Outputs

Name                                          |   Extension   |   hda-id    |   hda-state   |   hda-deleted   |   hda-purged   |   ds-id     |   ds-state   |   ds-deleted   |   ds-purged   |   Size
----                                          |   ----        |   ----      |   ----        |   ----          |   ----         |   ----      |   ----       |   ----         |   ----        |   ----
Canu assembler on data 41 (trimmed reads)     |   fasta.gz    |   9520369   |               |   f             |   f            |   9018510   |   running    |   f            |   f           |
Canu assembler on data 41 (corrected reads)   |   fasta.gz    |   9520368   |               |   f             |   f            |   9018509   |   running    |   f            |   f           |
Canu assembler on data 41 (unitigs)           |   fasta       |   9520367   |               |   f             |   f            |   9018508   |   running    |   f            |   f           |
Canu assembler on data 41 (unassembled)       |   fasta       |   9520366   |               |   f             |   f            |   9018507   |   running    |   f            |   f           |
Canu assembler on data 41 (contigs)           |   fasta       |   9520365   |               |   f             |   f            |   9018506   |   running    |   f            |   f           |

gxadmin for Monitoring

gxadmin already supported query, csvquery, and tsvquery for requesting data from the Galaxy database in tables, CSV, or TSV formats, but we recently implemented influx queries which output data in a format that Telegraf can consume.

So running gxadmin query queue-overview normally shows something like:

tool_id tool_version destination_id handler state job_runner_name count 12cores_180G_special handler_main_4 running condor 1 12cores_180G_special handler_main_5 running condor 1 12cores_12G handler_main_3 running condor 2 4G_memory handler_main_1 running condor 1 2.1.0+galaxy3 8cores_20G handler_main_11 running condor 1 0.72 20G_memory handler_main_11 running condor 4
ebi_sra_main 1.0.1 4G_memory handler_main_3 running condor 2
ebi_sra_main 1.0.1 4G_memory handler_main_4 running condor 3

The gxadmin iquery queue-overview is run by our Telegraf monitor on a regular basis, allowing us to consume the data:

queue-overview,,tool_version=,state=running,handler=handler_main_4,destination_id=12cores_180G_special,job_runner_name=condor count=1
queue-overview,,tool_version=,state=running,handler=handler_main_5,destination_id=12cores_180G_special,job_runner_name=condor count=1
queue-overview,,tool_version=,state=running,handler=handler_main_3,destination_id=12cores_12G,job_runner_name=condor count=1
queue-overview,,tool_version=1.0.0_rc1+galaxy1,state=queued,handler=handler_main_11,destination_id=4G_memory,job_runner_name=condor count=1
queue-overview,,tool_version=2.1.0+galaxy3,state=running,handler=handler_main_11,destination_id=8cores_20G,job_runner_name=condor count=1
queue-overview,,tool_version=0.72,state=running,handler=handler_main_11,destination_id=20G_memory,job_runner_name=condor count=4
queue-overview,tool_id=ebi_sra_main,tool_version=1.0.1,state=running,handler=handler_main_3,destination_id=4G_memory,job_runner_name=condor count=2
queue-overview,tool_id=ebi_sra_main,tool_version=1.0.1,state=running,handler=handler_main_4,destination_id=4G_memory,job_runner_name=condor count=3

And produce some nice graphs from it.

You can use an influx configuration like:

    commands = ["/usr/bin/galaxy-queue-size"]
    timeout = "10s"
    data_format = "influx"
    interval = "1m"

This often requires a wrapper script, because you’ll need to pass environment variables to the gxadmin invocation, e.g.:

export PGUSER=galaxy
export PGHOST=dbhost
gxadmin iquery queue-overview --short-tool-id
gxadmin iquery workflow-invocation-status

tip Which queries support iquery?

This data is not currently exposed, so, just try the queries. But it’s easy to add influx support when missing! Here is an example, we set the variables in a function:


This means: column 0 is a tag named tool_id, and column 1 is a field (real value) named count. Here is an example that has multiple fields that are stored.

Implementing a Query

Queries are really easy to implement! All you have to do is add your SQL, with a small bash function to wrap it. gxadmin supports ‘local’ functions, which you can add locally without contributing back. We strongly encourage you to contribute your functions back to gxadmin though, you’ll never know who wants to know the same thing about their db.

gxadmin will look for local functions in ~/.config/

A basic function

hands_on Hands-on: Implementing a basic function

  1. If ~/.config/ does not exist, create that directory with mkdir -p ~/.config/

  2. Open ~/.config/ in a text editor.

  3. Add the following to the file and save it.

    local_hello() { ## : Says hi
    	echo "hi!"
  4. Run gxadmin local

    question Question

    What do you see?

    solution Solution

    It should look like:

    gxadmin usage:
    Local: (These can be configured in /home/hxr/.config/
        local hello          Says hi
    help / -h / --help : this message. Invoke '--help' on any subcommand for help specific to that subcommand
  5. Run gxadmin local hello

    question Question

    What do you see?

    solution Solution

    It should output ‘hi!’

This is the simplest possible function you can add, and is pretty limited in its functionality. This can offer you a nice place to put all of your existing bash scripts, and have autogenerated help for them.

Adding help

Every function is improved by documentation! Let’s add that now:

hands_on Hands-on: Adding help

  1. Open ~/.config/ in a text editor.

  2. Update your function to add the handle_help call:

    local_hello() { ## : Says hi
    	handle_help "$@" <<-EOF
    		Greets you
    	echo "hi!"
  3. Run gxadmin local hello --help

    question Question

    What do you see?

    solution Solution

    It should look like:

    $ gxadmin local hello --help
    local hello - Says hi
    gxadmin local hello
    Greets you

Adding a query

The bulk of gxadmin is not functions calling shell commands though, it’s mostly SQL queries. So let’s find the N most recent jobs

hands_on Hands-on: Adding a query

  1. Open ~/.config/ in a text editor.

  2. Add a new function:

    local_query-latest() { ## [jobs|10]: Queries latest N jobs (default to 10)
    	handle_help "$@" <<-EOF
    		Find information about the latest jobs on your server.
    	# Value of first argument, or 10 if isn't supplied
    	# Here we store the query in a bash variable named QUERY
    	read -r -d '' QUERY <<-EOF
    			id, tool_id, tool_version, state
    		FROM job
    		ORDER BY id desc
    		LIMIT ${job_limit}
  3. Run gxadmin local query-latest 5 to select

    question Question

    What do you see?

    solution Solution

    It should similar to the following, assuming you’ve run tools in your Galaxy

    $ gxadmin local query-latest 5
     id  |         tool_id          | tool_version | state
     103 | upload1                  | 1.1.6        | ok
     102 | upload1                  | 1.1.6        | ok
     101 | upload1                  | 1.1.6        | error
     100 | circos                   | 0.91         | ok
      99 | circos                   | 0.91         | ok
    (5 rows)


There are a lot of queries, all tailored to specific use cases, some of these may be interesting for you, some may not. These are all documented with example inputs and outputs in the gxadmin readme, and help is likewise available from the command line.

keypoints Key points

  • gxadmin is a tool to run common database queries useful for Galaxy admins

  • new queries are welcome and easy to contribute

Frequently Asked Questions

Have questions about this tutorial? Check out the FAQ page for the Galaxy Server administration topic to see if your question is listed there. If not, please ask your question on the GTN Gitter Channel or the Galaxy Help Forum


Did you use this material as an instructor? Feel free to give us feedback on how it went.

Click here to load Google feedback frame

Citing this Tutorial

  1. Helena Rasche, 2020 Galaxy Monitoring with gxadmin (Galaxy Training Materials). /archive/2021-05-01/topics/admin/tutorials/gxadmin/tutorial.html Online; accessed TODAY
  2. Batut et al., 2018 Community-Driven Data Analysis Training for Biology Cell Systems 10.1016/j.cels.2018.05.012

details BibTeX

    author = "Helena Rasche",
    title = "Galaxy Monitoring with gxadmin (Galaxy Training Materials)",
    year = "2020",
    month = "09",
    day = "03"
    url = "\url{/archive/2021-05-01/topics/admin/tutorials/gxadmin/tutorial.html}",
    note = "[Online; accessed TODAY]"
        doi = {10.1016/j.cels.2018.05.012},
        url = {},
        year = 2018,
        month = {jun},
        publisher = {Elsevier {BV}},
        volume = {6},
        number = {6},
        pages = {752--758.e1},
        author = {B{\'{e}}r{\'{e}}nice Batut and Saskia Hiltemann and Andrea Bagnacani and Dannon Baker and Vivek Bhardwaj and Clemens Blank and Anthony Bretaudeau and Loraine Brillet-Gu{\'{e}}guen and Martin {\v{C}}ech and John Chilton and Dave Clements and Olivia Doppelt-Azeroual and Anika Erxleben and Mallory Ann Freeberg and Simon Gladman and Youri Hoogstrate and Hans-Rudolf Hotz and Torsten Houwaart and Pratik Jagtap and Delphine Larivi{\`{e}}re and Gildas Le Corguill{\'{e}} and Thomas Manke and Fabien Mareuil and Fidel Ram{\'{\i}}rez and Devon Ryan and Florian Christoph Sigloch and Nicola Soranzo and Joachim Wolff and Pavankumar Videm and Markus Wolfien and Aisanjiang Wubuli and Dilmurat Yusuf and James Taylor and Rolf Backofen and Anton Nekrutenko and Björn Grüning},
        title = {Community-Driven Data Analysis Training for Biology},
        journal = {Cell Systems}

congratulations Congratulations on successfully completing this tutorial!