Glowroot Java APM: Embedded and Central Monitoring

Glowroot's Java Instrumentation and Intended Users

Glowroot addresses the need to understand latency and failures inside Java applications without requiring application code to emit telemetry. The project is positioned as a Java APM agent that attaches to a JVM, captures selected execution details, stores them, and presents them through its own UI. Its documented audience includes developers working with a single application, small installations, and organizations operating many application JVMs that need a shared monitoring service.

The agent targets slow requests and errors. It also supports continuous profiling, flame graphs, response-time breakdowns, percentile charts, SQL and service-call aggregation, MBean attributes, alerts, historical rollups, and asynchronous requests that span several threads. Those features place Glowroot closer to an observability agent than to a simple log viewer. It is intended to answer questions about where time is spent and which execution paths are responsible for failures or slow responses.

Glowroot does not require application instrumentation calls in the documented quick-start path. Its main entry point is the `-javaagent` option, which loads `glowroot.jar` into the JVM before an executable JAR starts. That approach makes it relevant to teams that want broad JVM-level visibility without editing every controller or service class. However, the documented instrumentation coverage still matters. The README refers readers to dedicated feature and instrumentation pages, which signals that automatic capture depends on covered libraries, frameworks, and extension points.

The repository is not archived, and its last push was on 2026-10-04. That is a current development signal by the repository's recorded activity, although it does not by itself establish production support or compatibility with every application stack.

Embedded Agent, H2 Storage, and Local UI

The default deployment combines the agent, an H2 collector, and the UI in the application JVM. This is the simplest topology because an operator downloads one distribution, adds one JVM argument, starts the application, and opens a local web interface. The README identifies embedded mode as appropriate for a single application, development, and small installations.

The data path is local in this mode. The Java agent observes the instrumented application, an embedded collector receives the captured information, H2 holds the resulting data, and the UI serves the visualizations from the same environment. The README states that the UI listens on `http://localhost:4000`. It also tells users to wait for a line beginning with `UI listening on …` in the agent log before opening that address.

The embedded mode has an important operational consequence. Monitoring is tied to the monitored JVM rather than separated into an independent service. The application process must have a writable Glowroot folder because the JVM user needs permission to write there. This is convenient for development, but it also means access controls, disk usage, retention, and monitoring availability belong to the same deployment boundary as the application.

The README explicitly says that embedded JSON or H2 storage is not a substitute for the central deployment. It should therefore be treated as a deliberate small-scale architecture, not as a feature-poor version of the shared collector. The absence of an agent configuration step in the quick start does not mean that all production settings are automatic. Post-install configuration is delegated to the linked embedded collector installation guide.

Starting an Embedded Glowroot JVM

The shortest documented first use begins with the latest stable agent distribution from GitHub Releases. The distribution is named `glowroot-*-dist.zip`; download and unzip it into a location accessible to the account that starts the JVM.

Add the agent argument to the application's JVM arguments. If the application uses an executable JAR, the README requires the agent argument to appear before `-jar`. The documented argument is:

-javaagent:path/to/glowroot.jar

This is a JVM option, not a complete application launch line. The README does not supply a full `java` command, so there is no confirmed executable-JAR name or application argument set to combine with it. The application must also be able to write to the Glowroot folder under the same operating-system user that runs the JVM.

Start the application through its existing launcher or application-server configuration, then inspect the agent log for a line beginning with `UI listening on …`. Once that line appears, open:

http://localhost:4000

At that point, the first useful verification is to exercise application behavior that Glowroot documents as captured, such as a slow request, an error, SQL work, a service call, or a profiled code path. The UI should then be used to inspect the corresponding transaction, timing breakdown, profile, or aggregated service data. The README does not define a synthetic request or a required sample workload, so it would be wrong to prescribe one as a validation command.

Central Collector and Cassandra for Shared Monitoring

The central architecture separates monitoring infrastructure from application JVMs. Each application runs the Glowroot agent, while a `glowroot-central` process and Cassandra run on a monitoring host. The agents send their captured data to the central service, which provides the shared UI and storage intended for many agents and longer retention.

