Database proxy metrics
This group appears when the daemon can scrape ProxySQL on the host (the managed database ingress sidecar). The title is ProxySQL. A host that runs Postgres or MySQL without that proxy has no group — engine process metrics are not this surface; the managed-engine census is on Storage usage.
Counters are per interval (how many happened), matching ingress. Connection gauges are point-in-time. The layout is adapter-agnostic — a future PgBouncer proxy would report the same shape — so nothing below is ProxySQL-specific except the source it is read from. Unlike ingress, this family carries means but no percentiles: ProxySQL exposes cumulative time counters and no histogram to derive them from.
Queries
| Series | Wire name | What it is |
|---|---|---|
| Queries | databaseProxy.queries | Statements the proxy handled in the interval |
| Slow queries | databaseProxy.slowQueries | Statements the proxy classified as slow |
A rising slow-query line with a flat query line is the database (or the network to it) getting slower, not busier. Pair with latency to see where the time goes.
Query vs backend latency
| Series | Wire name | What it is |
|---|---|---|
| Query | databaseProxy.queryLatencyMsAvg | Mean time from a client's statement arriving to its result leaving, milliseconds |
| Backend | databaseProxy.backendLatencyMsAvg | Mean time the proxy waited on the database for that statement |
The gap between the two lines is proxy overhead — queueing for a backend connection, routing, result buffering. Both rising together is the database. Query rising while backend stays flat is the proxy: usually a connection pool that is full, so statements wait for a backend slot. Check backend connections and rejected connections.
Active transactions
databaseProxy.activeTransactions — transactions open across the proxy right now.
A steady floor above zero on a quiet system is something that opened a transaction and never committed — an idle-in-transaction session holding locks. A rising floor is that pattern accumulating: connections pile up behind the locks, latency follows, and eventually the pool fills.
Connections
| Series | Wire name | What it is |
|---|---|---|
| Client | databaseProxy.clientConnections | Connections from apps into the proxy right now |
| Backend | databaseProxy.backendConnections | Connections from the proxy into the database(s) right now |
Many more client connections than backend connections is pooling doing its job. Both climbing together toward a known ceiling is the pool filling. Client high with backend near zero and errors up is "the proxy is up, the database is not accepting."
Client connection churn
| Series | Wire name | What it is |
|---|---|---|
| Created | databaseProxy.clientConnectionsCreated | New client connections opened in the interval |
| Aborted | databaseProxy.clientConnectionsAborted | Client connections that ended abnormally in the interval |
Compare churn with the concurrency gauge. High created with flat concurrency is an application opening a connection per request instead of pooling — every one pays a handshake. Aborted rising is clients timing out or being dropped; if rejected rises with it, they were turned away.
Rejected at max connections
databaseProxy.connectionsRejectedMaxConns — client connections the proxy refused because it was at its connection limit.
This is the most actionable number here. Anything above zero is an application that got an error instead of a connection. Raise the proxy's limit, fix the client that is not releasing connections, or add capacity — but do not leave it non-zero. A connection error spike that coincides with this is refusals, not network trouble.
Backend connection churn
| Series | Wire name | What it is |
|---|---|---|
| Created | databaseProxy.backendConnectionsCreated | New connections the proxy opened to a database in the interval |
| Aborted | databaseProxy.backendConnectionsAborted | Backend connections that ended abnormally in the interval |
Backend connections should be long-lived and reused. Created climbing steadily is the pool being rebuilt — a backend restarting, a failover, or a connection lifetime set too short. Aborted with backends up dropping is a database going away underneath the proxy.
Connection errors
databaseProxy.connectionErrors — failed client or backend connects in the interval.
Spikes at deploy or failover can be expected. A sustained rate is refused connections, a full connection table, TLS mismatches, or backends that are down. See conntrack if this host NATs heavily, and rejected for the proxy-limit case specifically.
Backends up vs total
| Series | Wire name | What it is |
|---|---|---|
| Up | databaseProxy.backendsUp | Database backends the proxy currently considers available |
| Total | databaseProxy.backendsTotal | Database backends configured |
Read it as "3 of 4". Up dropping below total is the discrete "a replica or primary disappeared from the proxy's point of view." That may be a planned failover or a real outage — check managed failover history and the server's events list in the same range.
Bytes from and to backends
| Series | Wire name | What it is |
|---|---|---|
| From backends | databaseProxy.bytesFromBackends | Result-set bytes the databases sent back through the proxy in the interval |
| To backends | databaseProxy.bytesToBackends | Query bytes the proxy sent to the databases in the interval |
From is result volume, to is query volume. From far above to is the normal read-heavy shape. To growing on its own is bulk inserts or very large statements. From growing with a flat query count is queries returning more rows each — a missing LIMIT, a table that grew, or a report that scans.
Related
- Managed database ingress — ports, TLS, replica semantics
- Storage usage — managed engine instances and connections at the engine
- Ingress — HTTP proxy charts (Caddy)
Last updated on