Automatic Diagnosis

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 here.

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:

1. Glassbox Monitor: AOP based monitor which lives beside your Application Server code in the Java Virtual Machine
2. 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.
3. Glassbox Client: Presentation and display variations, has a many to many relationship with the Glassbox diagnostics.

What does your technology mean for the customer? It means Glassbox has a light footprint on your application server, installs easily, and provides conclusions instead of raw data.

• 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.

How is Glassbox installed and run? Install and start monitoring in 4 easy steps:

1. Drop the Glassbox files into application server directories
2. Configure your environment variables to locate and run Glassbox automatically when your application server starts.
3. Re-start your application and run some sample functionality you want monitored.
4. 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 this series of articles written by our CTO, Ron Bodkin. They include great code samples and really delve into the code level details.