Skip to content

Query, session, logs & HA

Real DB-native telemetry — long-running queries, sessions, native logs, and HA health.

Slow queries

Set a duration threshold to surface queries running longer than expected across every connection — with the real running statement, user, database, and duration from the engine (pg_stat_activity, MongoDB currentOp, …). Inspect before acting; killing a query is permission-gated and audited.

Live sessions

The session manager lists active sessions per connection (or fleet-wide) with user, database, state, client, and age. Terminate one with the kill action — one slow or unreachable database never blocks the rest of the scan.

Wait-event analysis

The Activity view samples a connection live (every 3s) and groups its active sessions by what they're waiting on — CPU (running), Lock, I/O, LWLock, Client, Timeout — straight from pg_stat_activity, each with a representative query (MySQL groups by thread state; SQL Server, Oracle, and IBM Db2 map their native wait classes — dm_exec_requests, v$session, WLM agents — into the same buckets). Stat cards split sessions into "on CPU" vs "waiting" and a stacked bar shows the mix, so you can immediately tell whether the database is CPU-, lock-, or I/O-bound. A "Top SQL by wait" panel then attributes that activity to the actual statements — the queries with the most sessions, how many are waiting vs on CPU, and their dominant wait (PostgreSQL, MySQL/MariaDB, SQL Server, Oracle) — so you land on the exact query to fix. The platform also samples waits continuously into Active Session History — a stacked wait chart over 1h/6h/24h plus a ranked "top waits" list — so you can diagnose a past slowdown, not only a live one.

Lock contention

On PostgreSQL, MySQL/MariaDB, SQL Server, Oracle, and IBM Db2, a blocking-chain panel shows every blocked session paired with the session holding the lock it waits on — the lock type and contended object, how long the victim has waited, and both sessions' user, pid, and running query. The blocker's state is flagged (idle-in-transaction is the classic culprit) and you can kill the blocker to release the chain, all audited. Read from the engine's lock views (pg_locks, sys.innodb_lock_waits, sys.dm_tran_locks, V$LOCK, SYSIBMADM.MON_LOCKWAITS) — no locks taken.

Native server logs

Read each database's real server log — via the engine's client API (PostgreSQL, MySQL, MongoDB, SQL Server, Oracle, Redis, Cassandra, Db2) or an SSH file source for file-only logs (Elasticsearch, or PostgreSQL with logging_collector off). Filter by level and search — these are the database's own diagnostics, not application events.

Advisors

Three advisors turn telemetry into action across the SQL engines: the Index Advisor mines captured slow queries for missing-index patterns, emitting ready-to-review CREATE INDEX DDL (PostgreSQL, MySQL/MariaDB, SQL Server, Oracle); the Maintenance Advisor reads each engine's statistics catalogs to surface bloat needing VACUUM, unused indexes, stale planner statistics, fragmentation, and tables missing optimizer statistics (adds IBM Db2 — RUNSTATS); and the Configuration Audit assesses server settings against security, reliability, performance, and observability best practices (TLS, durability, autovacuum, timeouts, password hashing, logging) with the current value, the recommended value, and why it matters — on all five engines (PostgreSQL, MySQL/MariaDB, SQL Server, Oracle, IBM Db2), and every finding is mapped to its CIS Benchmark domain with an open-gaps-by-domain posture rollup. All rank by impact and are advisory — nothing is applied automatically.

Replication & HA

The Replication & HA view draws a visual topology graph — each primary as a node with connector lines to its replicas, colored by health and labelled with per-member lag — mapping primary/replica roles fleet-wide with every cluster member (role, state, lag, health) read straight from the engine (PostgreSQL pg_stat_replication, MongoDB rs.status(), Redis INFO replication, MySQL/MariaDB SHOW REPLICAS, SQL Server Always On availability groups, Oracle Data Guard), plus an HA-health badge that flags degraded clusters or single nodes with no failover target.

Try it yourself

Open the console and put this into practice.

Open the console