Appendix F: The QueueMetrics watchdog page

QueueMetrics has a watchdog page - that is, if you request a page called: ''/sysup.jsp'', you get an answer that is a valid JSON object of the format:

{
  "state" : "QMUP",
  "ramFreeMb" : 118,
  "ramTotalMb" : 152,
  "ramMaxMb" : 1818,
  "generatedOn" : "Tue Nov 05 16:44:30 CET 2013",
  "version" : "13.12.01 build 607"
}

If the page contains the string QMUP, this means that QueueMetrics is working and able to talk to the database.

The other information on memory usage can be used to be stored in a long-term tracking system (e.g. Nagios, Zabbix, Pandora…​.) in order to make it possible to understand if there are memory issues.

We offer a sample watchdog script that checks whether QM is running or not and restarts it - you can find it at ''WEB-INF/mysql-utils/restart/watchdogQm.pl''.

Accessing JMX counters

You can extract JVM metrics in JSON format without needing a dedicated JMX client by adding the JMXTOKEN parameter to the sysup.jsp endpoint call:

curl "http://server.my:8080/queuemetrics/sysup.jsp?JMXTOKEN=mysecret"

{
  "state" : "QMUP",
  "generatedOn" : "Sun Feb 08 09:52:47 CET 2026",
  "version" : "24.11.12 / 376 - 2025.11.20-16:01 - 7bebec488b9@rel_24_11_m",
  "jmxCollectionTime" : 0,
  "ramFreeMb" : 64,
  "ramTotalMb" : 170,
  "ramMaxMb" : 170,
  "jmx" : {
    "gc_g1_old_num" : "1",
    "gc_g1_old_time" : "77",
    "gc_g1_yng_num" : "2818",
    "gc_g1_yng_time" : "10668",
    "jvm_code_cache" : "NOT_FOUND",
    "jvm_cputime_ns" : "14704680000000",
    "jvm_heap_used" : "110732592",
    "jvm_loaded_classes" : "7799",
    "jvm_nonheap_used" : "111011960",
    "jvm_thread_count" : "27",
    "jvm_total_compilation_time" : "68169",
    "jvm_unloaded_classes" : "4172",
    "pool_max_idle" : "5",
    "pool_max_total" : "1000",
    "pool_num_active" : "0",
    "pool_num_destroyed" : "111",
    "pool_num_idle" : "1",
    "pool_num_waiters" : "0",
    "tomcat_active_sessions" : "84",
    "tomcat_bytes_received" : "67704793",
    "tomcat_bytes_sent" : "139333040",
    "tomcat_error_count" : "5",
    "tomcat_request_count" : "540907",
    "tomcat_threads_acceptors" : "2",
    "tomcat_threads_busy" : "1",
    "tomcat_threads_current" : "10",
    "tomcat_total_processing_time" : "2151784"
  }
}

This approach is particularly useful for integrating with monitoring systems like Grafana, Prometheus, or other observability platforms. Instead of configuring a full JMX client connection, you can periodically poll this HTTP endpoint and parse the JSON response to extract metrics for visualization and alerting.

Configuration Requirements

  • You must set the JVM property qm.jmx.token with your chosen secret token for JMX counter generation to be enabled

  • The set of metrics returned is defined in the WEB-INF/jmx.properties configuration file - the default ones are a good starting point to diagnose issues.