New component: Oracle DB receiver

[crobert-1]

The purpose and use-cases of the new component

Oracle Database is a multi-model database management system produced and marketed by Oracle Corporation. It is a database commonly used for running online transaction processing, data warehousing and mixed database workloads. Source.

The Oracle DB receiver would be used to connect to Oracle DB, then query tables for performance metrics (or convert any query results into metrics).

There is currently a way to receive metrics from Oracle DB using the prometheus receiver, as well as using the sqlquery receiver with the oracle driver. The purpose of creating another receiver with functionality that is already possible is simply user-experience. The eventual goal is to make this use a library pulled out from the sqlquery receiver's functionality, but that may not be how this works internally initially. Once that new library is created we can reference it without changing anything externally.

Example configuration for the component

receivers:
  oracledb:
    username: otel
    password: password
    endpoint: localhost:51521
    service_name: XE

This query format is copied from the sqlqueryreceiver.

Telemetry data types supported

Metrics

Is this a vendor-specific component? If so, are you proposing to contribute this as a representative of the vendor?

Yes, it's vendor specific, but I'm not a representative of Oracle DB.

Sponsor (Optional)

@dmitryax

[dmitryax]

This query format is copied from the sqlqueryreceiver.

Why do we need to provide support for random queries in this receiver? I believe sqlquery receiver should be used for that purpose. This one should be used to collect a predefined set of metrics, similar to existing mysql and postgres receiver, right?

[crobert-1]

This query format is copied from the sqlqueryreceiver.

Why do we need to provide support for random queries in this receiver? I believe sqlquery receiver should be used for that purpose. This one should be used to collect a predefined set of metrics, similar to existing mysql and postgres receiver, right?

I left it general simply because it's possible with this design, not necessarily the best way to handle it.

We do need to define what the predefined metrics and queries should be, I'm not sure if this issue or during PRs would be the better place to have that discussion.

[dmitryax]

User config interface is something that we need to discuss upfront I believe. We don't even have to use sqlquery receiver as a library in the initial version, but we need to stick to the config interface that we choose. Exposing the same functionality in two receivers might be confusing to users, so I'd suggest removing that part from the config. Please look at the existing mysql and postgres receivers. I believe providing metrics config section from mdatagen is more important.

[crobert-1]

Please look at the existing mysql and postgres receivers. I believe providing metrics config section from mdatagen is more important.

I'm not sure exactly what you mean by this. Is it one of these? Something else?

1. Are you saying I should define all of the metrics in this proposal that the receiver will be emitting? (Essentially defining here the contents of the metadata.yaml file consumed by mdatagen?)
2. Are you saying the config should include the option to enable/disable metrics (like the postgres and mysql receivers have)?

[dmitryax]

@crobert-1 if we do 1, we get 2 OOTB. We need 2 anyway, so I believe the easiest way is to start with 1

[dmitryax]

If you define metadata.yaml and run make generate, you get all the helpers to record datapoints and configuration interface to enable/disable particular metric which is handled by the generated code

[TylerHelmuth]

@dmitryax @crobert-1 @atoulme is this receiver implemented? Is this issue ready to be closed?

[dmitryax]

It's not ready yet but the work is started so we can close the issue

[atoulme]

Good to go here. I will open a separate issue with the scraper code.