Oracledb Receiver
contrib
Maintainers: @dmitryax, @crobert-1, @atoulme, @ebrdarSplunk, @XSAM, @akshays-19, @sv-splunk, @splunk-shanu
Source: opentelemetry-collector-contrib
Supported Telemetry
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:datasource: Oracle database connection string. Special characters must be encoded. Refer to Oracle Go Driver go_ora documentation for full connection string options.
Secondary Configuration Option
Required options:endpoint: Endpoint used to connect to the Oracle DB server. Must be in the format ofhost:portpassword: 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.
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:
Permissions
Instance detection
These grants are required to populate theoracle.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 againstDUALrequire no additional grant and are available to all database users.
Hosting type detection (Oracle >=19c only)
These grants are required to populate theoracle.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 theoracle.db.pdb attribute. The monitoring user needs SELECT on
these views (container-wide):
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, theLAST_*,OUTPUT_ROWS, andSTARTScolumns are populated only when Oracle is configured to collect execution plan statistics (for example,STATISTICS_LEVEL=ALLor theGATHER_PLAN_STATISTICShint). 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:
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:
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 theDBA_*view for the event(s) that need it, so events keep flowing with the container-attribution limitation described above rather than failing withORA-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 usingrdsadmin.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 thedb.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-separatedkey=valuepairs) in thedb.query.comment_tagsattribute.
- When
allowed_comment_keysis 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.
/* 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