Skip to main content

Overview Tab: Metric Reference

This page is the source of truth for the in-app Explain this panels on the Database Explorer detail view's Overview tab. Each section is written once as a content partial under _explain/ and rendered both here and inside the dashboard's info panel (scripts/build-explain.mjs compiles the registry).

The Overview tab is available for all six supported engines. The summary tiles adapt to the engine: every engine shows a size, an object count, and a connections tile, and the throughput tile is Transactions/sec (PostgreSQL, SQL Server), Executions/sec (Oracle), or Operations/sec (MongoDB, Redis, Valkey).

Database Size​

How much space this database occupies, as the engine itself reports it. On Redis and Valkey the tile is labeled Memory Usage, because memory is their storage.

How it's calculated​

  • The agent asks the engine for its own size figure and Logstag shows the latest value for the selected window, with the trend compared against the preceding window.
  • Sizes are shown in adaptive units (MB, GB, …).

Source by engine​

EngineSource
PostgreSQLpg_database_size() — when unavailable on a managed service, Logstag falls back to summing the sizes of the database's objects
MongoDBthe dbStats command
Redis / Valkeyused_memory from INFO memory
SQL Serverthe engine's database size statistics
Oraclethe engine's database size statistics

Reading it​

Watch the slope, not the number. Databases are supposed to grow; what deserves attention is a change in the growth rate — a sudden jump usually maps to a bulk load or a runaway log/temp structure, and a sudden drop to a cleanup or a restore. The Schema tab's size treemap shows which objects the space actually lives in.

Objects​

How many objects the database contains. The label adapts to the engine's object model: Objects on PostgreSQL, SQL Server, and Oracle; Collections & Indexes on MongoDB; Total Keys on Redis and Valkey.

How it's calculated​

  • Relational engines count schema objects from the agent's schema inventory — for PostgreSQL, the current table and index inventory.
  • MongoDB counts collections and indexes; Redis and Valkey report the key count from DBSIZE.
  • The trend arrow compares against the preceding window.

Reading it​

This is a structural pulse, not a performance number. It normally moves only when deployments create or drop objects — so an unexplained change is worth a look at the Schema tab's object list and, for audited environments, the schema-change history. On Redis, a steadily climbing key count with flat memory usually means many small keys; the reverse means fewer, bigger values.

Connections​

How many client connections the database currently has. On MongoDB the tile is labeled Server Connections, because connection counts there are reported for the server process.

How it's calculated​

  • The agent samples the engine's connection figures on its collection intervals; the tile shows the latest value for the selected window with a trend against the preceding window.

Source by engine​

EngineSource
PostgreSQLpg_stat_activity session samples
SQL Serversys.dm_exec_sessions session samples
MongoDBserverStatus connection counters
Redis / ValkeyINFO clients
Oraclev$session samples

Reading it​

Judge it against the connection limit and the pool size, not in isolation. A count parked near the engine's maximum is an outage waiting for one traffic spike. For the split between active and idle — and the per-session detail — the Activity Explorer's Connections tab is the drill-down surface.

Transactions/sec​

The database's transaction throughput, per second. This tile appears for PostgreSQL and SQL Server; Oracle shows Executions/sec and MongoDB, Redis, and Valkey show Operations/sec instead.

How it's calculated​

  • The agent collects the engine's cumulative transaction counters — xact_commit and xact_rollback from pg_stat_database on PostgreSQL, the transaction performance counters on SQL Server — and Logstag turns the window's growth into a rate.
  • The trend arrow compares against the preceding window.

Reading it​

This is the database's heartbeat. Learn its daily rhythm, then read deviations against that rhythm rather than any absolute number: a flatline during business hours is an application problem before it is a database problem, and a spike with rising query latency in the trend charts below means the workload outgrew something — plans, indexes, or hardware.

Executions/sec​

The rate of SQL statement executions per second on this Oracle database — Oracle's counterpart to the Transactions/sec tile other engines show.

How it's calculated​

  • The agent collects execution counters from Oracle's SQL statistics (v$sqlarea), and Logstag turns the window's growth into a per-second rate.
  • Executions are used rather than commit counts because they track the workload Oracle actually processes, including read-only statements that never commit.
  • The trend arrow compares against the preceding window.

Reading it​

Read it the same way as a transaction rate: as the workload baseline. Because it counts executions, a jump here without an application change often means more statements per unit of work — the classic N+1 signature — which the Insights page detects and the Activity Explorer's Wait Activity tab can attribute to specific SQL_IDs.

