C2B2 logo icon

Getting the most out of WLDF Part 3: Notifications

Read Part 1: "What is the WLDF?" here
Read Part 2: "Watches" here

This blog directly follows on from part 2 on watches, so if you haven’t already read that then you should probably go and do that now.

You can still create notifications without having any watches configured; you just won’t receive anything on them.

In the last post, I had created two watches, one Server Log watch and one Collected Metrics watch. In this post, I will create notifications to work with these watches.

What are notifications?
WLDF notifications are nothing more than a particular configuration for alerting based on a condition. Think of them as channels of communication; unless something is sent down those channels, they will stay empty. The forms that these channels can take are:


  • SMTP Email
  • JMS Message
  • Diagnostic Image
  • JMX Notification
  • SNMP Trap


Which notification should I use?

There’s no right or wrong when it comes to choosingnotification methods, but there is certainly annoying and non-annoying! Of thenotification methods above, all but email are passive methods of alerting people concerned. The reason I classifythem as passive is that you, as the end-user who wants to be notified, mustperform some sort of action to consume that notification. For example, toconsume JMS message data, you must use a JMS client and would likely processthe data automatically, perhaps for graphing.
Email, in contrast, is an active method of alerting since the end user will be told when shegets a new email. The majority of smartphone equipped techy people will checktheir email because their phone has beeped at them, not because they weresimply curious. If you find yourself staring out of a rainy window wondering atwhat treasures your inbox might hold, you likely have bigger problems than configuringWLDF.

So which is best: active or passive?

Well you want to be ahead of the curve with what’s happeningin your environment, don’t you? So email it is! Decision made, then, off you goand configure WLDF to send emails for every time a watch is configured.

I’ll wait here.


How did that go down with your support team? Badly? Ithought so.
The problem with just using a single notification method forevery watch event is that you definitely want to be notified as soon as somecritical event occurs that requires action, but what if the event is onlymedium or low priority, or can be recovered from automatically? In those cases,you absolutely don’t care about every single event and often you’d like a lotof data to be graphed for you to review at a later date, which email iscertainly not built for.
As the signal to noise ratio goes down, you’ll find yoursupport users increasingly set up rules to ignore alerts and you find yourselfin the same position as before when something critical happens where no-onetakes any notice because they’re ignoring all your usage results.
I’ll outline two different notification types here, thoughthey are all straightforward to configure.

JMX Notification

To create your JMX notification, go to the diagnostic module where your watches are configured. In Configuration -> Watches and Notifications, click the “New” button in the Notifications tab in the lower pane. 

Next, there are just two steps. Select “JMX Notification” as the type, as shown in the image, then click Next to name your notification.

Enter a meaningful name in the name field and make sure the Enable Notification box is ticked. Click OK and your notification is created!

Email notification

In the same way as before, click the “New” button in the Notificationstab of the appropriate diagnostic module.
After selecting the type as SMTP email and giving ita meaningful name, click next to complete the final step
Choose the mail session you want to use, enter emailaddresses you want to alert with this notification and click finish.
If you haven’t already created a mail session, you can usethe button here to make one without losing your place. This is a blog aboutWLDF not Java mail, so I won’t go into that, but they are simple enough tobe described with a single page of documentation.

Using your notifications

Now you’ve created your notifications, you need to tell your watches to use them! In the screenshot below, I’ve opened my SocketsOpen watch from the last blog and moved across my JMX notification from “Available” to “Chosen”

That’s all there is to it! Obviously if you wanted to use the email notification, choose that instead or as well as the JMX notification.

It’s pretty obvious how the email notifications work – checkyour inbox. If you were to fire up JConsole to check your new MBean, however,you would find that you can’t access it. The reason for that is that you needto addthe right WebLogic jar to the classpath before you start JConsole.
To demonstrate the JMX notification working, I used a single Javaclass that I stumbled across, and modified slightly, from anOracle blog. Make sure to include weblogic.jar from the server/lib directory of your WebLogic installation in the classpath if running in the command line or the project build path as in my screenshot of Netbeans below:

What next?

Now you can create watches and notifications on WebLogic, you can configure a monitoring product like RHQ or Hyperic to monitor anything that you can configure a watch on; with JMX tools, this normally stops with MBeans, but thanks to watches you can also monitor server logs and instrument your applications!