"No collector" approach to monitor GraalVM Native Image applications NISHIKAWA, Akihiro (Aki) Cloud Solution Architect, Microsoft @logico-jp.dev linkedin.com/in/anishi1222/ 

Živijo! こんにちは! Hello! { "name": "Akihiro Nishikawa", "country": "Japan", "workFor": "Microsoft", "favourites": [ "JVM", "GraalVM", "Azure" ], "expertise": [ "Application integration", "Container", "Serverless" ] } 

Why this topic? 

We often use Java agents for instrumentation. 1) How do we improve startup time of CPU restricted pods? 2) Can we use the same agent for GraalVM Native Image? 

Framework auto-instrumentation What I want to share with you in this talk 

Agenda  Why this topic?  Observability  OpenTelemetry  Zero-code Instrumentation  GraalVM  Zero-code instrumentation for native image  Agent, or...?  Spring Boot  Quarkus  Conclusion 

Observability 

Monitoring large number of components (microservices) is quite hard and difficult. Image: “Mastering Distributed Tracing” by Yuri Shkuro 

Observability is the ability to understand the internal state of a system by examining its outputs. In the context of software, this means being able to understand the internal state of a system by examining its telemetry data, which includes traces, metrics, and logs. https://opentelemetry.io/docs/what-is-opentelemetry/#what-is-observability 

tells us what’s happening, why it’s happening and how to fix it. Monitoring vs. Observability Two ways to identify the underlying cause of problems Traces Metrics Logs Profiles Events Monitoring Observability tells us when something is wrong. “proactive” “reactive” 

OpenTelemetry (OTel)  An Observability framework and toolkit designed to create and manage telemetry data such as traces, metrics, and logs.  Profiler signal is under progress.  Vendor and tool agnostic.  Not an observability backend like Jaeger, Prometheus, or other commercial vendors.  Focused on the generation, collection, management, and export of telemetry. Documentation | OpenTelemetry 

The 2nd most active CNCF project https://all.devstats.cncf.io/d/1/activity-repository-groups?orgId=1&var- period=d7&var-repogroups=All 

Objectives [1] Focuses solely on collecting and delivering telemetry data. [2] Generating actionable insights and storing telemetry data are out of scope.  An observability backend like Jaeger, Prometheus, or other commercial vendors. A major goal of OpenTelemetry is that you can easily instrument your applications or systems[1], no matter their language, infrastructure, or runtime environment. The storage and visualization of telemetry is intentionally left to other tools[2]. https://opentelemetry.io/docs/what-is-opentelemetry/ 

Java apps/libraries Collector (vendor agnostic) Receiver Processor Exporter Java Instr. APIs OTel SDK OTLP Transport telemetry data (1) Agent 

Java apps/libraries Exporter Java Instr. APIs OTel SDK Transport telemetry data (2) No collector 

Java apps/libraries Collector (vendor agnostic) Receiver Processor Exporter Java Instr. APIs OTel SDK OTLP Transport telemetry data (3) Gateway Load balancer Receiver Processor Exporter Receiver Processor Exporter 

Zero-code instrumentation 

Signal instrumentation and export input output application Signals (telemetry data) (logs, memory/CPU usages, etc.) export dashboard (Grafana, Prometheus, etc.) Instrumentation 

Zero-code instrumentation  Add monitoring and telemetry capabilities to an app without modifying its source code.  Java program runs normally, but an attached instrumentation agent monitors its behavior (e.g. HTTP requests, database calls) without any changes to your codebase. 

Why zero-code instrumentation? Makes observability easier to adopt.  No additional code for observability is needed.  Covers standard telemetry out-of-the-box, including in areas developers might overlook. 

Several ways to achieve zero-code instrumentation Type Description Example JVM Agent (Auto-Instrumentation) Attaches to the JVM at runtime and uses the Java Instrumentation API to modify bytecode and collect telemetry data. OTel Java Agent Vendor APM Agents Framework Auto- Instrumentation Java applications using certain frameworks can use instrumentation without custom code. Spring Boot Starter Quarkus extension Service Mesh (sidecar proxy) Service meshes (Istio, Linkerd, etc.), which work as a proxy, provide zero-code observability at the network Istio (Envoy) Linkerd eBPF-Based Instrumentation eBPF programs can safely hook into kernel and system calls to monitor application behavior. Pixie Cilium Hybrid Approaches Use a mix of the above. 

