Add richer Prometheus metrics: connection queue depth, wait time, SQL execution time, pool stats, slot activity (regular + XA) by Copilot · Pull Request #363 · Open-J-Proxy/ojp

Copilot · 2026-02-24T10:19:11Z

OJP previously exposed only gRPC-level metrics via OpenTelemetry. This adds eleven custom Prometheus metrics covering the three highest-value gaps: connection queue depth, connection wait time, and per-statement SQL execution time — plus pool stats (for both HikariCP and XA pools) and slot activity.

New metrics (`/metrics`)

Metric	Type	Labels
`ojp_connection_queue_depth`	UpDownCounter	`conn_hash`
`ojp_connection_wait_time_ms`	Histogram	`conn_hash`, `outcome` (success/failure)
`ojp_sql_execution_time_ms`	Histogram	`sql` (truncated SQL text)
`ojp_pool_active_connections`	ObservableGauge	`pool`
`ojp_pool_idle_connections`	ObservableGauge	`pool`
`ojp_pool_pending_threads`	ObservableGauge	`pool`
`ojp_xa_pool_active_sessions`	ObservableGauge	`pool`
`ojp_xa_pool_idle_sessions`	ObservableGauge	`pool`
`ojp_xa_pool_pending_threads`	ObservableGauge	`pool`
`ojp_slot_active_slow`	UpDownCounter	—
`ojp_slot_active_fast`	UpDownCounter	—

Pool gauge pool labels use the format <dsName>_<4-char-hash> for HikariCP pools and <dsName>_xa_<4-char-hash> for XA pools, where <dsName> is the OJP datasource name configured in OJP (defaulting to "default" if none is set). This keeps labels human-readable while guaranteeing uniqueness even when a non-XA and XA pool share the same datasource name in the same connection. No JDBC URL or database server details are ever exposed in metric labels.

The sql label on ojp_sql_execution_time_ms contains the first 100 characters of the normalised (lower-cased, whitespace-collapsed) SQL text, giving human-readable metric labels while keeping Prometheus cardinality bounded.

ojp_connection_queue_depth and ojp_connection_wait_time_ms cover both regular connection acquisition and XA session borrowing.

Key changes

OjpMetrics (new) — owns all custom OTel instruments; injected as an optional dependency (null-safe throughout, no behaviour change when telemetry is disabled); includes toSqlSnippet() helper that normalises and truncates SQL text; uses a pre-compiled regex for whitespace collapsing on the hot path; buildPoolLabel(dsName, connHash, xa) builds consistent, human-readable pool labels using the OJP datasource name (falls back to "default") and the first 4 chars of the connection hash; registerDatasource(connHash, poolLabel, ds) and registerXaPool(connHash, poolLabel, ds) accept a separate label so the internal registry key (full connHash) is decoupled from the display label
OjpServerTelemetry — exposes getOpenTelemetry() and createOjpMetrics() so custom metrics share the same Prometheus endpoint as gRPC metrics; fixed a pre-existing bug in the 9-param createGrpcTelemetry overload where the result was assigned to a local variable instead of this.openTelemetry
ConnectionAcquisitionManager — new overload accepts OjpMetrics; increments/decrements queue_depth around getConnection() and records wait_time_ms
SlowQuerySegregationManager — new constructor accepts OjpMetrics; emits slot counters (slow/fast slot acquired/released) on acquire/release. SQL execution time recording is intentionally kept outside this class so it fires regardless of whether slow query segregation is enabled or disabled
StatementServiceImpl — try-finally timing blocks in executeUpdate() and executeQuery() call ojpMetrics.sqlExecuted() unconditionally; timing uses System.nanoTime() for precision. ojp_sql_execution_time_ms is always recorded as long as OpenTelemetry is enabled, independent of slow query segregation configuration
HandleXAConnectionWithPoolingAction — sets xa.poolName to the friendly pool label so OpenTelemetryPoolMetrics uses it as the pool.name attribute; registers the XA pool with ojpMetrics.registerXaPool(); wraps borrowSession() with connectionWaitStarted()/connectionAcquired() in try-finally to record XA session borrow queue depth and wait time
OpenTelemetryPoolMetrics — stores all 8 ObservableDoubleGauge references as fields; close() now calls .close() on each gauge, properly unregistering their callbacks from the OTel SDK and preventing DuplicateLabelsException if a pool with the same name is recreated
ActionContext / GrpcServer — wire OjpMetrics through the call stack; GrpcServer.main() creates the instance only when ojp.opentelemetry.enabled=true and passes it to StatementServiceImpl
ConnectAction — calls ojpMetrics.registerDatasource(connHash, poolLabel, ds) with a friendly label derived from the OJP datasource name when a new HikariCP datasource is created

