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.

Permissions

Instance detection

These grants are required to populate the oracle.db.version, 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:

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 three event types (db.server.query_sample, db.server.top_query, db.server.session.wait_sample) 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.session.wait_sample

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

Combined grant statement

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

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-08-24