Monitor GraalVM Native Apps with OpenTelemetry

JavaZone 2024.

Transcript

1. Monitoring GraalVM Native Image applications with OpenTelemetry NISHIKAWA, Akihiro (Aki) Cloud Solution Architect, Microsoft @logico_jp
2. Who am I? { "name": "Akihiro Nishikawa", "country": "Japan", "favourites": [ "JVM", "GraalVM", "Azure" ], "expertise": [ "Application integration", "Container and Serverless" ] }
3. Agenda  OpenTelemetry  GraalVM  Zero-code Instrumentation of Native Images  Case study  Takeaways
4. OpenTelemetry (OTel)
5. Monitoring large number of components (microservices) is quite hard and difficult. Image: “Mastering Distributed Tracing” by Yuri Shkuro
6. 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
7. 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”
8. Signal instrumentation and export input output application Signals (telemetry data) (logs, memory/CPU usages, etc.) export dashboard (Grafana, Prometheus, etc.) Instrumentation
9. Standards? What to follow for instrumentation and signal export?  Specifications  Implementation (SDKs, APIs, libraries)  Semantic conventions  Communication standards  Compatibilities  etc.
11. The 2nd most active CNCF project https://all.devstats.cncf.io/d/1/activity-repository-groups?orgId=1&var- period=d7&var-repogroups=All
12. 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/
14. Java apps/libraries Collector (vendor agnostic) Receiver Processor Exporter Java Instr. APIs OTel SDK OTLP Transport telemetry data (1) Collector (agent)
15. Java apps/libraries Exporter Java Instr. APIs OTel SDK Transport telemetry data (2) No collector
16. 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
17. Would help you understand OpenTelemetry... Workshop  Observability with OpenTelemetry: From Idea to Insight (by Øyvind Randa and Hans Kristian Flaatten)
18. GraalVM
20. 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, etc.
21. GraalVM Native Image Fast start and scale Lower resource usage Predictable performance Improved security Compact packaging Several frameworks and platforms supported
22. Iterative analysis until reaching fixed point. Output How to generate Native Image Points-to Analysis Run initializations Input Application Substrate VM JDK Dependencies (Libraries) Native executable Text section Data section Heap snapshotting AOT compiled code (specific to OS) Image heap
23. Use cases (not limited to) CLI tools Self-contained, start up instantly, and easy to distribute. • picocli (picocli - a mighty tiny command line interface) • Pkl configuration language Pkl :: Pkl Docs (pkl-lang.org) Serverless & Containerized applications Suitable for use in containerized and serverless applications where severe start-up time and memory management are needed. picocli Pkl
24. For more details Conferences  Going AOT: Everything you need to know about GraalVM for Java applications (by Alina Yurenko) Workshop  Multi-Cloud Apps with GraalVM - Up and Running (by Olga Gupalo)
25. Zero-code instrumentation for native applications
26. Zero-code instrumentation for Java apps java -javaagent:path/to/opentelemetry-javaagent.jar \ -Dotel.service.name=your-service-name \ -jar myapp.jar JVM myapp.jar agent Can use bytecode instrumentation.
27. How about zero-code instrumentation of native apps?
28. Java agents don’t support Native Image applications. Support agents at image generation time · Issue #1065 · oracle/graal (github.com)
29. Iterative analysis until reaching fixed point. Output Native Image apps run without dependency on JDK. Points-to Analysis Run initializations Input Application Substrate VM JDK Dependencies (Libraries) Native executable Text section Data section Heap snapshotting AOT compiled code (specific to OS) Image heap
30. Alibaba’s feasibility study OTel Community Day North America 2024
31. Milestone (subject to change, of course ☺) GraalVM for JDK 25 (September 16, 2025) Milestone (github.com)
32. Java apps/libraries Exporter Java Instr. APIs OTel SDK “No collector” approach for native apps Exporter functionality should be packed into native applications.
33. Micrometer can also achieve this! Yes, I know. But you’d like to know another option, right?
34. Spring Boot
35. OpenTelemetry Spring Boot Starter Can collect signals where OTel Java agent does not work. OTel Java agent supports more out of the box instrumentation than Starter.
36. <dependency> <groupId>io.opentelemetry</groupId> <artifactId>opentelemetry-bom</artifactId> </dependency> <dependency> <groupId>io.opentelemetry.instrumentation</groupId> <artifactId>opentelemetry-instrumentation-bom</artifactId> </dependency> <!-- The OTel Spring Boot starter: https://tinyurl.com/otel-starter --> <dependency> <groupId>io.opentelemetry.instrumentation</groupId> <artifactId>opentelemetry-spring-boot-starter</artifactId> </dependency> Dependencies
37. Additional settings might be needed in some cases. In case of Azure <dependency> <groupId>com.azure.spring</groupId> <artifactId>spring-cloud-azure-starter-monitor</artifactId> </dependency> ... <plugin> <groupId>org.graalvm.buildtools</groupId> <artifactId>native-maven-plugin</artifactId> <configuration> <buildArgs> <buildArg>--libc=musl</buildArg> <jvmArgs>-Djava.security.properties=src/main/resources/custom.security</jvmArgs> </buildArgs> </configuration> </plugin> Disabling signature verification is needed when generating native apps with signed JARs.
38. # Most instrumentation properties are enabled by default. # If using Azure Application Insights, the following properties are required applicationinsights.connection.string =InstrumentationKey=000000-0000-0000-0000-0000000000 # If specific instrumentation is needed, we should explicitly enable it after disabling all instumentations otel.instrumentation.common.default-enabled=true Configuration application.properties (application.yml) Out of the box instrumentation | OpenTelemetry
39. Quarkus
40. 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.
41. Enhancement to support OTel in Quarkus 3.13 Quarkus 3.13 - OpenTelemetry Metrics, OpenTelemetry 1.39, TLS registry improvements and more... - Quarkus
42. <!-- Quarkus OpenTelemetry extension --> <dependency> <groupId>io.quarkus</groupId> <artifactId>quarkus-opentelemetry</artifactId> </dependency> <!-- if JDBC telemetry is needed --> <dependency> <groupId>io.opentelemetry.instrumentation</groupId> <artifactId>opentelemetry-jdbc</artifactId> </dependency> <!-- Additional exporters are available in Quarkiverse --> <dependency> <groupId>io.quarkiverse.opentelemetry.exporter</groupId> <artifactId>quarkus-opentelemetry-exporter-azure</artifactId> </dependency> Dependencies
43. 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 # If using Azure Application Insights, the following properties are required quarkus.otel.azure.applicationinsights.connection.string =InstrumentationKey=00000000-0000-0000-0000-000000000000 Configuration application.properties (application.yml)
44. Demo
45. Environment No intention of promotion, of course! ☺ Database Database for PostgreSQL Flexible Server Observability backend Application Insights Container platform Container Apps
46. Each container Spring Boot Quarkus
47. Collect Telemetry data from polyglot apps
48. Repository  Azure-Samples/java-native-telemetry (github.com)  JDK 17 is used but JDK 21 works as well.  Spring Boot  opentelemetry-spring-boot-starter (2.5.0-alpha used in this repo. The latest is 2.7.0)  opentelemetry-bom (1.38.0 used in this repo. The latest is 1.41.0)  Quarkus  quarkus-bom (3.11.2 used in this repo. The latest is 3.14.2)  quarkus-opentelemetry-exporter-azure (for Azure Application Insights, the latest is 3.8.3.1)
49. Case study
50. Customer case Backgrounds • Microservices on Kubernetes • Spring Boot (Kotlin) • Short-lived and stateless Challenges • Round-trip time got longer as their business grows. • Slow startup and long round-trip time gave negative impact to customer experience. Concerns • Is zero code instrumentation of native applications feasible?
51. Their decisions GraalVM OTel Spring Boot Starter Met their requirements around observability. Confirmed they could add special metrics with codes if needed. Confirmed starter did not spoil the advantage of native application. Round-trip time was improved. Improved startup time of each component. Reduced memory/CPU usage allows them to rearrange resources. Additionally, reduced attack surfaces.
52. Conclusion
53. Takeaways Agentless zero-code instrumentation • Works for GraalVM Native Image applications. • Spring Boot: Spring Boot Starter • Quarkus: enhanced support for OpenTelemetry Customer case study • In several scenarios, Agentless instrumentation fits better • Even if instrumenting typical Java applications. Let’s get involved! • OpenTelemetry project is active. • Your contribution is highly appreciated.
54. Resources OpenTelemetry https://opentelemetry.io/ GraalVM https://graalvm.org/ Spring https://spring.io/ Quarkus https://quarkus.io/
55. Thank you!