-javaagent JVM flag — no code changes, no framework wrappers, and no recompilation required.
Prerequisites
- Java 11 or later (compatible with standard JVMs)
- A running HyperProbe broker (URL provided by your team or HyperProbe cloud setup)
- The
hyperprobe-agent.jarfile (downloaded from your HyperProbe dashboard or CI artifact store) - The git commit SHA of the deployed build (required for coordinate resolution)
How the agent works
When you attach the JAR with-javaagent, the JVM calls the agent’s initialisation sequence before your application’s main method runs. To ensure zero interference with your application, the agent:
- Starts in an isolated, child-first classloader (preventing dependency conflicts).
- Reads configuration strictly from environment variables.
- Connects to the HyperProbe broker over gRPC.
- Instruments your classes at load time using non-intrusive bytecode transformations.
- Listens for probe instructions and captures telemetry when probed lines execute.
Attaching the agent
Add the-javaagent flag to your JVM startup command. The Java agent requires configuration to be passed via environment variables to prevent configuration leakage into the host application and to adhere to twelve-factor app principles.
Configuration
The agent reads configuration exclusively from environment variables. System properties (-D flags) are intentionally ignored by the agent to ensure strict isolation.
Required variables
| Environment variable | Description |
|---|---|
HYPERPROBE_SERVICE_ID | Identifier for your service (e.g., uuid of the service from the dashboard) |
HYPERPROBE_ENVIRONMENT | Deployment environment (e.g., production, staging) |
HYPERPROBE_BROKER_URL | gRPC broker URL (e.g., https://logger.app.hyperprobe.co) |
GIT_COMMIT | Git commit SHA of the deployed build |
Safety guardrails
The Java agent continuously monitors JVM memory health. If free memory drops below 15%, the agent enters aYELLOW state (warning). If free memory drops below 5%, the agent enters a RED state, immediately suspending all instrumentation to protect the host application. Instrumentation automatically resumes after the HYPERPROBE_COOLDOWN_SEC period if memory levels stabilize.
| Environment variable | Default | Description |
|---|---|---|
HYPERPROBE_HITS_PER_SEC | 20 | Maximum probe hits per second globally before the agent throttles |
HYPERPROBE_BANDWIDTH_KB_PER_SEC | 1024 | Maximum telemetry bandwidth in KB/s |
HYPERPROBE_COOLDOWN_SEC | 10 | Cooldown period in seconds after the memory safety shield triggers |
HYPERPROBE_SYNC_INTERVAL_MS | 60000 | How often (in ms) the agent syncs probe state with the broker |
HYPERPROBE_FLUSH_INTERVAL_MS | 1000 | How often (in ms) the agent flushes the telemetry queue to the broker |
Data controls
| Environment variable | Default | Description |
|---|---|---|
HYPERPROBE_REDACT_KEYS | See below | Comma-separated list of field names to auto-redact from snapshots |
HYPERPROBE_REDACT_VALUES | — | Comma-separated list of values to redact |
HYPERPROBE_MAX_OBJECT_DEPTH | 3 | Maximum depth for serializing nested objects |
HYPERPROBE_MAX_ARRAY_LENGTH | 3 | Maximum number of array elements captured |
HYPERPROBE_STACK_FRAME_DEPTH | 3 | Number of stack frames included in snapshots |
HYPERPROBE_MAX_OBJECT_PROPERTIES | 50 | Maximum number of object properties captured |
HYPERPROBE_MAX_STRING_LENGTH | 1024 | Maximum string length before truncation |
The default redacted keys are:
password, secret, token, authorization, cookie, key, signature. These are applied automatically. Add your own sensitive field names via HYPERPROBE_REDACT_KEYS to override the defaults.Optional configuration
| Environment variable | Default | Description |
|---|---|---|
HYPERPROBE_DISABLED | — | Set to YES to completely skip agent initialization at startup |
HYPERPROBE_APP_ROOT | — | Defines the root package or directory to restrict instrumentation scanning |
Examples
- Docker
- Kubernetes
When deploying via Docker, it is best practice to bake the Pass the build argument when building the image in your CI/CD pipeline:Because the commit is baked in, you can run the container cleanly without runtime variables:
GIT_COMMIT directly into the image during the build process using build arguments, along with your static configuration.Dockerfile
Framework integrations
The agent hooks into the standard JVM initialization process, so it works seamlessly alongside any Java framework. Provide the-javaagent flag as a standard JVM argument in your build or run tasks.
- Spring Boot (Maven)
- Spring Boot (Gradle)
- Application Servers
When running via the Spring Boot Maven plugin, provide the agent path in
<jvmArguments> and set configuration in <environmentVariables>.pom.xml
