Operations
iWatch 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 topologies
| Topology | Where iWatch runs | DB host overhead | When to choose it |
|---|---|---|---|
| Co-resident | On the database host itself | ~1–2% of one core | Default. Simplest to deploy, works in every environment, including cloud VMs without SPAN ports. |
| Separate host | A dedicated Linux host on the same subnet, receiving a mirrored copy of the database traffic | Effectively zero | Tight CPU budgets, regulated environments where nothing additional is permitted on the DB host. |
| Appliance | A purpose-built physical or virtual appliance in front of the database tier | Effectively zero | Large estates with multiple databases monitored from one capture point. |
What gets captured
| Field | Meaning |
|---|---|
| SQL text | The full text of every prepared and executed statement, normalised for grouping by template if desired. |
| Bind values | Parameter values bound to each execution (configurable per database and per table for sensitive data). |
| Response time | Wire-measured time from the request leaving the client to the response leaving the server. |
| Rows returned / affected | Result-set size for queries, affected-row count for DML. |
| Client identity | Source IP, source port, database user, application name where the driver supplies it. |
| Session identity | Database session id, server PID where applicable, transaction boundaries. |
| Errors | Server error code, error message, and the statement that triggered it. |
| Wait events | Where the database surfaces them at the wire, the wait class on each round trip. |
The repository
Per-transaction data is volumetric. A modestly busy production database easily generates tens of millions of measured transactions per day. iWatch ships with a repository architecture explicitly designed for that volume: rolling partitions, automatic aggregation tiers, and a SQL-searchable summary layer 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.
Configuration model
A single iWatch 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. iWatch tracks which targets are being captured, which are configured but not yet live, and the wire-format version in use on each.
Operational behaviour
| Property | Behaviour |
|---|---|
| Read-only | Never modifies any traffic in either direction. Pure observer. |
| Fail-safe | If iWatch stops, the application keeps working. There is no in-line path for database traffic when the capture is passive. |
| Bounded resource use | Capture, decode and repository writers run in bounded queues with backpressure. Under sustained overload, iWatch sheds the oldest pending events first and continues; it never blocks the wire. |
| Restart-safe | The repository tolerates iWatch restarts mid-stream. A restart is visible as a gap in the timeline, not a corruption. |
| Bind-value redaction | Per-database and per-table rules can redact bind values entirely, hash them, or pass them through unchanged. |