-
Notifications
You must be signed in to change notification settings - Fork 881
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
Add JFR streaming metrics gatherer #7886
Add JFR streaming metrics gatherer #7886
Conversation
@roberttoyonaga can you split out the |
Yup I can do that |
runtime-telemetry-jfr
and runtime-telemetry-jmx
public void afterAgent(AutoConfiguredOpenTelemetrySdk autoConfiguredSdk) { | ||
ConfigProperties config = autoConfiguredSdk.getConfig(); | ||
|
||
boolean defaultEnabled = config.getBoolean("otel.instrumentation.common.default-enabled", true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this say that jfr instrumentation is enabled by default?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I thought that might be a good choice because its similar to the JMX gatherer, which is also collecting metrics. And by default we are only collecting metrics not already covered by JMX.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And by default we are only collecting metrics not already covered by JMX.
True.. although the metrics it produces aren't part of the semantic conventions (yet). Wondering if that influences our decision.
Generally, I think they contain useful data, but need just a bit of adjustment to match the metric semantic conventions guidelines. I.e. they are likely to change before being added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm I see, yeah I think maybe its better to disable them by default. Then once its decided how the semantic conventions can be updated, they can be enabled by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also discussed at the March 2 2023 SIG. Decided that the new metrics should not be enabled by default until the semantic conventions can be updated.
.../io/opentelemetry/instrumentation/javaagent/runtimetelemetryjfr/JfrRuntimeMetricsTest.groovy
Outdated
Show resolved
Hide resolved
} | ||
|
||
otelJava { | ||
minJavaVersionSupported.set(JavaVersion.VERSION_17) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious how this works with the agent. Do we publish different versions of the agent, or do we package the jfr stuff up in the java 8 agent and only allow it to be activated if we detect we're running on java 17+?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not 100% clear on this either. I tried building with 17, and running with 11 and things run normally, just without the JFR streaming.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed in the March 2 2023 SIG . Confirmed nothing must be done in order to prevent JDK17 features from breaking things.
…ed. Remove test fixtures and put GC tests in test dir
...library/src/main/java/io/opentelemetry/instrumentation/runtimetelemetryjfr/JfrTelemetry.java
Show resolved
Hide resolved
...library/src/test/java/io/opentelemetry/instrumentation/runtimetelemetryjfr/GenerateDocs.java
Outdated
Show resolved
Hide resolved
.../src/main/java/io/opentelemetry/instrumentation/runtimetelemetryjfr/JfrTelemetryBuilder.java
Outdated
Show resolved
Hide resolved
...rc/main/java/io/opentelemetry/instrumentation/runtimetelemetryjfr/internal/DurationUtil.java
Outdated
Show resolved
Hide resolved
...java/io/opentelemetry/instrumentation/runtimetelemetryjfr/internal/RecordedEventHandler.java
Outdated
Show resolved
Hide resolved
...java/io/opentelemetry/instrumentation/runtimetelemetryjfr/internal/RecordedEventHandler.java
Outdated
Show resolved
Hide resolved
…/opentelemetry/instrumentation/runtimetelemetryjfr/GenerateDocs.java Co-authored-by: Mateusz Rzeszutek <[email protected]>
…/opentelemetry/instrumentation/runtimetelemetryjfr/JfrTelemetryBuilder.java Co-authored-by: Mateusz Rzeszutek <[email protected]>
…/opentelemetry/instrumentation/runtimetelemetryjfr/internal/DurationUtil.java Co-authored-by: Mateusz Rzeszutek <[email protected]>
…aga/opentelemetry-java-instrumentation into jfr-runtime-metrics-gatherer
Summary of changes:
test
folder and set up tasks that specify different GCs based on the type of GC test.Usage
Include
-Dotel.instrumentation.runtime-telemetry-jfr.enabled=true
to enable metrics not already covered by JMX.Include
-Dotel.instrumentation.runtime-telemetry-jfr.enable-all=true
to enable all JFR metrics gathering.Notes
The diff is quite massive, but almost all of it is a direct copy-paste.
A follow up PR will be made to rename
runtime-metrics
toruntime-telemetry-jmx
I'm not sure why the test
Agent loads in when separate jvm is launched
fails with this output. Note, this only happens when JFR is activated in the Java agent by default (I've currently disabled it which means the test is currently passing. See comments below).