opentelemetry-java-instrumentation
opentelemetry-java-instrumentation copied to clipboard
More runtime metrics for Spring starter with GraalVM
Feature
Spring starter with GraalVM currently (when https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/13173 is merged) doesn't support
- JFR metrics - excluded with https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/fcdc4df4adfc22da273ea6d8c14c4cfec8c3737c/instrumentation/spring/spring-boot-autoconfigure/src/main/javaSpring3/io/opentelemetry/instrumentation/spring/autoconfigure/internal/instrumentation/runtimemetrics/RuntimeMetricsBeanRegistrationExcludeFilter.java#L23
- memory buffer metrics - not excluded, but just not working: https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/7c68b999bf3ae9398d068655582b457655c2537a/smoke-tests-otel-starter/spring-boot-common/src/main/java/io/opentelemetry/spring/smoketest/AbstractOtelSpringStarterSmokeTest.java#L226
GraalVM 23
PR: https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/13269
Once JFR metrics work: the current setup only tests the latest LTS version of GraalVM.
Graal 23 has a different options for enabling JFR - which has been tried out in https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/13078 - this line: https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/13078/files#diff-75989ca3659128c1bc6aea21d1129a7a704b98959fad35345d5c3c216c53c91cR71
It may turn out that JFR metrics are only possible with Graal 23, which would mean that we have test 23. If 21 also supports JFR metrics, we still want to test 23 - to know that our JFR metrics will not break in the future.
Cleanup
Runtime metrics are currently configured in RuntimeMetricsAutoConfiguration class.
https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/13236 is a PR with a cleaner separation
of runtime metrics into different @Configuration classes.
It turned out that the RuntimeMetricsBeanRegistrationExcludeFilter can't exclude @Configuration classes, so
we discarded that approach. => solved by excluding the bean contained un the autoconfiguration