Weekly Trino Cluster Health Digest to Discord

Trino tells you everything about its own workload through the system.runtime.queries catalog, but only if someone looks. This blueprint looks every Monday: one io.kestra.plugin.jdbc.trino.Query with fetchType: FETCH_ONE aggregates the last seven days of query history into completed and failed counts plus the longest wall time, and posts the digest to Discord before the ops review.

How it works

1. cluster_stats (io.kestra.plugin.jdbc.trino.Query, fetchType: FETCH_ONE) queries system.runtime.queries, counting queries by state with count_if and computing the maximum wall time as date_diff('second', created, "end"). The quoted "end" column is a reserved word in SQL, and coalesce keeps the metric at 0 on quiet clusters. The single result row is addressable as {{ outputs.cluster_stats.row.* }}.
2. notify interpolates the four scalars into a Discord message: total, completed, failed, and longest wall time in seconds.
3. The errors block posts a distinct Discord alert when the digest itself fails, which usually means the coordinator is unreachable, a health signal in its own right.
4. A disabled-by-default Schedule trigger runs the digest every Monday at 07:00.

What you get

• A weekly failure-rate and slowest-query baseline for the cluster, delivered where the team already reads.
• Trend visibility: a rising failed count or wall time stands out week over week in the channel history.
• A monitor that degrades loudly, since an unreachable coordinator produces an alert instead of a skipped digest.
• One place to add more runtime metrics as the team's questions evolve.

Who it's for

• Platform engineers operating a shared Trino cluster for many teams.
• Data engineering leads who want workload health in the standup channel, not in a dashboard nobody opens.
• Teams establishing a baseline before capacity planning or version upgrades.

Why orchestrate this with Kestra

The runtime catalog only holds what the coordinator currently remembers, so the value comes from sampling it on a reliable schedule and keeping the results somewhere durable. Kestra provides the schedule, retries against a briefly busy coordinator, an execution history that preserves each week's numbers, and delivery to Discord, all as a few lines of reviewable YAML.

Prerequisites

• A Trino user allowed to read system.runtime.queries; visibility of other users' queries depends on your access control rules.
• Awareness that system.runtime.queries reflects the coordinator's in-memory history, so a coordinator restart shortens the window; back the digest with an event listener or query log for strict completeness.
• A Discord incoming webhook for the digest and alerts.

Secrets

• TRINO_URL: JDBC URL, e.g. jdbc:trino://host:443/system/runtime (use https on 443 in production; password authentication requires TLS).
• TRINO_USERNAME: Trino username.
• TRINO_PASSWORD: Trino password.
• DISCORD_WEBHOOK_URL: Discord incoming webhook URL.

Quick start

1. Add the four secrets to your Kestra namespace.
2. Execute the flow manually and confirm the Discord digest shows plausible counts.
3. Adjust the window or the metrics to your ops review cadence.
4. Set disabled: false on the weekly trigger.

How to extend

• Add count_if(state = 'RUNNING') and queue metrics like queued_time_ms percentiles to spot saturation.
• Break the digest down per user or source with a second query to find noisy tenants.
• Turn the weekly digest into a daily gate by combining it with the data quality gate pattern and failing on a failure-rate threshold.
• Store each week's row in an Iceberg table with an INSERT task to build a long-term health history beyond coordinator memory.

Links

• Trino plugin documentation
• Trino system connector documentation