Usage

# Prometheus scrape — new metrics alongside existing gRPC ones
$ curl http://ojp-server:9159/metrics | grep ojp_sql
ojp_sql_execution_time_ms_bucket{sql="select id, name from users where active = true",le="100"} 42

$ curl http://ojp-server:9159/metrics | grep pool
ojp_pool_active_connections{pool="myds_a1b2"}    5
ojp_xa_pool_active_sessions{pool="myds_xa_a1b2"} 3

# If no datasource name is configured:
ojp_pool_active_connections{pool="default_a1b2"}    5
ojp_xa_pool_active_sessions{pool="default_xa_a1b2"} 3

Backward-compatible: all constructors/methods that don't pass OjpMetrics continue to work unchanged.

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

…execution time, pool stats, slot metrics Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>

rrobetti · 2026-02-24T11:00:00Z

@copilot why ojp_sql_execution_time_ms uses the sql hash as label? this make readability difficult.

…cution_time_ms metric Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>

Copilot · 2026-02-24T11:08:20Z

@copilot why ojp_sql_execution_time_ms uses the sql hash as label? this make readability difficult.

The hash was used because SlowQuerySegregationManager only received the hash, not the original SQL. Fixed in a77ddb1:

The sql_hash label is replaced with sql, whose value is the first 100 chars of the normalised (lower-cased, whitespace-collapsed) SQL text — readable in Prometheus without cardinality explosion
SlowQuerySegregationManager.executeWithSegregation now accepts (hash, sql, operation) so the SQL text flows through to the metric; StatementServiceImpl passes request.getSql() at both call sites
The whitespace regex is pre-compiled once (not per call) for performance
The hash-only backward-compat overload labels measurements as [hash:<value>] so they're clearly identifiable if the SQL text is ever unavailable

Example metric in Prometheus after the change:

ojp_sql_execution_time_ms_bucket{sql="select id, name from users where active = true",le="100"} 42

rrobetti · 2026-02-24T11:19:14Z

@copilot does this mean that if the slow query segregation is disabled we cannot collect the metrics? if so the collection of execution time needs to be removed somewere else and be active if any of slow query segration or advanced telemetry is enabled.

…move to StatementServiceImpl Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>

Copilot · 2026-02-24T11:26:59Z

@copilot does this mean that if the slow query segregation is disabled we cannot collect the metrics? if so the collection of execution time needs to be removed somewere else and be ...

Correct observation — it was an architectural coupling rather than an actual gap (the !enabled branch still called executeAndMonitor), but it was wrong for the metric to live inside SlowQuerySegregationManager at all. Fixed in 52c3961:

Removed sqlExecuted() from SlowQuerySegregationManager.executeAndMonitor(). The class now only emits slot metrics (slow/fast slot acquired/released).
Moved the timing into StatementServiceImpl.executeUpdate() and executeQuery() using a try-finally block wrapping the executeWithSegregation() call. ojpMetrics.sqlExecuted() fires there unconditionally — regardless of whether slow query segregation is enabled, disabled, or not configured — as long as OpenTelemetry is enabled.
Switched from System.currentTimeMillis() to System.nanoTime() for more accurate elapsed-time measurement.

rrobetti · 2026-02-25T21:14:07Z

Must evaluate this one first #318

rrobetti · 2026-02-28T17:18:29Z

