Creating a Monitor | JBoss: A Developers Notebook

A snapshot is good for collecting information about one aspect of your server over time, to gain an understanding of your server's behavior, and to find anomalies. However, when you are looking for a specific problem, you generally want to know about it as soon as that problem has occurred. Then you can go to a long-running snapshot and examine how the server behaved during the time leading up to the problem.

The Web Console gives you the ability to create an alert to monitor an MBean attribute value for a specific condition. When that condition is met, JBoss triggers a notification event to alert you to the condition. In this lab, you will create a monitor on the free memory of the JBoss application server.

How do I do that?

To create the alert, find the FreeMemory attribute of the jboss.system:type=ServerInfo MBean one more time and choose Create Monitor from the menu. The details section of the Web Console will contain the monitor creation form shown in Figure 8-8.

Developer's Notebook 8-8. Creating an alert

JBoss has filled in the MBean name and attribute name. The THReshold and Comparison Equation values determine the trigger for the event. Monitors are purely numeric and can be compared to any fixed value. This monitor will trigger an alert when free memory goes below 50,000,00, which is approximately 50MB. JBoss checks the monitor every Time Period milliseconds.

If the alert is triggered, JBoss will send an alert to the alert handlers selected in the Alerts select box. Right now only one alert handler is listed: Console Alert. It sends an alert message to the console log. You'll see some other alert options later.

Select the Persist Changes and Enable Monitor boxes to make sure the alert will be persisted and enabled before clicking the Create button.

You've created a monitor to generate an alert when free memory falls below a certain threshold, but where did the monitor go? All the monitors are listed in the Alerts section of the navigation pane. However, you may need to refresh the tree to see the Alerts section.

Note: Right-click the JBoss logo to refresh the tree.

When you select the Alerts node, you'll see a list of all active monitors. The list looks like that shown in Figure 8-9.

Developer's Notebook 8-9. The list of active monitors

The green OK status means the monitor has not yet triggered an alert.

To prove that our alert works, we need to force JBoss to trigger it. To do that, we need a way to consume lots of memory, driving the free memory below the 50MB threshold. We've created a simple JSP to do that:

     <%@ page import="java.util.*" %>             <h1> Memory Eater </h1>     <%! int count; %>     <%         try {            ArrayList list = new ArrayList(  );            while (true) {                list.add(new Object(  ));                 count++;            }                 } catch (Throwable t) {         }             %>             Created <%= count %> objects...

This JSP continually creates objects until memory runs so low that an exception is thrown. Copy this JSP directly into ROOT.war in the deploy/jbossweb-tomcat55.sar directory to make it available.

If you name the file memory.jsp, you can access it at http://localhost:8080/memory.jsp. When you access it, the server will spin for a while as it eats up memory. Unless you have a large amount of memory and a slow CPU, it shouldn't take more than about 15 seconds to deplete the free memory in the JVM. When the page finally loads, you should see that the alert shows up in your console log as expected:

Note: The console alert listener logs to the org.jboss.monitor.alerts. ConsoleAlertListener category.

     14:16:39,171 INFO  [ConsoleAlertListener] FreeMemoryMonitor was triggered     for attribute FreeMemory.

If you return to the list of monitors, you will see that the status has changed from a green OK to a red ALERT. If you click Manage, you'll see the monitor with the triggered Value filled in. This is the value at the time the threshold was exceeded. Figure 8-10 shows the value in this case.

Developer's Notebook 8-10. The monitor after it fires an alert

As you can see, the value was well below 50MB by the time JBoss noticed. The JSP was consuming memory very rapidly, and even though the monitor was very aggressive in checking the value every second, it didn't notice until the measure was well below the threshold.

Normally, the values you are monitoring won't change so rapidly, but you do need to be careful to pick a time period for the monitor that is likely to pick up the change. If we monitored free memory every minute, the event may have come and gone by the time JBoss checked the value again, and you would have missed the event.

What just happened?

You created a monitor and triggered an alert using the Web Console. There's not much more to say, but we should point out that once a monitor has issued an alert, it remains in that state until you clear it. The Clear Alert button clears the alert and restarts the monitor.