Hi Robert,
The idea is to phase out and improve over the JMX metrics gathering implementation.
How would the implementation be improved? I think you can meet the requirements by implementing custom events using the jdk.jfr API. Such as solution can work on earlier JDK releases and you could design it (and modify it in the future) to suite your use case. Erik ________________________________ From: hotspot-jfr-dev <hotspot-jfr-dev-retn@openjdk.org> on behalf of Robert Toyonaga <rtoyonag@redhat.com> Sent: Wednesday, February 1, 2023 3:22 PM To: hotspot-jfr-dev@openjdk.org <hotspot-jfr-dev@openjdk.org> Subject: OpenTelemetry and new JFR events Hello hotspot-jfr-dev! I'm Robert on the Java monitoring team at Red Hat. I've been working on building an OpenTelemetry metrics gatherer using JFR<https://github.com/open-telemetry/opentelemetry-java-contrib/tree/main/jfr-streaming>. The goal is to create an implementation that meets the OpenTelemetry specification<https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/semantic_conventions/runtime-environment-metrics.md#jvm-metrics> outlining metrics related to the JVM. The idea is to phase out and improve over the JMX metrics gathering implementation. However, the set of existing JFR events is missing a few data points required to accomplish this. I've identified some additions that will help to fill in the gaps here<https://docs.google.com/document/d/1oP8arX7FpZFnyA4nVi_k83eem7gh5w4_PJyPNZZFwRk/edit?usp=sharing>. If the changes seem reasonable, the first additions I'll try to make are jdk.SerialGCHeapSummary and jdk.CPULinuxLoadAverage. Please let me know what you think. Thank you! Robert Toyonaga