@copilot review the latest commit to main branch which introduced, especially metrics for XA pools as well. evaluate how that affects this PR. Ideally we want to apply these advanced metrics in the XA implementation as well.

Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>

Copilot · 2026-02-28T17:28:39Z

@copilot review the latest commit to main branch which introduced, especially metrics for XA pools as well. evaluate how that affects this PR. Ideally we want to apply these advanced...

Done in a740c02. The XA path now has full metric coverage parity with regular connections:

New XA pool gauges (read from CommonsPool2XADataSource on each Prometheus scrape):

ojp_xa_pool_active_sessions{conn_hash="..."} 3
ojp_xa_pool_idle_sessions{conn_hash="..."}   7
ojp_xa_pool_pending_threads{conn_hash="..."}  0

Existing metrics extended to XA:

ojp_connection_queue_depth — increments when borrowSession() is called, decrements in finally
ojp_connection_wait_time_ms — records the XA session borrow wait time with outcome=success|failure

Also fixed a merge artifact from main where ActionContext and StatementServiceImpl constructors still referenced the old CircuitBreaker type instead of CircuitBreakerRegistry.

rrobetti · 2026-02-28T17:44:20Z

@copilot test failure
[INFO]
Error: Errors:
Error: GrpcServerHealthTest.testHealthEndpointServing:75->assertHealthStatus:105 » StatusRuntime UNAVAILABLE: io exception

…GrpcTelemetry; wire ojpMetrics into StatementServiceImpl Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>

Copilot · 2026-02-28T17:57:34Z

@copilot test failure
[INFO]
Error: Errors:
...

Fixed in db79b1a. Root cause was a pre-existing bug in OjpServerTelemetry.createGrpcTelemetry (9-param overload, introduced in the XA metrics PR merged to main) — it declared a local variable OpenTelemetry openTelemetry = sdkBuilder.build() instead of assigning to the class field this.openTelemetry. This was harmless on main because createOjpMetrics() was never called there. My changes to GrpcServer.main() added the createOjpMetrics() call, which then found this.openTelemetry == null and threw IllegalStateException. The server thread crashed silently (the test swallows the exception), so the health check saw UNAVAILABLE.

Two fixes:

OjpServerTelemetry: OpenTelemetry openTelemetry = ... → this.openTelemetry = ...
GrpcServer.main(): pass ojpMetrics to StatementServiceImpl (it was created but never wired in)

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

999.999.999.999
- Triggering command: /usr/lib/jvm/temurin-21-jdk-amd64/bin/java /usr/lib/jvm/temurin-21-jdk-amd64/bin/java -jar /home/REDACTED/work/ojp/ojp/ojp-server/target/surefire/surefirebooter-20260228175652004_3.jar /home/REDACTED/work/ojp/ojp/ojp-server/target/surefire 2026-02-28T17-56-51_933-jvmRun1 surefire-20260228175652004_1tmp surefire_0-20260228175652004_2tmp (dns block)
invalid-ip
- Triggering command: /usr/lib/jvm/temurin-21-jdk-amd64/bin/java /usr/lib/jvm/temurin-21-jdk-amd64/bin/java -jar /home/REDACTED/work/ojp/ojp/ojp-server/target/surefire/surefirebooter-20260228175652004_3.jar /home/REDACTED/work/ojp/ojp/ojp-server/target/surefire 2026-02-28T17-56-51_933-jvmRun1 surefire-20260228175652004_1tmp surefire_0-20260228175652004_2tmp (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

Configure Actions setup steps to set up my environment, which run before the firewall is enabled
Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

rrobetti · 2026-02-28T18:09:11Z

@copilot got this error in the prometheus URL http://localhost:9159/metrics while trying to test metrics XA and non XA at the same time

An Exception occurred while scraping metrics: io.prometheus.metrics.model.snapshots.DuplicateLabelsException: Duplicate labels for metric "ojp.xa.pool.connections": {otel_scope_name="ojp.xa.pool",pool.name="ojp-xa-pool"}
at io.prometheus.metrics.model.snapshots.MetricSnapshot.validateLabels(MetricSnapshot.java:42)
at io.prometheus.metrics.model.snapshots.MetricSnapshot.(MetricSnapshot.java:27)
at io.prometheus.metrics.model.snapshots.GaugeSnapshot.(GaugeSnapshot.java:18)
at io.opentelemetry.exporter.prometheus.Otel2PrometheusConverter.merge(Otel2PrometheusConverter.java:596)
at io.opentelemetry.exporter.prometheus.Otel2PrometheusConverter.putOrMerge(Otel2PrometheusConverter.java:570)
at io.opentelemetry.exporter.prometheus.Otel2PrometheusConverter.convert(Otel2PrometheusConverter.java:124)
at io.opentelemetry.exporter.prometheus.PrometheusMetricReader.collect(PrometheusMetricReader.java:61)
at io.prometheus.metrics.model.registry.MultiCollector.collect(MultiCollector.java:21)
at io.prometheus.metrics.model.registry.PrometheusRegistry.scrape(PrometheusRegistry.java:84)
at io.prometheus.metrics.exporter.common.PrometheusScrapeHandler.scrape(PrometheusScrapeHandler.java:135)
at io.prometheus.metrics.exporter.common.PrometheusScrapeHandler.handleRequest(PrometheusScrapeHandler.java:56)
at io.prometheus.metrics.exporter.httpserver.MetricsHandler.handle(MetricsHandler.java:33)
at jdk.httpserver/com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:98)
at jdk.httpserver/sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:82)
at jdk.httpserver/com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:101)
at jdk.httpserver/sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:871)
at jdk.httpserver/com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:98)
at jdk.httpserver/sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:847)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1570)

