[exporter/prometheusremotewriteexporter] Deprecate and Remove `export_created_metric` feature.

[ArthurSens]

Component(s)

exporter/prometheusremotewrite

Describe the issue you're reporting

Although the intention with #17417 was good to be compliant with OpenMetrics, it's important to mention that OpenMetrics is an data exposition format, while Prometheus Remote-Write is a data transport protocol.

The original goal of StartTimeUnixNano and OM's _created metrics is to identify resets of monotonically increasing metrics.

Knowing that our exporter exposes StartTimeUnixNano as a separate metric, and that PRWv1 potentially splits metrics into multiple requests, there's no guarantee that _created and its related metric will be sent in the same request, which makes the usage of this feature super super difficult and inefficient. The current implementation in Prometheus when receiving this metric will just create another timeseries and will not use it to identify resets, making this feature in the collector pointless.

My suggestion here is that we remove this feature altogether. Let's keep in mind that this is a prwexporter and not a openmetrics exporter.

[github-actions]

Pinging code owners:

• exporter/prometheusremotewrite: @Aneurysm9 @rapphil @dashpole

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[dashpole]

Since PRW v2.0 will have the created timestamp in the proto, this will become moot after we switch to that. Should we just leave it around until then? IIRC, it is disabled by default. I'm not sure if people are using it or not. We can add a warning or something to the documentation if you want to make sure people know it doesn't work with Prometheus' CT support

[ArthurSens]

I'd rather remove it, if possible. For PRWv2 I think we'll always do this conversion, it shouldn't be opt-in/out 🤔. While in PRWv1 it just doesn't work at all, so there's no reason to enable it

[dashpole]

cc @kovrus do you have any thoughts here?

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• exporter/prometheusremotewrite: @Aneurysm9 @rapphil @dashpole

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[ArthurSens]

Sorry, this is still on my list. Just struggling to allocate time for it 😬

[pokgak]

@ArthurSens here's the PR for deprecation: #36214

If I understand the guideline correctly, removing the config option itself have to be done separately in the next release right?

[ArthurSens]

@ArthurSens here's the PR for deprecation: #36214

If I understand the guideline correctly, removing the config option itself have to be done separately in the next release right?

Yes, for complete removal it will take a few releases... but we can put the feature behind a feature gate and slowly decrease the stability stage until complete removal