Spring boot runtime metrics native reduced

[zeitlinger]

trimmed down version of #13078

[zeitlinger]

@jeanbisutti here's a version that supports a subset of metrics for native mode - I'd suggest we start here and add more coverage for native mode later

[jeanbisutti]

here's a version that supports a subset of metrics for native mode

@zeitlinger Could you please elaborate a bit what this PR is doing?

[zeitlinger]

here's a version that supports a subset of metrics for native mode

@zeitlinger Could you please elaborate a bit what this PR is doing?

sure @jeanbisutti

Initially, I tried to add all runtime metric features to native image - but it got too difficult.
Therefore, this PR supports everything that I got working so far, which is all except:

• JFR - this has some changes in GraalVM 23, so it probably makes sense that we do the upgrade first - see https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/13173/files#diff-3c8c04145304a1ad8cf84cfe7adc613e44be3e69377545047da8a4bc42197d66R139
• Memory buffer metrics are not working - not sure why: see https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/13173/files#diff-cb65f3946e8d3d3ded39f235469855abb8d5df50be4b73c9979a1c4bf4308012R225

[jeanbisutti]

@zeitlinger

In the tests, JFR is now not enable at the the build time: 6850c88#diff-75989ca3659128c1bc6aea21d1129a7a704b98959fad35345d5c3c216c53c91cL71

Is it related to the native build failure mentioned in #13078 (comment)?

If there is JFR-related code, even programmatically disabled, could you please renable JFR at build time in the tests to check potential issues at the build time?

Ideally, if the JFR code can't be used in the native image, I would prefer to not include it at the build time (see #13078 (comment)) to avoid side effects at the build time (and help limit the native image size).

[zeitlinger]

@zeitlinger

In the tests, JFR is now not enable at the the build time: 6850c88#diff-75989ca3659128c1bc6aea21d1129a7a704b98959fad35345d5c3c216c53c91cL71

Is it related to the native build failure mentioned in #13078 (comment)?

yes
I realized that the failure could either be caused by enabling JFR - or by using graal 23

If there is JFR-related code, even programmatically disabled, could you please renable JFR at build time in the tests to check potential issues at the build time?

JFR is enabled differently based on the graalvm version.
We should first figure out which versions we want to support - then we can add the flags in the test.

Ideally, if the JFR code can't be used in the native image, I would prefer to not include it at the build time (see #13078 (comment)) to avoid side effects at the build time (and help limit the native image size).

I don't think it's enabled - can you point me to the relevant change?

[jeanbisutti]

I realized that the failure could either be caused by enabling JFR - or by using graal 23

and/or new added code causing build time issues

I don't think it's enabled - can you point me to the relevant change?

It's not what I have said. There is JFR-related code programatically disabled at runtime (

opentelemetry-java-instrumentation/instrumentation/runtime-telemetry/runtime-telemetry-java17/library/src/main/java/io/opentelemetry/instrumentation/runtimemetrics/java17/RuntimeMetrics.java

Line 139 in 7c68b99

if (System.getProperty("org.graalvm.nativeimage.imagecode") != null) {

), but processed during the native image compilation. It would be safer to not include this code in the native image compilation, or alternatively be more exhaustive in the native tests (with JFR enabled at build time, ...). The first option would be my preference because less supposed to add side effects at the build time (and it would help limit a bit the native image size).

[zeitlinger]

The first option would be my preference because less supposed to add side effects at the build time (and it would help limit a bit the native image size).

@jeanbisutti got that working now 😄

[zeitlinger]

@jeanbisutti please check again

[jeanbisutti]

@zeitlinger After a lot of discussions, it looks generally good to me.

I have approved with some comments.