This topology changes several engineering responsibilities. Embedded mode requires a writable Glowroot directory in the application environment and keeps its H2 collector in that JVM. Central mode requires a separately installed collector and Cassandra, plus the network path between application hosts and the monitoring host. It also changes the operational owner: a team or platform group must deploy and maintain the monitoring service rather than treating it only as an application directory.

The README requires Java 17 or newer for `glowroot-central`, while the agent itself requires Java 8 or newer. That split matters when evaluating an existing platform. An application fleet on Java 8 may still be able to attach the agent, but the shared collector has a separate runtime requirement.

Compared with an external APM platform, Glowroot's documented central option keeps the collection architecture visible: Java agents, a Glowroot central collector, and Cassandra. The repository does not identify or compare a named competing APM product, so claims about another vendor's storage model, setup, licensing, or capabilities cannot be verified from the project documentation. The concrete Glowroot alternative is embedded H2 versus central collector plus Cassandra, with the former favoring local simplicity and the latter favoring shared service operation.

Coverage Gaps and Operational Boundaries

Glowroot's broad feature list does not imply that every Java library is instrumented equally. The README links to `Plugin coverage gaps` and `What Glowroot does not do`, both of which indicate known boundaries around queries, service calls, and web instrumentation. Before selecting Glowroot for a particular application, engineers need to compare the application's frameworks and libraries against the documented instrumentation coverage. Automatic attachment does not remove the need to confirm that a particular execution path is observed.

The embedded deployment also has a clear failure boundary. If the JVM user cannot write to the Glowroot folder, the agent may not have the filesystem access required for its installation and local operation. If the application does not emit the expected log line, the README directs users to wait for `UI listening on …`, so opening `http://localhost:4000` too early is not a valid installation check. The linked troubleshooting guide exists because startup and environment problems are recognized operational cases.

Continuous profiling introduces a separate consideration from request tracing. Glowroot documents filtered profiling and flame graphs, but it does not establish in the README how much profiling data should be retained, how filters should be designed for a specific workload, or what profiling policy fits production. Those decisions require the feature and administration documentation rather than inference from the existence of profiling support.

There is also no documented rollback procedure in the README. It provides upgrade notes for version 0.14.8, including health endpoint changes, and a separate guide for the embedded H2 1.x to 2.x transition. Those documents point to migration boundaries that should be reviewed before changing versions; the README does not promise that every upgrade can be reversed through a single command.

Release Cadence, Upgrades, and Apache-2.0 Terms

The repository is not archived, and its last push was on 2026-10-04. Recent releases include `v0.14.8-beta.3` on 2026-06-08, `v0.14.8-beta.4` on 2026-08-02, and `v0.14.8-beta.5` on 2026-09-08. The labels identify these artifacts as beta releases, so the release list should not be treated as evidence that every 0.14.8 build is intended for production use.

Upgrade planning has project-specific documentation. The README points to `docs/health-endpoints.md` and `docs/0.14.8-upgrade-notes.md` for the HTTP `/health` and `/readiness` behavior in 0.14.8 and later. It separately points to `docs/embedded-h2-upgrade.md` for the embedded H2 1.x to 2.x upgrade. These are concrete files to inspect before enabling automated deployment or changing an existing embedded installation.

The project is licensed under Apache-2.0, as shown by the license badge, repository `LICENSE` file, and project metadata. That license governs the project's terms, but it does not replace an organization’s review of dependencies, plugins, deployment artifacts, or internal policies. Glowroot also has plugins and custom instrumentation. A team using those extensions should account for their compatibility and maintenance separately; the README does not promise that all third-party plugins follow Glowroot's release schedule.

The main upgrade cost is therefore not limited to replacing the agent JAR. Operators must determine whether the application uses embedded or central storage, check the applicable upgrade notes, preserve access to the agent directory, and validate the UI after restart. Central installations add collector and Cassandra coordination to that checklist.

Editorial conclusion

Glowroot is a practical choice for Java teams that want application traces and profiling attached directly to the JVM. It is a poor fit for operators that cannot permit agent writes, do not want an APM data store in the application environment, or need a deployment without an identified owner. Verify the chosen distribution, storage mode, Java version, writable directory, supported instrumentation, and the scope of any upgrade changes before adoption.

Frequently asked questions

Official sources

1. glowroot/glowroot on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases