Solution Overview — For Architects
You are the person who has to decide whether a new component belongs in the estate, on what topology, with what data path, and at what licensing exposure. The questions below are the ones DBVoyeur is designed to make easy.
Deployment model
| Question | DBVoyeur answer |
|---|---|
| Where does the component sit in the data path? | It does not. DBVoyeur is a passive observer of the database listener traffic. It is not in the request path; the application cannot wait on it. |
| What is the failure mode? | If DBVoyeur stops, the application keeps working. The only consequence is that the timeline shows a gap. |
| What is the security boundary? | DBVoyeur reads database traffic on a configured interface and writes to a configured repository. It opens no inbound port to the application tier and no outbound connection to the database as a client. |
| How do we satisfy data-residency obligations? | The repository is whatever database you point it at, in whatever region you choose. Captured data never leaves the repository unless you query it out. |
| How do we redact sensitive bind values? | Per-database, per-schema, per-table, per-column rules. Bind values can be passed through, hashed, or blanked. Rules apply at capture time, before write. |
| How does it scale? | One capture process per monitored target, sharable across targets within one engine family. The repository is partitioned and aggregated; the bottleneck under load is repository write throughput, which is sized to the estate. |
Coverage matrix
A single DBVoyeur deployment can simultaneously monitor:
- IBM Informix, HCL OneDB
- IBM Db2 LUW and Db2 z/OS DDF
- SAP ASE and SAP IQ (Sybase)
- Microsoft SQL Server
- PostgreSQL
- MongoDB
— from one console, against one repository, with one operational grammar. The licensing model supports multi-instance and multi-engine deployments explicitly.
Integration surfaces
| System | How DBVoyeur interfaces with it |
|---|---|
| SIEM / log platform | The repository is SQL-searchable; standard ETL pulls aggregates into Splunk, Elastic, or a data lake at whatever cadence suits. |
| APM | DBVoyeur correlates with application-side traces via session identity and timestamp; common APMs ingest its aggregates through their generic database connector. |
| Alerting | Any query against the repository is an alert candidate. Per-statement P99 regressions, per-app error-rate spikes, and per-pool commit-time drift are the usual starting points. |
| BI / reporting | The repository is a SQL database. Tableau, Power BI, Cognos and equivalent tools connect natively. |
| Capacity planning | Aggregate tiers retain longer history. The same data that drives incident triage drives quarterly capacity reviews. |
What changes architecturally
The standing question “is it the database or the application?” is settled by evidence, not by ownership. The database tier ceases to be a black box for the application architects, and the application tier ceases to be a black box for the DBA team. Both sides read the same timeline.
Risk register impact
| Risk | Before | With DBVoyeur |
|---|---|---|
| Production-database side effects | Server-side traces add 10–15% CPU; agents inside the database add a coupling to its release schedule. | Passive capture. No coupling to the database release schedule; ~1–2% of one core, or zero on the DB host. |
| Long MTTR on database-related incidents | Driven by lack of evidence at the SQL layer. | Evidence is already in the repository when the incident starts. |
| Multi-DB skill spread | Operators learn the monitoring vocabulary of each engine separately. | One operational grammar across all engines in the estate. |
Next step
A scoping call to map DBVoyeur onto the topology in scope; from there, a trial against a non-production target validates the deployment model and the expected repository volume. Email support.info@oninit.com.