EaseAgent attaches to a JVM and adds tracing without changing your code

An agent that instruments the JVM rather than your source

EaseAgent is described as a lightweight and open Java agent for cloud-native and APM systems, and it is the underlying component that provides non-intrusive extensions to applications in the Java ecosystem. The non-intrusive claim is structural rather than a matter of discipline. EaseAgent loads into the running JVM and instruments the code at bytecode level, so a service gains distributed tracing, metrics and log collection without a single line of application code changing. It can collect distributed application tracing, metrics and logs for use in an APM system, and for tracing it follows the Google Dapper paper. The audience is a Java shop that already runs APM infrastructure and wants a single agent covering the frameworks it uses, rather than a hand-rolled OpenTelemetry SDK wiring in every service. It also has a service mesh angle, since it can help a service mesh, and EaseMesh in particular, do control panel work.

The plugin framework: Points, Interceptors and a chain

The architecture is described in enough detail to be useful, and the mechanism is Byte Buddy. A plugin defines where to make enhancements by implementing `Points`, which says which classes and methods to touch, and what to do at that point by implementing `Interceptor`. When the instrumented method is invoked, the unique index owned by the method is used as a parameter to call the common interface of `Agent Common Method Advice`, which finds the `Agent Interceptor Chain` by that unique index and calls the `before` method of each interceptor in the chain in priority order. Normally both a `Metric Interceptor` and a `Tracing Interceptor` sit in that chain and are called sequentially, and the data they collect is stored in `MetricRegistry` and `Tracing`. The `Reporter` module then takes it from there and sends it to Kafka. The `after` method of each interceptor is invoked in the reverse order of the `before` calls, which is the standard way to keep a stack-like chain consistent.

Which libraries are actually instrumented

The supported list is the practical constraint on the tool, and it is long enough to be useful for a Spring Boot shop. For metric and tracing collection the coverage includes JDBC 4.0, HTTP Servlet and HTTP Filter, and for Spring Boot 2.2.x the `WebClient`, `RestTemplate` and `FeignClient` clients. Then there is a list of middleware clients: RabbitMQ Client 5.x, Kafka Client 2.4.x, Jedis 3.5.x, Lettuce 5.3.x in both sync and async forms, ElasticSearch Client 7.x and above in sync and async, Mongodb Client 4.0.x and above in sync and async, Motan, Dubbo, and SofaRpc 5.3.0 and above. Access log collection covers HTTP Servlet, HTTP Filter and Spring Cloud Gateway. The stated focus is Spring Boot development environments, but the README says users can support any Java ecosystem applications through plugins. So the honest summary is that coverage is broad for Spring Boot and the common JVM clients, and thin for anything outside that list unless someone writes a plugin.

Standard formats on the reporting side

The output side is where a tool like this either saves you a migration or creates one. EaseAgent states that the tracing data format is fully compatible with the Zipkin data format, that the metric data format fully supports integration with Prometheus, and that the application log format is fully compatible with the OpenTelemetry data format. The data reports themselves come in five shapes: a console reporter, Prometheus exports, an HTTP reporter, a Kafka reporter and a custom reporter. That last one is how the Cloud-Native and service mesh story works, since a service mesh control plane wants to receive the data over its own protocol. The plugin model also covers scenario-specific business requirements, with traffic redirection and traffic coloring given as the examples, which are control plane operations rather than observability operations. A caveat worth holding onto is the trace format: Zipkin compatibility means existing Zipkin backends work, but a shop that has standardised on OTLP endpoints needs to check what EaseAgent actually speaks.

Installing the jar and setting the agent path

Setup is a matter of putting the agent jar somewhere and telling the JVM where it is. You set an environment variable and then either download `easeagent.jar` from the releases page or build it yourself.

$ cd ~/easeagent #[Replace with agent path]
$ export EASE_AGENT_PATH=`pwd` # export EASE_AGENT_PATH=[Replace with agent path]
$ mkdir plugins

The download is a single curl.

$ curl -Lk https://github.com/megaease/easeagent/releases/latest/download/easeagent.jar -O

Building from source needs Java 1.8 or newer and git, and the Maven build skips the tests.

$ cd easeagent
$ mvn clean package -Dmaven.test.skip
$ cp ./build/target/easeagent-dep.jar $EASE_AGENT_PATH/easeagent.jar

The `easeagent-dep.jar` is the agent jar with all the dependencies bundled, which is the one you copy into the agent path. The `plugins` directory you created in the first step is where plugin jars are dropped, which is the extension point the whole plugin mechanism hangs off. There is one platform wrinkle, and it is a Windows one: git `core.autocrlf` should be set to false before cloning, and the README points at `git config --global core.autocrlf false` to change it.

What the repository layout says about the scope

The top-level directories describe the shape of the codebase. There is `core`, which holds the plugin framework, `loader`, which is the agent bootstrap, `plugin-api`, which is the public extension contract, and `plugins`, which is where the built-in instrumentation lives. Then there are the data path directories: `metrics` for the metric API and registry, `zipkin` for the tracing implementation, `report` for the reporters, `log4j2` for the log side, and `httpserver` for the agent info, health check and readiness check endpoints. `config` holds the configuration file, `context` the context and settings plumbing, `resources` the packaged defaults, `mock` for testing, `build` for the Maven build, and `release` for release artefacts. The presence of a dedicated `mock` module and a `test` area suggests the instrumentation is exercised against simulated services rather than only against real ones. The licence is Apache 2.0, and the repository has a `CODE_OF_CONDUCT.md` and a `.licenserc.yaml` for automated licence header checks. It also ships an `AOSP-Checkstyles.xml`, which is a slightly unusual choice and tells you the code follows Android Open Source Project style rules.

Maintenance pace, and the gap between the versions

The release history is the thing to weigh. The listed versions are v2.2.8 in September 2023, v2.2.9 in June 2025 and v2.3.0 in August 2025, and the last push to the repository was on 2026-04-14, which is more than six months before today. So the tree has seen work after v2.3.0 that is not in a tagged release, and there is a visible gap between v2.2.8 and v2.2.9 of nearly two years. The architecture image is labelled for version 2.0, and the documentation refers to the 2.0 architecture, so the version numbers in the repo and the version numbers in the docs do not line up exactly. The README points at a user manual, an enhancement plugin development guide and a report plugin development guide, and the project is explicitly designed for extension, creating a plugin being described as a matter of as few as three classes with a simple and clear plugin interface. Whether that promise is still easy to keep depends on how much the APIs have moved, and the repository does not include a compatibility statement in what has been published.

Editorial conclusion

Adopt EaseAgent if you run Spring Boot services and need distributed tracing and metrics without touching application code, and you can run a Kafka or Prometheus stack to receive the output. Skip it if you have standardised on the OpenTelemetry Java agent, since EaseAgent writes Zipkin-format traces and its own log format, or if you cannot accept a bytecode-instrumenting agent in production. Before you commit, check the last push date of 2026-04-14 against your roadmap, and verify that the specific libraries your services use are in the supported instrumentation list rather than assuming coverage.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. megaease/easeagent on GitHub
4. README
5. Releases