Otel metrics support

[brunobat]

• Part of Add support for OpenTelemetry metrics. #39033

Things to look at:

• quarkus.otel.metrics.enabled=false by default at build time.
• gRPC sender refactoring. Both the gRPC and HTTP senders are reusable between signals.
• General refactoring, most packages and class names assumed OpenTelemetry Tracing, now we have other signals.
• Metrics wiring using SPI-CDI bridge, not the customizers. (Still a work in progress)
• Update the shutdown hook.
• New Build steps and resources retention.
• New tests in Deployment plus OpenTelemetry and Vert.x exporter IT projects.
• CDI bean selection and exclusions on the exporter provider.
• Metrics export injection
• AggregationTemporality and DefaultAggregation on the metrics exporter

Includes:

• Add recent new tls to the metrics exporter
• Drop of deprecated properties

Ongoing:

• Docs, on a different PR

[quarkus-bot]

/cc @radcortez (opentelemetry)

[ayushghosh]

@brunobat do we have any eta for this being merged ?

[brunobat]

Not yet @ayushghosh

[brunobat]

PR is ready to review. Will be working on the docs in a different PR because this one is already too big.

[geoand]

The test failures are suspicious

[brunobat]

The test failures are suspicious

very... Looking into it.

[brunobat]

ok... fixed native mode and broke the exporter... Looking into that.

[brunobat]

@geoand and @radcortez can you guys review this one now? @gsmet PRs did the trick.

[janhenke]

The test failures seem due to a missing docker image, maybe a rerun would succeed?

Is there a realistic chance to get this merged in time for the 3.13 release?

[geoand]

@brunobat is this ready from your perspective?

Asking so I can start looking at it or not

[brunobat]

The metrics part yes, @geoand. This PR is already too big.
From the documentation and configuration point of view I'm preparing updates at 2 levels:

• On this PR I'll put metrics off by default, to comply with it's experimental nature. Working on it now.
• On the documentation PR I'm adding signal independent configurations so ppl can configure all signals with the same connection properties... That requires overrides and some additional tweaks. OTel documentation also is going to be split.

[geoand]

Gotcha, thanks a lot

[geoand]

General refactoring, most packages and class names assumed OpenTelemetry Tracing, now we have other signals

This makes perfect sense, but I just want to make sure you are aware and okay with the fact this is will make backporting fixes to 3.8 harder.

[geoand]

I assume this is not needed because of the new VertxHttpSender? If so, maybe the old class can be renamed to the new one so we can retain the git history?

[brunobat]

makes sense

[brunobat]

Sorry... Just tried it but I'm not sure how to do this without creating a mess.

[geoand]

Okay, no problem

[brunobat]

General refactoring, most packages and class names assumed OpenTelemetry Tracing, now we have other signals

This makes perfect sense, but I just want to make sure you are aware and okay with the fact this is will make backporting fixes to 3.8 harder.

Yes, that will be a pain, but my OCD makes me move them to a new package. Day to day operations will get increasingly confusing, especially when logging is brought in as well.

[geoand]

Sure, just wanted to make sure you were aware.

I'm +1 for this, I just had some comments

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 6c87887.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.