GraalVM 

GraalVM An advanced JDK with ahead-of-time Native Image compilation Hotspot based JIT compiler (Graal compiler) Native Image Ahead-of-time compilation Other features Polyglot runtime (Truffle) based Python, Node.js, Ruby, WASM, etc. 

GraalVM Native Image Fast start and scale Lower resource usage Predictable performance Improved security Compact packaging Several frameworks and platforms supported 

How to generate Native Image Input Application Substrate VM JDK Dependencies (libraries) 

How to generate Native Image Iterative analysis until reaching fixed point. Points-to Analysis Run initializations Input Application Substrate VM JDK Dependencies (Libraries) Heap snapshotting 

Iterative analysis until reaching fixed point. How to generate Native Image Points-to Analysis Run initializations Input Application Substrate VM JDK Dependencies (Libraries) Heap snapshotting Output Native executable Data section Image heap Text section AOT compiled code (specific to OS) 

Can use the same tools to solve issues with native image and Java apps. Tools Collected information • JDK Mission Control • Visual VM • jvmstat • jmx etc. • GC logs • Thread dumps • Heap dumps • Profiling • Error report • Core dump • JDK Flight Recorder etc. 

Zero-code instrumentation for native image 

Which type can be achievable? Type Description Example JVM Agent (Auto-Instrumentation) Attaches to the JVM at runtime and uses the Java Instrumentation API to modify bytecode and collect telemetry data. OTel Java Agent Vendor APM Agents Framework Auto- Instrumentation Java applications using certain frameworks can use instrumentation without custom code. Spring Boot Starter Quarkus extension Service Mesh (sidecar proxy) Service meshes (Istio, Linkerd, etc.), which work as a proxy, provide zero-code observability at the network Istio (Envoy) Linkerd eBPF-Based Instrumentation eBPF programs can safely hook into kernel and system calls to monitor application behavior. Pixie Cilium Hybrid Approaches Use a mix of the above. 

How do we instrument GraalVM Native Image applications ? Back to the motivation 

JVM myapp.jar agent OS JVM?? Native app agent OS Where does the agent run and attach? Normal Java apps Native lmage apps 

As of now, agents are not supported. [GR-55707] Java Agents Support in Native Image · Issue #8177 · oracle/graal 

Precisely speaking... Welcome, GraalVM for JDK 24! by Alina Yurenko | Medium  Native Image supports static agents in premain phase, but not yet in runtime.  GraalVM team is working hard to support agents in GraalVM...  GraalVM for JDK 25 (September 16, 2025) Milestone (github.com)  Feasibility study using Java agents with Native Image has started, but configuration is complicated.  Performance Improvement by 10 Times, GraalVM Application Observability Practice - Alibaba Cloud Community 

Any alternatives for zero-code instrumentation which works for GraalVM Native Image? 

Java apps/libraries Exporter Java Instr. APIs OTel SDK JVM myapp.jar agent OS Agents can work well with normal Java applications. Agents 

Java apps/libraries Exporter Java Instr. APIs OTel SDK JVM?? myapp agent OS But currently agents cannot work well with native image applications. 

Java apps/libraries Exporter Java Instr. APIs OTel SDK How about building native apps with exporter functionality, instead of using agents? Self-contained application 

Java apps/libraries Exporter Java Instr. APIs OTel SDK myapp dependencies OS Package all dependencies into a JAR and create a binary executable with it. 

Framework auto-instrumentation Type Example Native Image Support JVM Agent (Auto-Instrumentation) OTel Java Agent Vendor APM Agents (as of May 30, 2025) Framework Auto-Instrumentation Spring Boot Starter Quarkus extension Service Mesh (side-car proxy) Istio (Envoy) Linkerd (network level instrumentation) eBPF-Based Instrumentation Pixie Cilium (This is not aware of high-level context.) Hybrid Approaches It depends. 

Why framework auto-instrumentation? Applicable to Spring Boot Starter and Quarkus OpenTelemetry, etc. Spring Boot starter | OpenTelemetry Smaller startup overhead than OTel Java agent In CPU-restricted environments such as k8s, agents take longer to start up. Framework auto-instrumentation can co-exist along with a Java monitoring agent which has been already used. In the case of OTel Java agent, it might not work with the other agent. Can use configuration files (application.properties, application.yml) as well as environment variables. Configuration files does not work with OTel Java agent. Supports JVM metrics Agent is not the only option. 

