What goes in a Presto or Trino monitoring dashboard in Metabase?

A Presto or Trino monitoring dashboard tracks query volume and state, wall-time percentiles, how long work sits queued in each resource group, splits in flight across the workers, memory pool pressure, and the error codes queries fail with. Metabase connects to Presto and Trino natively, so every card is plain SQL over the engine's own system.runtime tables and the event listener's history table.

What does a Presto or Trino monitoring dashboard look like?

Here’s the layout this guide builds. Cluster-level counters sit at the top; the middle section is throughput and latency — how many queries, how long they take, how long they wait, and how much split work is in flight; the bottom section is the pressure half, where the memory pool, worker health, and error codes name the thing that is actually breaking.

Which cards belong on a Presto or Trino monitoring dashboard?

Eight cards. Four describe the workload, four describe the pressure it puts on the cluster — and it is the pairing that makes the dashboard diagnostic rather than decorative.

• Queries by hour and final state — finished, failed, cancelled (stacked bar)
• Query wall time, p50 and p95 by hour (line)
• Queue time vs. execution time by resource group (line)
• Splits in flight — queued and running across the workers (area)
• Cluster memory pool reserved against total distributed bytes (line)
• Failures by error code — memory limit, no nodes available, syntax (row)
• Worker nodes and CPU time per hour (combo)
• Top queries by CPU time, with splits and bytes scanned (table)

What data does the dashboard need?

• system.runtime.queries — the coordinator’s live view: state, user, source, resource_group_id, queued_time_ms, analysis_time_ms, planning_time_ms, and the query text. Recent queries only.
• system.runtime.tasks — per node and stage: queued_splits, running_splits, completed_splits, split_cpu_time_ms, raw_input_bytes, and raw_input_rows.
• system.runtime.nodes for the worker roster — node_id, coordinator, node_version, and state (active, inactive, shutting down).
• The JMX connector for memory: jmx.current."trino.memory:name=general,type=clustermemorypool" gives free and total distributed bytes, blocked nodes, and assigned queries (com.facebook.presto.memory on Presto).
• An event-listener table of QueryCompletedEvent rows — wall, queued, and CPU time, peak user memory, completed splits, total bytes, and failureInfo.errorCode. This is what every trend card reads.

How do you build it?

1. Connect Presto or Trino to Metabase with a read-only user, and make sure the catalog list includes system and jmx — they are ordinary catalogs, and without them half the cards have no source.
2. Turn on an event listener that persists QueryCompletedEvent to a table the cluster can query, then expose that table through the same connection. Without it you have a status page, not a dashboard.
3. Model the event table once — milliseconds to seconds, a duration bucket, a normalized query fingerprint, and the resource group parsed out of resource_group_id — so no two cards disagree about what “slow” means.
4. Build the queue-time and memory-pool cards first. Together they tell you whether the cluster is admission-bound or execution-bound, which is the only question worth answering before you tune anything.
5. Add filters for cluster, resource group, and date range, and alert the platform channel when reserved memory crosses its threshold or the failure rate doubles.

Example card SQL

SELECT
date_trunc('hour', end_time)                             AS hour,
resource_group,
count(*)                                                 AS queries,
count_if(state = 'FAILED')                               AS failed,
round(approx_percentile(queued_time_ms, 0.95) / 1000.0, 2)
                                                         AS queue_p95_s,
round(approx_percentile(wall_time_ms, 0.50) / 1000.0, 2) AS wall_p50_s,
round(approx_percentile(wall_time_ms, 0.95) / 1000.0, 2) AS wall_p95_s,
round(sum(cpu_time_ms) / 3600000.0, 1)                   AS cpu_hours,
sum(completed_splits)                                    AS splits,
round(sum(total_bytes) / power(1024, 4), 2)              AS tb_scanned
FROM metrics.query_events
WHERE end_time >= current_timestamp - interval '14' day
GROUP BY 1, 2
ORDER BY 1, 2;

Related

Metrics

Integrations

Dashboards

FAQ