Oracle Database Monitoring at Fleet Scale
DB Realm Inc. (Internal)
Challenge
Monitoring an Oracle estate usually forces a bad trade. Agent-based tools need software installed on database servers, which security teams resist and change control slows down. Console-based tools cost more than the databases they watch. And most of them quietly read Diagnostics Pack views, exposing the organization to a licensing claim that only surfaces during an audit — long after the usage is logged.
Solution
Built a monitoring agent that runs without an Oracle client, without an installed agent on the database server, and without touching a licensed view unless explicitly permitted. It emits both a human-readable HTML dashboard and a structured JSON payload, which it uploads to a central support platform over a token-authenticated ORDS endpoint. Agents also push their own configuration for versioned backup and drift detection, so a fleet reports not just its health but its own consistency.
Results
- ✓ Runs in Python thin mode — no Oracle client required
- ✓ Explicit licensing gate on Diagnostics Pack views
- ✓ Feeds a central platform across a live fleet
- ✓ Remote and agentless collection for Kubernetes and Autonomous DBs
Most Oracle monitoring products make an assumption that does not survive contact with a regulated environment: that you are allowed to install their agent, and that you have licensed the packs their queries read.
This agent is built for the case where neither is true.
Licensing as a design constraint
Oracle’s Diagnostics Pack is separately licensed, and several of the most convenient monitoring views — v$sysmetric chief among them — fall under it. Querying them on an unlicensed database creates real exposure, and the usage is recorded whether or not anyone intended it.
The agent treats this as a hard gate rather than a footnote. A configuration flag, allow_diagnostics_pack, defaults to false. While it is false, the pack-gated panel is skipped entirely and only licence-free metrics are collected. Turning it on is a deliberate, per-host decision made by someone who knows what that database is licensed for.
The same principle governs the audit module: it reads only unified_audit_trail and the enabled-policies view — no AWR, no active session history, no pack dependency.
What it collects
Tablespaces grouped per container, ASM disk groups, PDB open modes, APEX and ORDS versions per PDB, RMAN backup history, scheduler jobs from both the database and the OS, Data Guard lag, and host disk, CPU and memory.
Two deeper sections are opt-in and off by default:
- Performance — session and process headroom, shared pool free percentage, blocked and long-running sessions, redo switch rate, archive log rate, instance uptime
- Health and integrity — block corruption, datafiles needing recovery, archiver health, unusable indexes, invalid objects, invalid registry components, expired and locked accounts, PDB violations, stale statistics, sequences approaching their maximum
Plus drill-downs for expensive SQL, blocking chains and Health Monitor findings, where the HTML shows the top few and the JSON carries everything.
Deployment reality
It runs in Python thin mode, so no Oracle client installation is needed anywhere. It works on Windows and Linux. And it supports remote collection — pointing at Kubernetes-hosted databases and Autonomous Databases where installing anything on the host is not an option at all.
Feeding the platform
The agent is one half of a pair. Its JSON payload uploads to a token-authenticated ORDS endpoint on a central support platform, which dispatches on report type — health reports to one ingestion package, audit reports to another — through a single endpoint.
Two details make this work at fleet scale rather than host by host:
Configuration backup and drift detection. Each agent pushes its own effective configuration, with secrets redacted, for versioned storage. The platform can then show what changed and when.
A capability matrix. Every report carries an enabled_features map derived from the agent’s effective configuration, not its file. The platform renders this as a per-host feature grid and flags drift — a host running fewer checks than its peers is visible immediately. Database-only features are forced off for hosts with no database configured, so an OS-only host never advertises capabilities it cannot have.
That last point closes a real failure mode: a configuration file written by an older agent version silently falls back to in-code defaults for every key it lacks, which can make a host under-report what it checks. The updater now reconciles configurations automatically on every upgrade — adding missing sections with safe defaults, healing empty ones, and never inventing a report section whose absence is itself meaningful.
Unified audit
A daily unified-audit summary classifies events by severity, emails a dashboard, and uploads to the platform’s audit module, where threshold breaches raise alerts. The consumer side derives a display name for events where the database username is null, falling back to the OS user and host — so an audit dashboard never shows a blank actor on a failed login.