Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenTelemetry extension re-write using the SDK AutoConfigure #30033

Merged
merged 1 commit into from
Mar 15, 2023

Conversation

brunobat
Copy link
Contributor

@brunobat brunobat commented Dec 22, 2022

Last part of #26444

OpenTelemetry (OTel) Extension re-write to support OTel Autoconfiguration.

What do we get from it:

  • Support configuration according to OTel Autoconfiguration
  • People using OTel standard configs will benefit from Quarkus configuration features.
  • Access to features already implemented in the autoconfig of the SDK can be easily commanded.
  • Make it easier to adopt future OTel features.
  • Allow using the stock OTel exporters in the future.

What was done:

  • Documentation to comply with the changes bellow and to improve some outdated aspects like the docker collector on Jaeger.
  • Cleanup and refactoring. In special, move away from the main processor instrumentation related build steps.
  • Simplify sampler and support its SPI hook
  • Jakarta rebase with main
  • Create substitutions for the Otel Auto-configuration code using reflection but not needed for runtime
  • Remove obsolete config scanning steps
  • Adapt IT tests, improve their resilience and speedup their execution
  • Fix additional issues from dev mode reload
  • Load missing properties, fix resources and sampler
  • Create Otel SDK on a bean producer
  • Autoconfigure wiring
  • New build and runtime configurations based on OTel guidance, ensuring backwards compatibility.

What was left for later:

@quarkus-bot
Copy link

quarkus-bot bot commented Dec 22, 2022

/cc @radcortez(opentelemetry)

@github-actions
Copy link

github-actions bot commented Feb 2, 2023

🙈 The PR is closed and the preview is expired.

@gsmet gsmet added the triage/needs-rebase This PR needs to be rebased first because it has merge conflicts label Feb 4, 2023
@brunobat brunobat force-pushed the otel-autoconfigure-4 branch 4 times, most recently from 51dea72 to 562e6e9 Compare February 9, 2023 19:29
@brunobat brunobat marked this pull request as ready for review February 9, 2023 19:37
@brunobat brunobat removed the triage/needs-rebase This PR needs to be rebased first because it has merge conflicts label Feb 9, 2023
@quarkus-bot

This comment has been minimized.

@brunobat brunobat closed this Feb 10, 2023
@quarkus-bot quarkus-bot bot added the triage/invalid This doesn't seem right label Feb 10, 2023
@brunobat brunobat reopened this Feb 10, 2023
@quarkus-bot quarkus-bot bot removed the triage/invalid This doesn't seem right label Feb 10, 2023
@brunobat brunobat self-assigned this Feb 10, 2023
@brunobat
Copy link
Contributor Author

@luneo7 Please be aware of this PR. A review from you would be much appreciated.

@brunobat
Copy link
Contributor Author

brunobat commented Mar 8, 2023

@radcortez we can try the @ConfigMapping approach once we have the new version of the extension.

@@ -69,6 +70,14 @@ AdditionalBeanBuildItem ensureProducerIsRetained() {
.build();
}

