Operations

DBVoyeur operates by passively capturing the SQL traffic between application clients and the database server. There is no agent inside the database, no client-side instrumentation, and no production configuration to change.

Deployment topology

Capture is local to the database host. The capture agent reads the traffic on the host it runs on; it is not deployed against a SPAN port, a mirror port or a network tap, and those topologies are not supported. This is a deliberate constraint rather than a gap, and the two sections below are the reason: the things customers most often want from SQL monitoring — statement text from encrypted connections, and visibility of shared-memory clients — are only obtainable on the database host. A mirrored deployment would silently deliver neither.

Encrypted SQL can only be recovered on the database host. Where a connection uses a modern cipher suite, the session keys are never transmitted, so the SQL cannot be recovered from network traffic by any product, at any capture point on the network. Recovering statement text from encrypted connections requires capturing on the database host itself, where the traffic is in clear by the time it reaches the database process — see TLS.

Shared-memory connections are only visible on the database host. A client connecting over shared memory never sends a packet: the request is handed to the server through a memory segment the two processes share, so there is nothing on any network interface to observe, on any host. Local clients, batch jobs and stored-procedure work frequently connect this way, and to a network-only capture point that traffic is not partially captured but absent entirely.

What gets captured

The repository

Per-transaction data is volumetric. A modestly busy production database easily generates tens of millions of measured transactions per day. DBVoyeur ships with a repository architecture explicitly designed for that volume: rolling partitions, automatic aggregation tiers, and a searchable summary layer in the dashboard that lets the operator walk from a user complaint (“last Tuesday at 10:42 the checkout page was slow”) to the exact statements involved in seconds.

The repository is itself queryable in SQL, so existing reporting, alerting, and BI tools work against it directly. Common patterns — top-N slow statements per hour, regression of a statement’s P99 over a release, top callers of a given table — are all ordinary SQL queries.

Restarting capture

Capture is passive: DBVoyeur identifies a database connection by observing it being established, and builds its understanding of that session from the connection onwards. This has one operational consequence worth planning for, because it is not obvious from the outside.

When the capture agent is restarted, connections that were already open are not picked up again. DBVoyeur did not see them start, so it has no session state for them and does not attempt to interpret them mid-stream. Those sessions remain invisible until the application closes the connection and opens a new one.

The reason this is worth stating explicitly is that nothing looks wrong. The agent is running, the database still lists the sessions, and reporting continues — because any application that connects afresh is captured normally. What is missing is precisely the long-lived work, and it goes missing quietly.

Who this affects

Planning a restart

• Restart during a window when pools recycle — typically an application restart or deployment — so capture and the pool come back together.
• Expect a partial view until pools turn over if you restart during steady-state running. Reporting for that period will under-represent pooled activity rather than show an obvious outage.
• Prefer restarting the collector to restarting the agent where the change allows it. Restarting the repository or dashboard does not disturb established capture state; restarting the capture agent does.
• Verify after restarting by confirming that traffic from a known long-lived application reappears once it has reconnected.

This is inherent to passive, non-intrusive capture rather than a limitation of a particular release. It is the same property that lets DBVoyeur observe a database without touching it: nothing is in line with the traffic, so nothing can be asked to replay a conversation that is already under way.

Configuration model

A single DBVoyeur instance can monitor multiple database types and multiple database instances simultaneously. Configuration is declarative: each monitored target is described by host, port, and database flavour. DBVoyeur tracks which targets are being captured, which are configured but not yet live, and the wire-format version in use on each.

Operational behaviour