Find the slow query.
Then the request that sent it.
Query latency and error rates for PostgreSQL, MySQL, Redis, MongoDB and more, tied to the traces and services that issued them. Capture database calls with OpenTelemetry instrumentation or straight from the kernel with eBPF.
Deep Dive
Core Capabilities & Architecture
Explore how Database Monitoring instruments, processes, and correlates high-cardinality telemetry at scale.
Every query as a span, inside the request that made it
OpenTelemetry database instrumentation records each call as a span with its statement, duration and outcome. Because it sits inside the distributed trace, a slow query is never an orphan: you see the endpoint, the service and the user request behind it.
- Query spans for PostgreSQL, MySQL, Redis, MongoDB, Cassandra and Elasticsearch clients
- Statement, duration and error captured on every call
- P50/P95/P99 latency per database, per operation
- Jump from a slow query to the full trace and its logs
Database traffic captured from the kernel
Where you cannot add instrumentation, axonIQzerocode reconstructs PostgreSQL, MySQL and Redis transactions from socket traffic with eBPF. Legacy services and third-party binaries report the same signals as instrumented code.
- PostgreSQL, MySQL and Redis protocol reconstruction
- No client library changes or language agents
- Connection resets and socket errors surfaced alongside latency
- Works for any binary on Linux kernels 5.4+
Server metrics beside the queries
Bring database server metrics in through the Prometheus exporters or OpenTelemetry Collector receivers you already run. Connections, throughput and resource use sit on the same dashboards as query latency, with alerts on either.
- Prometheus remote_write and OTLP metrics ingestion
- PromQL-compatible queries and alert rules
- Dashboards that mix server metrics with query spans
- SLOs on database latency with error budget tracking
Built for every team that cares about reliability
One platform, tailored to how your team actually works.
Fix the query, not the symptom
Start from a slow endpoint and land on the exact statement that made it slow.
Catch saturation before it pages
Alert on connection counts and query latency together, not on whichever one fails first.
Cover what you cannot instrument
Get database visibility for legacy and third-party services through eBPF, without code changes.
Database calls are telemetry, not a separate product
Query spans arrive over OTLP from your instrumented services, or from axonIQzerocode for everything else. Server metrics arrive through Prometheus or the OpenTelemetry Collector. All of it lands in the same ClickHouse store, so the query, the trace and the server metric share one timeline.
Also in the platform
Start database monitoring in 5 minutes
Your existing OpenTelemetry instrumentation works unchanged, so there is nothing to rewrite and nothing to migrate.