@BuildStep
void registerNativeImageResources(BuildProducer<ServiceProviderBuildItem> services) throws IOException {
services.produce(ServiceProviderBuildItem.allProvidersFromClassPath(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we also add:
io.opentelemetry.sdk.autoconfigure.spi.AutoConfigurationCustomizerProvider
io.opentelemetry.sdk.autoconfigure.spi.ResourceProvider
io.opentelemetry.sdk.autoconfigure.spi.ConfigurablePropagatorProvider
?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was planning to add official support for them only later. I can add the SPIs, however I'll leave testing and documentation for later because this PR is already too big.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree. At this point, we should move forward and add these missing pieces later. They are not a blocker at this point.

@quarkus-bot

This comment has been minimized.

@quarkus-bot quarkus-bot bot added the area/infra-automation anything related to CI, bots, etc. that are used to automated our infrastructure label Mar 9, 2023
Copy link
Member

@gsmet gsmet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a few questions and very minor suggestions.

What's the status of this work exactly? Is it expected to land before our 3.0.0.CR1?


[NOTE]
====
All configurations have been updated from `quarkus.opentelemetry.\*` -> `quarkus.otel.*`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry to ask that but is it really an improvement? What's the rationale of this change?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is to align with the OTel side property semantics. See: https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk-extensions/autoconfigure/README.md#disabling-opentelemetrysdk

We will transparently support them from now on.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When OTel introduced its configuration namespace, we discussed and decided to align with it as close as possible:

  • Since the goal of OTel is to be supported across many cloud providers, tools, servers, etc, we want to stay within it. Ideally, users should use the same configuration as what they use in other external OTel aware components
  • We cannot prevent users from plugin in the OTel Agent, which uses the OTel configuration as specified. This should unify that configuration, so when you plug in the agent, it will use the defined Quarkus configuration (if any)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Thanks for the clarification.
I wonder if we should rewrite the properties as part of the upgrade process. Unfortunately, we cannot use regexps so we will have to map the old names to the new names manually.

Maybe it's not worth the hassle, I don't know.

docs/src/main/asciidoc/opentelemetry.adoc Outdated Show resolved Hide resolved
docs/src/main/asciidoc/opentelemetry.adoc Outdated Show resolved Hide resolved
extensions/opentelemetry/deployment/pom.xml Show resolved Hide resolved
/**
* No Metrics exporter for now
*/
@ConfigItem(name = "metrics.exporter", defaultValue = "none")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So you will have a singleton list with none in it, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. This will effectively disable OTel metrics.

@brunobat
Copy link
Contributor Author

brunobat commented Mar 9, 2023

Depends on the feedback @gsmet but yes, I'd like to add it to CR1 and issue follow up PRs later, according to the description in the 1st comment.
This contains the main changes and is already too big to keep adding functionality to it, in my opinion.

@quarkus-bot

This comment has been minimized.

@quarkus-bot

This comment has been minimized.

@brunobat brunobat requested a review from gsmet March 14, 2023 09:48
@quarkus-bot
Copy link

quarkus-bot bot commented Mar 15, 2023

Failing Jobs - Building db3bb13

Status Name Step Failures Logs Raw logs
✔️ Gradle Tests - JDK 11
Gradle Tests - JDK 11 Windows Build Failures Logs Raw logs
✔️ JVM Tests - JDK 11
✔️ JVM Tests - JDK 17
JVM Tests - JDK 17 Windows Build Failures Logs Raw logs
JVM Tests - JDK 19 Build ⚠️ Check → Logs Raw logs

Full information is available in the Build summary check run.

Failures

⚙️ Gradle Tests - JDK 11 Windows #

📦 integration-tests/gradle

io.quarkus.gradle.devmode.MultiSourceProjectDevModeTest.main line 22 - More details - Source on GitHub

org.awaitility.core.ConditionTimeoutException: Condition with lambda expression in io.quarkus.test.devmode.util.DevModeTestUtils that uses java.util.function.Supplier, java.util.function.Supplierjava.util.concurrent.atomic.AtomicReference, java.util.concurrent.atomic.AtomicReferencejava.lang.String, java.lang.Stringboolean was not fulfilled within 1 minutes.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)

⚙️ JVM Tests - JDK 17 Windows #

- Failing: extensions/resteasy-classic/rest-client/runtime 
! Skipped: extensions/amazon-lambda-http/deployment extensions/amazon-lambda-http/http-event-server extensions/amazon-lambda-rest/deployment and 105 more

📦 extensions/resteasy-classic/rest-client/runtime

io.quarkus.restclient.runtime.RestClientBaseTest. - More details - Source on GitHub

java.io.IOException: Failed to delete temp directory D:\a\quarkus\quarkus\extensions\resteasy-classic\rest-client\runtime\target\junit4822274520985205514. The following paths could not be deleted (see suppressed exceptions for details): 
	at org.junit.jupiter.engine.extension.TempDirectory$CloseablePath.createIOExceptionWithAttachedFailures(TempDirectory.java:350)
	at org.junit.jupiter.engine.extension.TempDirectory$CloseablePath.close(TempDirectory.java:251)

@gsmet gsmet merged commit 56f2dab into quarkusio:main Mar 15, 2023
@quarkus-bot quarkus-bot bot added this to the 3.0 - main milestone Mar 15, 2023
@gsmet
Copy link
Member

gsmet commented Mar 15, 2023

Let's merge. Thanks for your perseverance on this one!

@brunobat
Copy link
Contributor Author

Thanks @gsmet. Super happy to see this merged.

ClassLoader serviceClassLoader,
BiFunction<? super MetricExporter, ConfigProperties, ? extends MetricExporter> metricExporterCustomizer,
List<Closeable> closeables) {
// OTel metrics not supported and there is no need to call
Copy link

@hnourhani hnourhani Mar 28, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@brunobat does it mean that we cannot use these configuration to enable Prometheus exporter:
https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk-extensions/autoconfigure/README.md#prometheus-exporter

If not could start a PrometheusMetricReader manually using OpenTelemetry SDK and collect metrics?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct. No OTel Metrics on Quarkus for now. It requires a lot of rework in the instrumentation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/documentation area/infra-automation anything related to CI, bots, etc. that are used to automated our infrastructure area/tracing release/breaking-change
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

6 participants