Skip to main content

Oracledb Receiver

Status Available in: contrib Maintainers: @dmitryax, @crobert-1, @atoulme, @ebrdarSplunk, @XSAM, @akshays-19, @sv-splunk, @splunk-shanu Source: opentelemetry-collector-contrib

Supported Telemetry

Logs Metrics

Overview

Getting Started

To use the Oracle DB receiver you must define how to connect to your DB. This can be done in two ways, defined in the Primary and Secondary configuration option sections. Defining one of the two configurations is required. If both are defined, the primary option will be used.

Primary Configuration Option

Required options: Example:

Secondary Configuration Option

Required options:
  • endpoint: Endpoint used to connect to the Oracle DB server. Must be in the format of host:port
  • password: Password for the Oracle DB connection. Special characters are allowed.
  • service: Oracle DB service that the receiver should connect to.
  • username: Username for the Oracle DB connection.
Example:

Optional Configuration Options

  • collection_interval (default = 10s): The interval at which metrics should be emitted by this receiver.
  • initial_delay (default = 1s): The initial time period this receiver waits before starting.
  • timeout (default = 0): Timeout for each Oracle DB request. Disabled by default.

Resource attributes

server.address and server.port identify the monitored Oracle instance and are emitted by default. When the receiver connects over loopback (for example datasource: oracle://otel:password@localhost:51521/XE or endpoint: 127.0.0.1:51521), server.address reports the host name of the machine running the collector, because the monitored instance is co-located with it and localhost would otherwise be shared by every monitored host. server.port defaults to 1521 when the connection string omits it. service.instance.id uses the same resolution and is reported as server.address:server.port/service. host.name is unaffected and keeps reporting the configured target. A datasource that is not in oracle://user:password@host:port/service form — a TNS descriptor, or an Easy Connect string without the oracle:// prefix — carries no host the receiver can read. In that case server.address is omitted rather than guessed, server.port falls back to 1521, and service.instance.id reports unknown:1521. Note that the driver does not currently connect with those forms either, so prefer the full oracle:// datasource or the endpoint option, both of which always populate the server attributes. To stop emitting the server attributes, disable them individually:
See documentation.md for the full list of resource attributes.

Permissions

Instance detection

These grants are required to populate the oracle.db.version, oracle.db.edition, oracle.db.role, oracle.db.open_mode, and oracle.db.pdb resource attributes. Detection is best-effort; failures are logged at warn level and the receiver continues.
Note: sys_context('USERENV', ...) queries against DUAL require no additional grant and are available to all database users.

Hosting type detection (Oracle >=19c only)

These grants are required to populate the oracle.db.hosting_type resource attribute. Only applies to Oracle 19c and later. Detection is best-effort; failures are logged at warn level and the receiver continues.

Metrics collection

Depending on which metrics you collect, you will need to assign these permissions to the database user:

ASM metrics

Grants required for ASM metrics.

Per-PDB metrics (CDB multitenant deployments)

When connected to a CDB root (Oracle 12c+), the receiver can collect per-PDB metrics by opting in to the oracle.db.pdb attribute. The monitoring user needs SELECT on these views (container-wide):
Users who already hold SELECT_CATALOG_ROLE (commonly granted to monitoring accounts) inherit SELECT on these views and don’t need the explicit grants above. If the required access isn’t present, the receiver detects this at startup and falls back to the single-container query set, emitting instance-wide metrics just as it did before per-PDB support was added. Existing CDB deployments upgrading without adding new grants continue to work unchanged.

Events collection

The following grants are required for event collection. All five event types (db.server.query_sample, db.server.top_query, db.server.session.wait_sample, db.server.top_procedure, db.server.query_plan) are disabled by default and must be explicitly enabled in configuration.

All events (shared requirements)

These grants are used by all event types for session context and PDB namespace resolution:

db.server.query_sample

Captures currently executing queries and blocking/locking session information:

db.server.top_query

Captures the most expensive queries by elapsed time with execution plan details:
[!NOTE] In the SQL query plan details, the LAST_*, OUTPUT_ROWS, and STARTS columns are populated only when Oracle is configured to collect execution plan statistics (for example, STATISTICS_LEVEL=ALL or the GATHER_PLAN_STATISTICS hint). Otherwise, these fields will be NULL or empty. Configuring this Oracle instrumentation may introduce additional runtime overhead. Enable it only if you need these runtime execution statistics for query performance analysis.

db.server.query_plan

By default, db.server.top_query carries the query’s execution plan in its oracledb.query_plan attribute. A plan is a JSON payload holding one entry per plan step, so it can dominate the record it travels on. Enabling db.server.query_plan isolates the plan on a record of its own, where it can be filtered, routed or dropped independently of the query statistics, and where an oversized plan does not take those statistics with it when a batcher splits by size. db.server.top_query is then emitted without its oracledb.query_plan attribute, and the plan itself is reported on db.server.query_plan, joined back to its cursor via oracledb.sql_id + oracledb.child_number + oracledb.child_address, with oracledb.plan_hash_value identifying the plan and db.namespace the database it came from. A cursor with no rows in V$SQL_PLAN_STATISTICS_ALL produces no db.server.query_plan record. Leaving db.server.query_plan disabled preserves the previous behavior exactly. db.server.query_plan is sourced from the same collection as db.server.top_query and only splits the plan out of it, so it needs no grants of its own, and enabling it without db.server.top_query is a configuration error.

db.server.session.wait_sample

Captures per-session wait event statistics from V$SESSION_EVENT:

db.server.top_procedure

Captures aggregated performance metrics for stored procedures, derived by grouping V$SQL by PROGRAM_ID and joining to DBA_PROCEDURES. Correlates with db.server.top_query and db.server.query_sample via the oracledb.procedure_id attribute:
Cumulative counters are converted to per-scrape deltas. Rows are fetched up to max_procedure_sample_count, ranked in the collector by elapsed-time delta, and truncated to top_procedure_count. The fetch limit is deliberately larger than the reported set: ranking on deltas over a wider pool is what lets a procedure that is hot only in the current interval — newly deployed, a month-end batch, something that just started misbehaving — reach the report even though its lifetime totals are modest. A negative delta on any of the summed resource counters means a cursor aged out of the shared pool, so the row is discarded rather than emitted as a bogus value.
[!NOTE] Oracle exposes no per-procedure cumulative execution counter, so oracledb.procedure_execution_count is derived as the minimum statement execution count across the procedure’s cached statements. This is best effort: a newly loaded child cursor starts at 1 and pulls the minimum down, and a statement in a branch that did not run holds it flat. The receiver therefore treats this counter separately from the resource counters — it is clamped to 0 instead of discarding the row. Resource counters (CPU, elapsed time, reads, writes, rows) are summed across the procedure’s statements and are not subject to this caveat.
See “CDB-root connections and container-scoped dictionary views” below for how this event behaves on a CDB-root connection.

CDB-root connections and container-scoped dictionary views

DBA_* dictionary views only expose the container you are connected to, while the V$ views report rows for every container. Object ids are only unique within a container, so from a CDB root a dictionary join on object id alone is not just incomplete — it can attribute a PDB row to an unrelated root object that happens to share the id. When connected to a CDB root, the receiver therefore reads the CDB_* equivalents and matches on CON_ID as well as the object id: top_query and top_procedure only need CDB_PROCEDURES; query_sample additionally needs CDB_OBJECTS. The two grants are probed independently at startup, so a CDB root with only CDB_PROCEDURES still gets container-qualified top_query/top_procedure results even while query_sample degrades to the DBA_* view:
Users holding SELECT_CATALOG_ROLE inherit both and need no explicit grant. Non-CDB and direct-PDB connections continue to use the DBA_* views and need nothing extra.
[!NOTE] Each grant is probed once at startup. If a grant is missing, the receiver logs a warning and falls back to the DBA_* view for the event(s) that need it, so events keep flowing with the container-attribution limitation described above rather than failing with ORA-00942. This mirrors how per-PDB metrics already degrade when their grants are absent — no upgrade requires new grants to keep working.

Combined grant statement

For convenience, the complete set of grants required to enable all events:

AWS RDS Oracle grants

Run the following as the master/admin user using rdsadmin.rdsadmin_util.grant_sys_object to grant permissions on the required views. The following grants cover all metrics and events collected by this receiver:

Direct-PDB connections

When the receiver connects directly to a PDB (including all AWS RDS Oracle deployments), oracledb.transactions.limit and oracledb.dml_locks.limit are derived from v$parameter instead of v$resource_limit, which is unavailable in PDB context. When Oracle auto-tunes these parameters, v$parameter reports the computed value (for example, 354 or 1416) rather than -1 (unlimited) as a root or standalone connection would. A direct-PDB deployment and a CDB-root deployment of the same instance can therefore report different values for these metrics.

Enabling metrics.

See documentation. You can enable or disable selective metrics. Example:

Enabling events.

The following is a generic configuration that can be used for the default logs and metrics scraped by the Oracle DB receiver.

SQL Comment Extraction

When the db.server.query_sample and/or db.server.top_query events are enabled, the receiver can extract key-value pairs from leading SQL block comments (/* key=value */) and emit them as the db.query.comment_tags attribute on the corresponding logs. This behavior is controlled by the allowed_comment_keys option, which can be set independently under top_query_collection and query_sample_collection:
  • allowed_comment_keys (default = []): A list of comment keys to extract. For each enabled collection, only keys present in this allowlist are extracted from the leading SQL comment and included (as comma-separated key=value pairs) in the db.query.comment_tags attribute.
Extraction is disabled unless explicitly configured:
  • When allowed_comment_keys is empty or unset, no comments are extracted.
  • Only keys included in the allowlist are emitted; all other comment keys are ignored.
  • Only leading block comments are parsed; comments elsewhere in the query are ignored.
Example:
Given a query such as /* application=exampleApp,team=payments */ SELECT * FROM users, the emitted log record will include db.query.comment_tags set to application=exampleApp,team=payments. When multiple keys are extracted, they are emitted as a comma-separated list of key=value pairs. See documentation for details on the db.query.comment_tags attribute.

Metrics

Attributes

Resource Attributes

Configuration

Example Configuration


Last generated: 2026-10-05