[telemetry] mark useOtelForInternalMetrics stable

[codeboten]

This marks the flag as stable. Leaving this as a draft until v0.92.0 is released.

Closes #8962
Fixes #816

[codecov]

Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (3a16592) 90.31% compared to head (6ad48b3) 90.33%.

Files	Patch %	Lines
service/service.go	50.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9102      +/-   ##
==========================================
+ Coverage   90.31%   90.33%   +0.02%     
==========================================
  Files         341      340       -1     
  Lines       18308    17923     -385     
==========================================
- Hits        16535    16191     -344     
+ Misses       1437     1409      -28     
+ Partials      336      323      -13     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[TylerHelmuth]

It's beautiful. What impact does this have on components in Contrib, like tailsamplingprocessor or filterprocessor, that use OC?

[atoulme]

Same question as Tyler regarding the Splunk HEC exporter: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/exporter/splunkhecexporter/heartbeat.go#L58

[codeboten]

Should have no impact, the opencensus bridge is still in place to receive OC metrics

[codeboten]

@TylerHelmuth @atoulme the global OC registry is still usable by components:

opentelemetry-collector/service/telemetry.go

Line 137 in 49e14a1

metricproducer.GlobalManager().AddProducer(tel.ocRegistry)

[splunkericl]

Can this PR wait for a couple releases? Our team relies on OpenCensus reporting and the metrics generated. Some metrics in queue_sender like queue size and queue capacity are important for our business.

We only notice the OpenCensus metrics is being removed because of the feature gate change in V0.92. I can imagine there are other users in the same boat. Would it make sense to wait for a couple releases so users have time to migrate off OpenCensus metrics?

[codeboten]

Some metrics in queue_sender like queue size and queue capacity are important for our business.

Thanks for the feedback @splunkericl! Can you specify which metrics? Queue size and capacity were added to the opentelemetry generated metrics some time ago. See #8716

[codeboten]

Our team relies on OpenCensus reporting and the metrics generated

@splunkericl just more follow up on this, any components that's using OpenCensus to generate metrics can continue to do so even with this change. The telemetry configuration for the Collector still supports the OpenCensus bridge.

[splunkericl]

@codeboten ah I see. So the application generating open census metrics will see them in the prometheus server spawned? If that is the case that should be fine.

Our application has been scraping against the prometheus metrics endpoint and use these metrics for business logics. As long as the workflow is still the same it should be fine and gives us more time to migrate to start using OTEL metrics framework.

[codeboten]

@splunkericl right. The metrics that are being exposed via prometheus today will continue to be exposed in the same manner, regardless of how those metrics are being recorded inside the collector itself.

You can see a sample output of the metrics before and after the flag is used here: #9029 (comment)

Any component (in core or in contrib) that is still recording its metrics via opencensus will continue to see its metrics exported via the collector's internal prometheus endpoint. Note there is an open issue to migrate components away in the future though: open-telemetry/opentelemetry-collector-contrib#29867. This would allow us to remove a dependency on the opencensus library.

[splunkericl]

Got it. Thanks for the explanations!