Configuration 1) Spring Boot 

io.opentelemetry opentelemetry-bom io.opentelemetry.instrumentation opentelemetry-instrumentation-bom io.opentelemetry.instrumentation opentelemetry-spring-boot-starter com.azure.spring spring-cloud-azure-starter-monitor Dependencies (1/2) 

Dependencies (2/2) Additional settings are needed with signed JAR. ... org.graalvm.buildtools native-maven-plugin --libc=musl -Djava.security.properties=src/main/resources/custom.security Disabling signature verification is needed when generating native apps with signed JARs. 

# e.g. when using Azure Application Insights applicationinsights.connection.string =InstrumentationKey=000000-0000-0000-0000-0000000000 Configuration application.properties (application.yml) APPLICATIONINSIGHTS_CONNECTION_STRING="InstrumentationKey=000000-0000-0000- 0000-0000000000" azure-sdk-for-java/sdk/spring/spring-cloud-azure-starter-monitor at main · Azure/azure-sdk-for-java Environment variables  We can configure settings in either config files or environment variables. Config file (application.properties) 

Configuration 1) Quarkus 

Quarkus  Since 3.13, OTel support has been enhanced.  But MicroMeter is now recommended.  Quarkus provides dependencies around OpenTelemetry.  No dependency provided from OpenTelemetry is required.  Several platform specific dependencies are also provided.  Using OpenTelemetry - Quarkus  Quarkus OpenTelemetry Exporter :: Quarkiverse Documentation  Maven Repository: io.quarkiverse.opentelemetry.exporter 

Enhancement to support OTel in Quarkus 3.13 Quarkus 3.13 - OpenTelemetry Metrics, OpenTelemetry 1.39, TLS registry improvements and more... - Quarkus 

io.quarkus quarkus-opentelemetry io.opentelemetry.instrumentation opentelemetry-jdbc io.quarkiverse.opentelemetry.exporter quarkus-opentelemetry-exporter-azure Dependencies 

quarkus.application.name=myservice quarkus.otel.exporter.otlp.endpoint=http://localhost:4317 quarkus.otel.exporter.otlp.headers=authorization=Bearer my_secret quarkus.log.console.format=%d{HH:mm:ss} %-5p traceId=%X{traceId}, parentId=%X{parentId}, spanId=%X{spanId}, sampled=%X{sampled} [%c{2.}] (%t) %s%e%n quarkus.datasource.jdbc.telemetry=true # When using Azure Application Insights quarkus.otel.azure.applicationinsights.connection.string =InstrumentationKey=00000000-0000-0000-0000-000000000000 Configuration application.properties (application.yml) QUARKUS_OTEL_AZURE_APPLICATIONINSIGHTS_CONNECTION_STRING="InstrumentationKey=00 0000-0000-0000-0000-0000000000" Can use environment variables to set configuration. 

Demo 

Environment No intention of promotion, of course! Observability backend Application Insights Database Database for PostgreSQL Flexible Server Container platform Container Apps 

Each container Spring Boot Quarkus 

Collect telemetry data from polyglot apps 

No content

No content

I'm worried that this works on Azure only... W, wait! 

How about using Grafana Cloud? 

Also works with other OTel backgrounds, of course Dependencies should be modified, though… Spring Boot Starter × Grafana Cloud io.opentelemetry.instrumentation opentelemetry-spring-boot-starter io.opentelemetry.instrumentation opentelemetry-jdbc 

Also works with other OTel backgrounds, of course Dependencies should be modified, though… Quarkus × Grafana Cloud io.quarkus quarkus-opentelemetry io.opentelemetry.instrumentation opentelemetry-jdbc 

No content

Conclusion 

Takeaways  No-collector approach is not just for agent but also for framework auto-instrumentation.  Java agents don’t work with GraalVM Native Image apps as of now.  Framework auto-instrumentation has several advantages over Java agent. 

Resources OpenTelemetry https://opentelemetry.io/ GraalVM https://graalvm.org/ Spring https://spring.io/ Quarkus https://quarkus.io/ Sample repo https://github.com/Azure-Samples/java-native-telemetry 

Hvala! ありがとう! Thank you!