Operations/sec​

The rate of operations per second — the throughput tile for engines whose unit of work is the operation rather than the transaction: MongoDB, Redis, and Valkey.

How it's calculated​

  • MongoDB: the agent reads the server's operation counters (serverStatus opcounters — inserts, queries, updates, deletes, and the rest) and Logstag turns the window's growth into a rate.
  • Redis and Valkey: command counters from INFO, turned into a rate the same way.
  • The trend arrow compares against the preceding window.

Reading it​

The absolute rate matters less than its relationship to latency and hit rates. On MongoDB, compare against the Server Operations chart below to see which operation type moved. On Redis, an operations spike with a falling keyspace hit rate means the working set changed — new keys are being asked for that aren't there yet.

Database Information and Server Resources​

Beside the health ring, an information card shows the database's identity and its host's resource pressure: the engine and version, the hosting instance, and — where system metrics are collected — average CPU and memory usage plus network throughput for the server. These are host-level figures: databases sharing an instance share them.

On Oracle databases without a Diagnostics Pack license, an additional card notes that Active Session History collection is unavailable for this database.

Database Health​

A single 0–100 score summarizing the database's health, with the five dimension scores that feed it. The ring's color follows the score band, and each dimension row can jump straight to the alerts behind it.

The dimensions​

  • Performance — query efficiency, resource contention, and throughput.
  • Security — authentication settings, privilege management, and encryption.
  • Configuration — server parameter tuning and best-practice settings.
  • Schema — index coverage, constraint integrity, and object design.
  • Maintenance — vacuuming, backup status, and replication health.

How it's calculated​

  • Each dimension is scored 0–100 from the health signals Logstag evaluates for that area of the engine.
  • Overall health is the weighted average of the dimension scores: Performance 30%, Security 25%, Configuration 20%, Schema 15%, Maintenance 10% — the same weights the in-app info icon shows.
  • When a dimension is not applicable for an engine, it is excluded and the remaining weights are re-normalized. For Redis and Valkey, Security and Maintenance are not applicable — note that the Schema dimension still applies to them even though the Schema tab is hidden, because key-design signals are still scored.
  • The score bands are: 80–100 Healthy (green), 60–79 Warning (amber), 0–59 Critical (red).
  • A database whose metrics have not been collected yet shows a pending state instead of a score.

Reading it​

Treat the overall number as a triage order, not a verdict — two databases at 74 can be amber for entirely different reasons. The dimension rows tell you which area is dragging the score down, and the arrow on a row opens the Alerts tab pre-filtered to exactly the alerts responsible. Fixing the underlying alerts is what moves the score; the score itself is never edited directly.

Trend Charts​

The time-series charts for this database over the selected window. There are two groups: key-metric charts tracking the summary tiles over time (size, connections, throughput), and engine charts showing deeper operational signals specific to the engine.

What each engine shows​

  • PostgreSQL — key metrics: Database Size, Connections, Transactions; engine charts: Query Latency, Disk IO, Deadlocks, Table Scans, Index Scans.
  • SQL Server — key metrics: Database Size, Objects, Connections, Transactions; engine charts: Query Latency, Disk IO, Lock Wait, Deadlock Rate, Table Scans, Index Scans.
  • Oracle — key metrics: Database Size, Connections, Executions; engine charts: Query Latency, Disk IO, Wait Events, Blocking Locks.
  • MongoDB — key metrics: Database Size, Collections & Indexes, Server Connections; engine charts: Server Operations, Data vs Index Size.
  • Redis / Valkey — key metrics: Memory Usage, Total Keys, Connections; engine charts: Operations, Keyspace Hit Rate.

How to read them​

  • All charts share a synchronized hover — moving the cursor on one moves it on all, so you can line up cause and effect across signals at the same instant.
  • Gaps in a line are honest: they mean no samples were collected for that stretch, not zero. An isolated dot is a real data point whose neighbors are missing.
  • The footer under each chart names the time window the data covers; changing the window from the top bar re-scopes every chart at once.
  • An empty chart means the signal applies to this engine but nothing was collected in the window — usually a collector that has not run yet or a quiet database.

Reading it​

Start with the key metrics for the "what changed" and use the engine charts for the "why": rising query latency with rising table scans and flat index scans is a missing index; rising disk IO with a falling cache-hit signal is a working set outgrowing memory. When a chart moves at a fixed time every day, it is a scheduled job introducing itself.