Intelligent JVM Monitoring: Combining JDK Flight Recorder with AI

Intelligent JVM monitoring by combining JDK Flight Recorder (JFR) with AI

High-level overview

• Problem: Distributed Java microservices (example: “Galaxy Cafe”) can experience intermittent performance issues during traffic spikes. Manually collecting JFR and debugging per-service is slow and brittle.
• Proposal: Deploy a Java agent to each JVM that streams selected JFR events to a central monitoring service. Use an LLM-based AI pipeline to analyze aggregated JFR data for anomalies, and control services remotely via JMX (MBeans) to implement automated/self‑healing actions with human-in-the-loop for critical changes.

Core technologies & components

JDK Flight Recorder (JFR)

• Use a Java agent (packaged with a manifest and passed via -javaagent) so JFR can be started on each microservice without changing startup arguments.
• Use the JFR API to obtain the default (low‑overhead) configuration or supply a custom JFC that only enables the specific events you need.
• Start the recording asynchronously in premain to avoid blocking application startup; add an event handler that serializes events and streams them to the monitoring service.
• Note: the default config enables many events (~90). Handlers and streaming increase overhead — limit enabled events.

JMX (Java Management Extensions)

• Expose runtime controls and observability using (dynamic) MBeans: attributes, operations, notifications.
• Register MBeans with the platform MBeanServer; inspect and invoke via JMX client or tools like JConsole, VisualVM, or Java Mission Control (JMC).
• Attach metadata to MBean operations/attributes (via MBeanInfo and Descriptor) to describe available actions (action name, description, whether confirmation is required). The AI system uses this metadata to know what it can remotely trigger.
• Example controls: clear cache, enable/disable batch mode, invoke garbage collection, toggle fetch mode (single vs batch).

Central monitoring service

• Receives streamed JFR events from agents, persists them (database), and runs scheduled anomaly-detection tasks that feed the AI pipeline.
• Performs MBean discovery (JMXServiceURL → queryNames) and filters MBeans by type (e.g., self‑healing) to expose available actions.
• Implements a control endpoint (processDecision) to execute decisions: checks action availability, confidence thresholds, cooldowns, and whether human confirmation is required before remotely invoking JMX (setAttribute/invoke).

AI / LLM integration (LangChain4j demo)

• Uses LangChain4j as an AI services abstraction to call an LLM (demo used Anthropic Hayo 4.5).
• Prompting strategy:
  • Separate system prompt (role, context, available actions, output format, tool instructions) and user prompt (request + preprocessed JFR aggregates).
  • Inject discovered actions (from MBean metadata) into the system prompt so the LLM knows permitted operations.
  • Require the model to output a strict JSON schema: reasoning first, then service name, key metrics, trends, recommended action, and confidence.
  • Encourage “reasoning before answer” to improve explanations and decision quality.
• Use chat memory per service (memory ID = service name) so the model can track trends over time (e.g., last 20 messages).
• Use function/tool calling: the model can return a decision and invoke a control tool (annotated method). The monitoring server validates and executes via JMX if allowed.

Implementation / practical guide (tutorial-style steps)

1. Build a Java agent with premain and package it as a -javaagent to deploy to each microservice.
2. In the agent, obtain a JFR configuration (default or custom JFC), create a RecordingStream, add an event handler that serializes desired event attributes, and start the recording asynchronously in its own thread.
3. Host a monitoring server that exposes an endpoint to receive streamed JFR events and persist them for analysis.
4. Implement dynamic MBeans in each microservice, override getMBeanInfo to include Descriptors for action name and confirmation, and register them with the platform MBeanServer.
5. In the monitoring service, discover MBeans remotely via JMXServiceURL + queryNames and filter based on MBean metadata (type).
6. Preprocess / aggregate JFR events (counts, averages, max, units) before feeding to an LLM; the presenters demoed using AI to produce that aggregation when needed.
7. Design a system prompt to include role, context, available actions (from MBean discovery), output schema, and tool usage rules.
8. Use LangChain4j (or equivalent) to glue model, memory, and tool integration. Create an AI interface (e.g., AnalysisAgent.analyze(serviceName, context)) and feed the preprocessed metrics.
9. Implement a safe control tool (processDecision) to validate model suggestions against available actions, thresholds, cooldowns, and whether confirmation is required; then call JMX setAttribute/invoke to apply the change.
10. Optionally include human-in-the-loop approval for critical actions.

Demo behavior & decision flow (example)

• Scenario: The Order service initially uses single-product fetch.
• Monitoring receives JFR events and the model suggests enabling batch fetch with 70% confidence → below threshold → rejected.
• With continued data the model’s confidence rises to 90% → passes threshold → monitoring service calls the control tool → JMX setAttribute enables batch mode in the Order service → batch fetch begins.

Decision flow emphasis: - Use confidence thresholds and cooldowns. - Require human confirmation for critical operations. - Log model reasoning and decisions for audit and explainability.

Design notes, trade-offs & operational considerations

• Aggregation location: Agent-side aggregation reduces transport but limits global view; server-side centralizes data but may be heavy to stream everything.
• Limit recorded events sent to reduce overhead; prefer custom JFC files controlled by the monitoring server.
• Security: Never leave remote JMX unsecured in production; use authentication, TLS, and proper network controls. For LLMs, consider secrets, compliance, and data exposure — on‑prem models (e.g., Olama) reduce exposure at a cost.
• Reliability: Use confidence thresholds, cooldowns, and human confirmation for critical actions to avoid unsafe automated changes.
• Observability / Explainability: Forcing the LLM to include reasoning and a confidence score improves traceability and helps policy decisions.

Tools, libraries & commands mentioned

• JFR API, custom JFC files, jfr print (CLI) for offline analysis
• JMX, MBeanServer, JConsole, VisualVM, Java Mission Control (JMC)
• LangChain4j (AI services abstraction), function/tool calling pattern
• Model used in demo: Anthropic Hayo 4.5; on‑prem hosting mentioned: Olama
• Java agent packaging: -javaagent via manifest

Open issues / future work

• How to scale streaming of raw JFR events in production (bandwidth/overhead).
• Best practices for aggregating and pre-processing JFR events before feeding to LLMs.
• Explore parallel approaches (e.g., integrating external monitoring systems vs a pure JDK-only approach).

Main speakers / sources

• Dwakim Nuttra — Oracle, JVM sustaining team (presenter)
• Yamur — co-presenter from the Oracle JVM sustaining team

(References: JFR, JMX, LangChain4j, Anthropic Hayo 4.5, Olama, JConsole/JMC/VisualVM, jfr print.)