Glassbox Troubleshooter speeds resolution of problems that matter to business by automating their diagnosis.
It has built-in knowledge of a set of common problems and can spot them as Java code executes in the application
server or another JVM process.
Any search is easier when you know what you’re looking for, so Glassbox’s problem-focused design provides
powerful advantages over manual diagnostic tools. Glassbox describes problems precisely and clearly in plain
English, rather than presenting views of data and leaving the user to make sense of it. It makes diagnosis
easier for technical experts and possible for everyone else.
Clear problem descriptions cut through the miscommunication that usually impedes problem resolution. Teams
no longer need to communicate a clutter of symptoms and rumors of reproduction steps, nor attempt to assign
ownership based on conjecture and finger-pointing. With a clear description of the problem and the stack
trace where it happens, handoffs become fact-based conversations, and symptom analysis becomes unnecessary.
Problem-focused design also means Glassbox must collect dramatically less data—only enough to perform its
diagnosis, not to support more general analysis. So it has a negligible impact on system performance and
can be used on production applications. That also means it can use a lighter storage architecture, which
keeps administration burden and hardware requirements down.
Monitoring Java code via Aspect Oriented Programming
Glassbox monitors your application through the Java virtual machine (JVM), which gives it a top-down view
of the application’s activity and allows it to infer problems in other processes. JDBC activity in the app
server, for example, will reveal how well the database is responding.
The interface to the JVM doesn’t involve byte code instrumentation of your production code but is done via
aspect-oriented programming (AOP), a standards-based technology for combining separately-developed Java
modules at load time. AOP instrumentation happens at class load time (or, if you prefer, at compile time).
Glassbox requires no changes to your source code or build process, so it can work with legacy .jar files.
Diagram: Enterprise Java Server monitored by Glassbox. Click diagram or enlarge
Glassbox Inspector and Glassbox Troubleshooter
As the diagram indicates, the open-source Glassbox Inspector monitors JVM activity via AOP and exposes
it via a JMX interface interface, suitable for viewing on any JMX console.
The Glassbox Troubleshooter interacts with the Glassbox Inspector to analyze the data being collected,
diagnose problems, and report them through its specialized client UI.
How does Glassbox Work?
Glassbox Troubleshooter exists in three technical layers:
What does your technology mean for the customer?
- Glassbox Monitor: AOP based monitor which lives beside your Application Server code in the Java Virtual Machine
- Glassbox Diagnosics: Diagnostic layer which analyses the raw monitor logs and output into solutions
and then cross-references those solutions with the knowledge base of known failures.
- Glassbox Client: Presentation and display variations, has a many to many relationship with the Glassbox diagnostics.
It means Glassbox has a light footprint on
your application server, installs easily, and provides conclusions instead of raw data.
How is Glassbox installed and run?
- Glassbox does not require you to change your source code or embed anything.
- Monitors out of the box by using Aspect-Oriented Programming to learn your application, no configuration or touching your source code needed.
- The technology is designed to be low risk, to be stable on production systems, and it monitors itself to prevent it from causing problems in the monitored application.
- Safe, only standards based monitoring, no custom byte-code manipulation like previous generations of troubleshooting vendors.
Install and start monitoring in 4 easy steps:
- Drop the Glassbox files into application server directories
- Configure your environment variables to locate and run Glassbox automatically when your application server starts.
- Re-start your application and run some sample functionality you want monitored.
- Start the Glassbox client and find out what is broken in your application
For some highly technical examples of how we use AOP for monitoring Java, please see
of articles written by our CTO, Ron Bodkin. They include great code samples and really
delve into the code level details.