…MetricsFactory key Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>

Copilot · 2026-02-28T18:14:28Z

@copilot got this error in the prometheus URL http://localhost:9159/metrics while trying to test metrics XA and non XA at the same time

An Exception occurred while scraping metric...

Fixed in a09d958. Two bugs combined to cause this:

HandleXAConnectionWithPoolingAction never set xa.poolName in xaPoolConfig, so every XA pool fell back to the default name "ojp-xa-pool". Two concurrent XA connections both registered ojp.xa.pool.connections.* gauges with {pool.name="ojp-xa-pool"} → DuplicateLabelsException.
PoolMetricsFactory was looking for key "ojp.xa.poolName" while CommonsPool2XADataSource uses "xa.poolName" — a key mismatch meant the factory always ignored whatever name was configured and fell back to the default.

Fixes:

HandleXAConnectionWithPoolingAction now sets xaPoolConfig.put("xa.poolName", connHash) — each XA pool gets a unique name matching its connection hash, consistent with how HikariCP pools are named
PoolMetricsFactory.POOL_NAME_KEY corrected from "ojp.xa.poolName" → "xa.poolName" to align with CommonsPool2XADataSource

After the fix, concurrent XA connections each get distinct pool.name labels:

ojp_xa_pool_active_sessions{pool_name="a1b2c3"} 2
ojp_xa_pool_active_sessions{pool_name="d4e5f6"} 1

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

