Dynatrace connection pool alerts: saturation threshold vs acquisition wait time for early exhaustion detection

Answer

OneAgent exposes the following JDBC‑pool metrics for HikariCP, Tomcat JDBC and Apache DBCP2:

• jdbc.connection.pool.active
• jdbc.connection.pool.idle
• jdbc.connection.pool.max
• jdbc.connection.pool.wait.time (average acquisition wait time)

The wait‑time metric is present for HikariCP and Tomcat JDBC in all recent OneAgent versions; for DBCP2 it appears only when the pool is configured with fairQueue (or similar) – otherwise the value may be zero or absent.

Early‑warning reliability

A percentage‑of‑maximum alert (e.g., active/max > 80 %) fires before the pool reaches 100 % utilization and works uniformly across services because it is relative. A wait‑time alert (e.g., average wait > 50 ms) can detect contention even when the pool is not full, but it may be missing for pools that do not instrument acquisition latency, leading to false‑negatives if relied on exclusively.

Recommended configuration

1. In the Dynatrace UI, navigate to Metrics and verify that jdbc.connection.pool.wait.time shows non‑zero values under load for your pools.
2. Create a metric event using the derived utilization expression:

   (jdbc.connection.pool.active / jdbc.connection.pool.max) * 100

   Set the aggregation to average over a 5‑minute window and the threshold to 80 %.
3. (Optional) Add a second metric event on jdbc.connection.pool.wait.time with a threshold appropriate for your latency SLA (e.g., > 50 ms) and the same 5‑minute average.
4. Set the alert scope to the relevant process group and enable Split by dimension on dt.entity.process_group. This automatically evaluates the threshold for each group without creating separate rules.
5. Save the rule and validate by generating steady load; the utilization event should trigger before the active count reaches the max.

Missing diagnostic detail

Please confirm your OneAgent version so we can verify whether jdbc.connection.pool.wait.time is available for your DBCP2 pools; if it is missing, rely on the utilization‑based alert alone.