Database observability Dynatrace: slow queries with PostgreSQL

It is 10:40, checkout takes eight seconds to respond, and the application dashboard points a finger at « the database ». Database observability Dynatrace offers a way past that vague suspicion: an application called Databases, fed by an extension that an ActiveGate uses to query PostgreSQL. Here is how I would run it, from the suspicious trace down to the execution-plan node that burns the time.

One framing note first: everything below is about Dynatrace SaaS. The pages I read talk about Grail, the Hub and the Platform Subscription, and nothing says Managed behaves the same, so I do not claim it. If you only want the extension itself, another post covers it: the database extension article. This one starts from the symptom.

Database observability Dynatrace: from symptom to query

A trace shows a SQL call lasting several seconds. That proves the database is making someone wait, nothing more. To act, you need three answers in order: which statement weighs most over the period, where its time goes (compute, disk, locks), and which node of its plan is responsible. The Databases app answers all three, provided the extension is in place. Without it, the tabs stay stubbornly empty.

No agent runs on the database servers: the extension reads metrics and query statistics remotely. The useful tabs are Overview (overall health), Explorer (CPU, memory, active sessions per instance), Databases, Tables and Indexes (including low-value indexes), Recommendations (extension version, databases found but unmonitored, missing plans) and Alert templates (ready-made alerts per vendor). Other engines are covered too: Oracle, SQL Server, MySQL, Snowflake, SAP HANA, DB2, MariaDB. I only read the PostgreSQL page closely.

Before opening the console: a field checklist

What has cost me the most time elsewhere is meeting a prerequisite halfway through a wizard. So I check these first:

• the Databases app is installed from the Hub;
• an Environment ActiveGate on 1.341.0 or later, with the Extension Execution Controller on, can reach the PostgreSQL server (see Environment ActiveGate or Cluster ActiveGate);
• the PostgreSQL extension is at 3.2.4 or later (3.1.2 for MySQL);
• you hold settings:objects:write on builtin:licensing.new-database-monitoring-experience, or the Settings Writer policy, and this monitoring is part of your Platform Subscription;
• the connection goes straight to the monitored host: no load balancer, proxy or pooler such as pg-pool, otherwise a failover muddles the measurements;
• log ingestion is on, since top queries are stored as logs.

Getting PostgreSQL ready without surprises

Two settings decide the quality of the data. First, pg_stat_statements must be in shared_preload_libraries; self-hosted, that means editing postgresql.conf and restarting, and also installing the hypopg binaries. On RDS, Cloud SQL or Azure, the provider’s parameter group is the source of truth. Second, track_activity_query_size must be raised to 4096: at the default 1024, long queries arrive cut off and become unreadable.

You then need a dedicated read-only account through the pg_monitor role, plus a dynatrace schema that will hold the function used to fetch plans. The capture below, taken from the documentation, shows the SQL to run.

The password behind the <PASSWORD> placeholder should come from your vault, not a shared file. On RDS or Aurora, IAM authentication removes that secret altogether (ActiveGate 1.325 or later).

Declaring the instance in the wizard

« Add DB instance » walks through six screens, which I summarise by what actually matters. Pick PostgreSQL as vendor, then the ActiveGate group: it will carry the polling load, so choose one with a network view of the database. Next comes configuration: frequency and feature sets, chiefly Queries and Index Recommendations. For the connection, the documentation advises one database per instance, often postgres. Finally, two scripts to download, install and validation, to run from a Unix machine with Bash and psql. Once validation passes, « Start monitoring » begins collection.

First check: in Recommendations, « Monitor extension status » should read « Up to date » with a clean extension log, and the instance should show in Explorer. Data lands in the Grail bucket default_database_monitoring.

Tracking down the guilty query

Three streams feed the analysis, all stored as logs and recognisable by their event.group:

• top_queries: the 100 costliest statements by cumulative time, sampled from pg_stat_statements every 5 minutes;
• longest_queries: the longest executions seen in pg_stat_activity, with the Queries feature set;
• execution_plans: the plan of a top query, fetched through the helper function.

In the statement analysis view, I filter on a fragment of SQL text and flip between Time, CPU, Disk and Waits. My own rule of thumb (it is not from the documentation): lots of Time and little CPU means the query is waiting, on locks or I/O; lots of both means pure computation, and the plan probably has a problem.

Then open the plan. The diagram gives each node a cost and highlights the heaviest. In the example below, a single join absorbs 95.7% of the total cost across seven nodes, so there is no point fussing over the rest.

Source : docs.dynatrace.com

If the dominant node is a full table scan on a very frequent query, suspect a missing index: hypopg exists precisely to try hypothetical indexes without creating them. To cross-check against what applications write in their logs, the method in log pattern analysis pairs well with this work.

Where it can bite

• ALTER statements are kept out of top queries, for security.
• Getting a plan needs extensions:configuration.actions:write, and the request must come from the database that hosts the helper function.
• On managed services, monitoring has limits and needs manual setup, per the documentation.
• The extension is free but ingested metrics are billed, logs on top. The doc’s estimate: (68 × instances) + (40 × databases) + (1 × tablespaces) data points per minute.
• After every extension update, re-run the install and validation scripts, or metrics, top queries or plans may stop.
• Not verified here: MySQL details, Dynatrace Managed, and any DQL query on these logs (so I offer none).

My adoption plan

Start on a test database with a single feature set, watch the data-point bill, then widen. Reserve an ActiveGate group for databases, with validated network rules. Restrict read access to the default_database_monitoring bucket through a dedicated policy. Finally, tie a SQL latency threshold to an objective: the SLO and SLA learning path shows how.

Frequently asked questions

Do I need OneAgent on the database server?

Not for the extension, which runs without an agent on database hosts: an ActiveGate queries the database remotely. The host metrics shown in Overview, however, come from hosts running OneAgent.

Does this method work with MySQL?

The upgrade page lists MySQL 3.1.2 or later with the same wizard. MySQL grants and settings are not verified here; follow the MySQL extension page.

Where can I see slow queries without opening the application?

Top queries, longest queries and plans are logs tagged by event.group: look for them in the log tool, after checking the bucket and your read permissions.

In short

For Database observability Dynatrace, remember the sequence: prepared instance, extension set up by the wizard, then reading top queries, the Time/CPU/Disk/Waits axes and the execution plan. Source: Dynatrace documentation, Get started with database monitoring.

This blog is independent and not affiliated with Dynatrace LLC. The information comes from the official documentation, read in November 2026; check it before any production use.

---

Originally published on span.observer. French version: https://span.observer/fr/database-observability-dynatrace/.