999.999.999.999
- Triggering command: /usr/lib/jvm/temurin-21-jdk-amd64/bin/java /usr/lib/jvm/temurin-21-jdk-amd64/bin/java -jar /home/REDACTED/work/ojp/ojp/ojp-server/target/surefire/surefirebooter-20260228181345784_56.jar /home/REDACTED/work/ojp/ojp/ojp-server/target/surefire 2026-02-28T18-13-29_383-jvmRun1 surefire-20260228181345784_54tmp surefire_1-20260228181345784_55tmp (dns block)
invalid-ip
- Triggering command: /usr/lib/jvm/temurin-21-jdk-amd64/bin/java /usr/lib/jvm/temurin-21-jdk-amd64/bin/java -jar /home/REDACTED/work/ojp/ojp/ojp-server/target/surefire/surefirebooter-20260228181345784_56.jar /home/REDACTED/work/ojp/ojp/ojp-server/target/surefire 2026-02-28T18-13-29_383-jvmRun1 surefire-20260228181345784_54tmp surefire_1-20260228181345784_55tmp (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

Configure Actions setup steps to set up my environment, which run before the firewall is enabled
Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

rrobetti · 2026-02-28T18:19:12Z

@copilot error still happening
An Exception occurred while scraping metrics: io.prometheus.metrics.model.snapshots.DuplicateLabelsException: Duplicate labels for metric "ojp.xa.pool.connections": {otel_scope_name="ojp.xa.pool",pool.name="L5aNlM6Zip1Oe8vcKktrkfHL6NHC3qqGnrDo-zEqcuo"}
at io.prometheus.metrics.model.snapshots.MetricSnapshot.validateLabels(MetricSnapshot.java:42)

Also we should not be using the connection hash for this, can we not use the datasource name + 4 first chars of connection hash? Would that work?

…nup on pool recreation Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>

Copilot · 2026-02-28T18:30:24Z

@copilot error still happening
An Exception occurred while scraping metrics: io.prometheus.metrics.model.snapshots.DuplicateLabelsException: Duplicate labels for metric "ojp.xa.pool...

Fixed in d7aac6c. There were two independent root causes:

1. Pool recreation wasn't cleaning up gauge callbacks — OpenTelemetryPoolMetrics.close() logged a message but did nothing. All 8 ObservableDoubleGauge instruments are now stored as fields and .close() is called on each in close(), which unregisters their callbacks from the OTel SDK. Without this, any pool with the same pool.name that was recreated (e.g. on resize/reconnect) would register duplicate callbacks for the same label set.

2. Pool labels now use datasource name + _xa infix + first 4 chars of hash — OjpMetrics.buildPoolLabel(url, connHash, xa) extracts the database name from the JDBC URL and produces:

Regular pool: mydb_a1b2
XA pool: mydb_xa_a1b2

This satisfies the requirement of distinguishing a non-XA and XA pool on the same datasource while staying readable. Both ConnectAction (HikariCP) and HandleXAConnectionWithPoolingAction (XA) now build and pass this label at registration time. The internal registry key remains the full connHash for deregistration.

Example output after fix:

ojp_pool_active_connections{pool="mydb_a1b2"}    5
ojp_xa_pool_active_sessions{pool="mydb_xa_a1b2"} 3
ojp.xa.pool.connections.active{pool.name="mydb_xa_a1b2"} 3   # from OpenTelemetryPoolMetrics

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

999.999.999.999
- Triggering command: /usr/lib/jvm/temurin-21-jdk-amd64/bin/java /usr/lib/jvm/temurin-21-jdk-amd64/bin/java -jar /home/REDACTED/work/ojp/ojp/ojp-server/target/surefire/surefirebooter-20260228182812449_56.jar /home/REDACTED/work/ojp/ojp/ojp-server/target/surefire 2026-02-28T18-27-52_474-jvmRun1 surefire-20260228182812449_54tmp surefire_1-20260228182812449_55tmp (dns block)
- Triggering command: /usr/lib/jvm/temurin-21-jdk-amd64/bin/java /usr/lib/jvm/temurin-21-jdk-amd64/bin/java -jar /home/REDACTED/work/ojp/ojp/ojp-server/target/surefire/surefirebooter-20260228182935167_56.jar /home/REDACTED/work/ojp/ojp/ojp-server/target/surefire 2026-02-28T18-29-20_221-jvmRun1 surefire-20260228182935167_54tmp surefire_1-20260228182935167_55tmp (dns block)
invalid-ip
- Triggering command: /usr/lib/jvm/temurin-21-jdk-amd64/bin/java /usr/lib/jvm/temurin-21-jdk-amd64/bin/java -jar /home/REDACTED/work/ojp/ojp/ojp-server/target/surefire/surefirebooter-20260228182812449_56.jar /home/REDACTED/work/ojp/ojp/ojp-server/target/surefire 2026-02-28T18-27-52_474-jvmRun1 surefire-20260228182812449_54tmp surefire_1-20260228182812449_55tmp (dns block)
- Triggering command: /usr/lib/jvm/temurin-21-jdk-amd64/bin/java /usr/lib/jvm/temurin-21-jdk-amd64/bin/java -jar /home/REDACTED/work/ojp/ojp/ojp-server/target/surefire/surefirebooter-20260228182935167_56.jar /home/REDACTED/work/ojp/ojp/ojp-server/target/surefire 2026-02-28T18-29-20_221-jvmRun1 surefire-20260228182935167_54tmp surefire_1-20260228182935167_55tmp (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

Configure Actions setup steps to set up my environment, which run before the firewall is enabled
Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

rrobetti · 2026-02-28T18:33:36Z

@copilot I never told you to use the database name, that is a security risk. Use the datasource name in the OJP perspective, if none is set "default" is assumed.

… extractDbName Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>

Copilot · 2026-02-28T18:38:48Z

@copilot I never told you to use the database name, that is a security risk. Use the datasource name in the OJP perspective, if none is set "default" is assumed.

Fixed in 693afb9. extractDbName() is removed entirely — no JDBC URL is parsed. Pool labels now use the OJP datasource name (ojp.datasource.name client property, defaulting to "default" when not set):

ConnectAction passes dsConfig.getDataSourceName()
HandleXAConnectionWithPoolingAction passes xaConfig.getDataSourceName()
buildPoolLabel(dsName, connHash, xa) uses the name directly, falling back to "default" if null/blank

Label format:

ojp_pool_active_connections{pool="mydb_a1b2"}      # regular, dsName="mydb"
ojp_xa_pool_active_sessions{pool="mydb_xa_a1b2"}   # XA, dsName="mydb"
ojp_pool_active_connections{pool="default_a1b2"}   # no dsName configured

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

999.999.999.999
- Triggering command: /usr/lib/jvm/temurin-21-jdk-amd64/bin/java /usr/lib/jvm/temurin-21-jdk-amd64/bin/java -jar /home/REDACTED/work/ojp/ojp/ojp-server/target/surefire/surefirebooter-20260228183803560_56.jar /home/REDACTED/work/ojp/ojp/ojp-server/target/surefire 2026-02-28T18-37-48_572-jvmRun1 surefire-20260228183803560_54tmp surefire_1-20260228183803560_55tmp (dns block)
invalid-ip
- Triggering command: /usr/lib/jvm/temurin-21-jdk-amd64/bin/java /usr/lib/jvm/temurin-21-jdk-amd64/bin/java -jar /home/REDACTED/work/ojp/ojp/ojp-server/target/surefire/surefirebooter-20260228183803560_56.jar /home/REDACTED/work/ojp/ojp/ojp-server/target/surefire 2026-02-28T18-37-48_572-jvmRun1 surefire-20260228183803560_54tmp surefire_1-20260228183803560_55tmp (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

Configure Actions setup steps to set up my environment, which run before the firewall is enabled
Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

sonarqubecloud · 2026-02-28T18:40:43Z

Quality Gate passed

Issues
8 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

rrobetti · 2026-03-01T22:50:52Z

done in a different PR.

Initial plan

022a956

Copilot AI assigned Copilot and rrobetti Feb 24, 2026

Copilot started work on behalf of rrobetti February 24, 2026 10:19 View session

Add richer telemetry metrics: connection queue depth, wait time, SQL …

8781e86

…execution time, pool stats, slot metrics Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>

Copilot AI changed the title ~~[WIP] Analyze requirements for emitting richer telemetry metrics~~ Add richer Prometheus metrics: connection queue depth, wait time, SQL execution time, pool stats, slot activity Feb 24, 2026

Copilot AI requested a review from rrobetti February 24, 2026 10:40

Copilot finished work on behalf of rrobetti February 24, 2026 10:40

Copilot started work on behalf of rrobetti February 24, 2026 11:00 View session

Replace sql_hash label with human-readable sql snippet in ojp_sql_exe…

a77ddb1

…cution_time_ms metric Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>

Copilot finished work on behalf of rrobetti February 24, 2026 11:09

Copilot started work on behalf of rrobetti February 24, 2026 11:19 View session

Decouple SQL execution time metric from SlowQuerySegregationManager; …

52c3961

…move to StatementServiceImpl Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>

Copilot finished work on behalf of rrobetti February 24, 2026 11:27

Merge branch 'main' into copilot/analyze-telemetry-metrics

432208e

Copilot started work on behalf of rrobetti February 28, 2026 17:18 View session

rrobetti and others added 2 commits February 28, 2026 17:19

Merge branch 'main' into copilot/analyze-telemetry-metrics

e4e9cc6

Extend advanced telemetry metrics to XA connection pool path

a740c02

Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>

Copilot AI changed the title ~~Add richer Prometheus metrics: connection queue depth, wait time, SQL execution time, pool stats, slot activity~~ Add richer Prometheus metrics: connection queue depth, wait time, SQL execution time, pool stats, slot activity (regular + XA) Feb 28, 2026

Copilot finished work on behalf of rrobetti February 28, 2026 17:29

Copilot started work on behalf of rrobetti February 28, 2026 17:44 View session

Fix GrpcServerHealthTest: assign this.openTelemetry in 9-param create…

db79b1a

…GrpcTelemetry; wire ojpMetrics into StatementServiceImpl Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>

Copilot finished work on behalf of rrobetti February 28, 2026 17:58

Copilot started work on behalf of rrobetti February 28, 2026 18:09 View session

Fix DuplicateLabelsException: set xa.poolName=connHash and align Pool…

a09d958

…MetricsFactory key Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>

Copilot finished work on behalf of rrobetti February 28, 2026 18:15

Copilot started work on behalf of rrobetti February 28, 2026 18:19 View session

Fix DuplicateLabelsException: readable pool labels, proper gauge clea…

d7aac6c

…nup on pool recreation Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>

Copilot finished work on behalf of rrobetti February 28, 2026 18:31

Copilot started work on behalf of rrobetti February 28, 2026 18:33 View session

Use OJP datasource name (not JDBC URL) for pool metric labels; remove…

693afb9

… extractDbName Co-authored-by: rrobetti <7221783+rrobetti@users.noreply.github.com>

Copilot finished work on behalf of rrobetti February 28, 2026 18:39

rrobetti closed this Mar 1, 2026

Conversation

Copilot AI commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

New metrics (/metrics)

Key changes

Usage

Uh oh!

rrobetti commented Feb 24, 2026

Uh oh!

Copilot AI commented Feb 24, 2026

Uh oh!

rrobetti commented Feb 24, 2026

Uh oh!

Copilot AI commented Feb 24, 2026

Uh oh!

rrobetti commented Feb 25, 2026

Uh oh!

rrobetti commented Feb 28, 2026

Uh oh!

Copilot AI commented Feb 28, 2026

Uh oh!

rrobetti commented Feb 28, 2026

Uh oh!

Copilot AI commented Feb 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

I tried to connect to the following addresses, but was blocked by firewall rules:

Uh oh!

rrobetti commented Feb 28, 2026

Uh oh!

Copilot AI commented Feb 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

I tried to connect to the following addresses, but was blocked by firewall rules:

Uh oh!

rrobetti commented Feb 28, 2026

Uh oh!

Copilot AI commented Feb 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

I tried to connect to the following addresses, but was blocked by firewall rules:

Uh oh!

rrobetti commented Feb 28, 2026

Uh oh!

Copilot AI commented Feb 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

I tried to connect to the following addresses, but was blocked by firewall rules:

Uh oh!

sonarqubecloud Bot commented Feb 28, 2026

Quality Gate passed

Uh oh!

rrobetti commented Mar 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Copilot AI commented Feb 24, 2026 •

edited

Loading

New metrics (`/metrics`)

Copilot AI commented Feb 28, 2026 •

edited

Loading

Copilot AI commented Feb 28, 2026 •

edited

Loading

Copilot AI commented Feb 28, 2026 •

edited

Loading

Copilot AI commented Feb 28, 2026 •

edited

Loading