Obfuscation
DrWatson reads the diagnostic outputs you upload —
ifxcollect tarballs, AF (assertion-failure) files, bare
onstat -a dumps. Those captures
typically include identifiers that some teams prefer not to share in
the clear: hostnames, database and table names, partial SQL
fragments, session IDs, sometimes user identifiers embedded in lock
or transaction states.
This page documents what DrWatson sees by default, what you can scrub before upload, and the per-account toggles that change either. Pairs with Security & Privacy.
What DrWatson reads by default
DrWatson's collectors are conservative — they extract only the facts the rule engine needs. Per upload kind:
| Upload kind | What DrWatson extracts | Where customer identifiers can appear |
|---|---|---|
| ifxcollect tarball |
Server configuration (onconfig), dbspace
and chunk geometry, per-partition counters,
lock-table snapshots, message-log tail, archive
history. SQL fragments are not read by today's
default collectors.
|
Database and table names in chunk and lock facts. |
| AF file | The signal that caused the failure (SIGSEGV, SIGBUS, …), addresses, the running SQL at the failure point if present, the call-stack symbol-name list, the engine version. |
Database / table / column names in the running SQL
and inside any af_table_or_index facts
carried by the file.
|
| onstat -a dump | The same fields as ifxcollect's onstat coverage, plus network-thread state and per-session locks. |
Hostnames in the -g ntt section.
|
What you can scrub before upload
Either reaction is supported — obfuscate before you send, or let DrWatson see the original and rely on the per-tenant separation. The list below is a menu, not a checklist; pick the items that matter for your environment.
Hostnames and IP addresses
Replace the production hostname in onstat, AF, and
message-log captures with a stable token (e.g.
customer-host-1). Keep the substitution stable
across captures so cross-snapshot rules still see the same host.
Database and table names
The rule engine never indexes facts by table name — it counts,
ratios, and thresholds. So renaming
orders → tbl_001 across an
upload preserves every analysis result. Use a deterministic mapping
(e.g. SHA-1 truncation or a small mapping file you keep locally)
so the same table reads as the same token across uploads.
SQL literals
Most rule families don't surface SQL text in findings
— only structural counters
(non-sargable markers, isolation levels, plan-shape
counts). A few do: the contention rules
(PERF-021 / PERF-022) cite the
offending query when a thread is contending on a lock or
condition variable, and the query-plan rules
(PLAN-001 / PLAN-002) cite the
statement whose access plan triggered the finding. AF reports
carry the current-SQL block when the AF dispatcher captured one.
Everything else reads the SQL inside an AF or an onstat capture
for parsing-counters only and not echoed.
If you'd like to scrub SQL literals defensively, replacing
'foo@bar.com' with ? in the captured
strings is enough — the parsing counters don't care about the
literal value.
User identifiers
Lock and transaction snapshots (onstat -k,
-u, -x) include the OS user that launched
the session. Replace with a token (app_user_1) if your
threat model requires it; the rule engine treats the user field as
opaque.
Account-level controls
Two switches we can set for your account on request — drop a note to support@oninit.com and we'll have either flipped before your next upload:
| Control | What it does |
|---|---|
| SQL redaction at intake | When enabled, every capture is scrubbed of SQL fragments before DrWatson reads it. Your reports still cite the rule that fired and the recommendation to act on; the actual SQL never leaves your environment in plain text. Useful for shops where any literal in a query (an email address, an account number, a customer ID) is in scope for compliance. |
| Opt out of interactive Q&A | If your governance team prefers no third-party model involvement, we can switch off the Ask panel for your account. You keep the static reports and PDFs in full; the conversational layer simply isn't offered. No data crosses the boundary you've chosen. |
What never happens
| Guarantee | What it means |
|---|---|
| No cross-tenant caching | Findings are not cached for cross-tenant pattern analysis. Each tenant's reports stay scoped to that tenant. |
| Bounded retention | Captures are not retained beyond the customer- configured retention window (90 days by default; configurable per account). |