Uploaded image for project: 'Quarkus Documentation'
  1. Quarkus Documentation
  2. QDOCS-1395

Known issue: Semeru JDK has different opentelemetry metrics that OpenJDK

XMLWordPrintable

    • Icon: Task Task
    • Resolution: Done
    • Icon: Major Major
    • IBQ-3.27.0 GA
    • None
    • Downstream-docs
    • None
    • 3
    • False
    • Hide

      None

      Show
      None
    • False
    • Hide
      :_mod-docs-content-type: REFERENCE
      [id="ref_rn-qdocs-1395-opentelemetry-metrics-differ-on-semeru"]
      = OpenTelemetry: JVM metrics differ on IBM Semeru Runtimes

      In the current release, JVM metrics exported by Quarkus Micrometer to OpenTelemetry differ between IBM Semeru Runtimes and OpenJDK HotSpot.
      The metric set and memory pool breakdowns differ across JVMs because the OpenTelemetry conventions obtain pool names from `MemoryPoolMXBean`, and each JVM defines different pools.
      Dashboards, alerts, and queries built for HotSpot can fail to match Semeru outputs, and you need to adjust them.

      For example, with the `jvm.memory.used` metric, HotSpot commonly reports pools such as `G1 Survivor Space`, `G1 Eden Space`, `G1 Old Gen`, `Metaspace`, and `CodeHeap 'profiled nmethods'`.
      Semeru reports pools such as `class storage`, `JIT code cache`, `nursery-allocate`, and `tenured-SOA`.
      Review your metric filters and attribute selectors such as `jvm.memory.pool.name` and `jvm.memory.type` to account for JVM-specific pool names and for pools that exist only on one JVM.

      When you enable the bridge with `quarkus-micrometer-opentelemetry`, OpenTelemetry auto-instrumentation for JVM metrics is disabled by default, and Micrometer collects the JVM metrics.

      For more information, see:

      * Quarkus link:https://quarkus.io/guides/observability[Observability]
      * Quarkus link:https://quarkus.io/guides/telemetry-micrometer[Micrometer metrics]
      * Quarkus link:https://quarkus.io/guides/telemetry-micrometer-to-opentelemetry[Micrometer and OpenTelemetry extension]
      * link:https://opentelemetry.io/docs/specs/semconv/runtime/jvm-metrics[JVM metrics semantic conventions]
      * link:https://eclipse.dev/openj9/docs/api/jdk11/jdk.management/com/ibm/lang/management/MemoryPoolMXBean.html[OpenJ9 memory pool names (MemoryPoolMXBean)]
      * link:https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/runtime-telemetry/runtime-telemetry-java17/library[OpenTelemetry runtime telemetry (Java 17) library]

      // https://issues.redhat.com/browse/QDOCS-1395
      // SME: Martin Ocenas, Bruno Baptista
      // Observability
      // Known issue
      // include::rn/ref_rn-qdocs-1395-opentelemetry-metrics-differ-on-semeru.adoc[leveloffset=+2]
      Show
      :_mod-docs-content-type: REFERENCE [id="ref_rn-qdocs-1395-opentelemetry-metrics-differ-on-semeru"] = OpenTelemetry: JVM metrics differ on IBM Semeru Runtimes In the current release, JVM metrics exported by Quarkus Micrometer to OpenTelemetry differ between IBM Semeru Runtimes and OpenJDK HotSpot. The metric set and memory pool breakdowns differ across JVMs because the OpenTelemetry conventions obtain pool names from `MemoryPoolMXBean`, and each JVM defines different pools. Dashboards, alerts, and queries built for HotSpot can fail to match Semeru outputs, and you need to adjust them. For example, with the `jvm.memory.used` metric, HotSpot commonly reports pools such as `G1 Survivor Space`, `G1 Eden Space`, `G1 Old Gen`, `Metaspace`, and `CodeHeap 'profiled nmethods'`. Semeru reports pools such as `class storage`, `JIT code cache`, `nursery-allocate`, and `tenured-SOA`. Review your metric filters and attribute selectors such as `jvm.memory.pool.name` and `jvm.memory.type` to account for JVM-specific pool names and for pools that exist only on one JVM. When you enable the bridge with `quarkus-micrometer-opentelemetry`, OpenTelemetry auto-instrumentation for JVM metrics is disabled by default, and Micrometer collects the JVM metrics. For more information, see: * Quarkus link: https://quarkus.io/guides/observability [Observability] * Quarkus link: https://quarkus.io/guides/telemetry-micrometer [Micrometer metrics] * Quarkus link: https://quarkus.io/guides/telemetry-micrometer-to-opentelemetry [Micrometer and OpenTelemetry extension] * link: https://opentelemetry.io/docs/specs/semconv/runtime/jvm-metrics [JVM metrics semantic conventions] * link: https://eclipse.dev/openj9/docs/api/jdk11/jdk.management/com/ibm/lang/management/MemoryPoolMXBean.html [OpenJ9 memory pool names (MemoryPoolMXBean)] * link: https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/runtime-telemetry/runtime-telemetry-java17/library [OpenTelemetry runtime telemetry (Java 17) library] // https://issues.redhat.com/browse/QDOCS-1395 // SME: Martin Ocenas, Bruno Baptista // Observability // Known issue // include::rn/ref_rn-qdocs-1395-opentelemetry-metrics-differ-on-semeru.adoc[leveloffset=+2]

      Scope: Quarkus Micrometer-OpenTelemetry provides different metrics when running Semeru JDK than when running OpenJDK.

      We've encountered it while testing the "jvm_memory_used_bytes" metric, where OpenJDK provides metrics such as "Compressed Class Space", "CodeHeap 'profiled nmethods'", "G1 Survivor Space", and "Metaspace". 

      While SemeruJDK has metrics like: "class storage", "JIT code cache", "nursery-allocate", "tenured-SOA".

      SME: Martin Ocenas

      Quarkus Issue: https://issues.redhat.com/browse/QUARKUS-6805

      This is also being addressed in upstream test coverage - https://github.com/quarkusio/quarkus/pull/50651/files#diff-c083b90637f7b22cfdbfad287090239433beba904472aac18fce5052e29fdd84

              mmaler@redhat.com Michal Maléř
              mmaler@redhat.com Michal Maléř
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: