In the last post, we've looked at how we can simply extend the ICIM model by adding new properties to existing classes. In this post, we'll go one step further and look at what we can do to take advantage of the events functionality and generate notifications in Smarts.
The objective
Monitor applications with synthetic transactions and depending on the response time, create a notification that states either the application is slow (degraded) or down.
The model changes
We will extend the ICIM_LogicalElement class since it seems to be appropriate for an application. There may be a more appropriate class but this one will do. First, the properties we need to use in monitoring:
interface MyApplication : ICIM_LogicalElement
"Instrumentation class used to monitor status of an application."
{
attribute int degradedThreshold "if the response takes longer than this number of seconds the application is considered degraded" = 0;
attribute int downThreshold "if the application does not respond in this number of seconds, it is considered down" = 0;
attribute int lastResponseTime "number of seconds application has responded in" = 0;
}
We have two thresholds and the actual response time. We want to create a notification stating the application is slow, if the response time is over the degradedThreshold and a different notification if the application does not respond within the time frame we specify in the downThreshold . Basic stuff. We need to define “events” in the model to accomplish this:
computed attribute boolean isDegraded
"set to true if the application has performance issues (Degraded)"
= lastResponseTime > degradedThreshold;
event Degraded "The application seems to be down"
= isDegraded;
export Degraded;computed attribute boolean isDown
"set to true if the application is not responding (Down)"
= lastResponseTime == -1
event Down "The application seems to be down"
= isDown;
export Down;
In the first section, we define a new boolean property isDegraded and set its value to true, if the lastResponseTime is bigger than the degradedThreshold (means our application performance is not as it should be). If isDegraded is set to true, an event Degraded is created and exported. In the second section, similarly, we generate a Down event if lastResponseTime is set to -1 (which we would do if the application does not respond in time frame specified in downThreshold).
Configuration changes
To be able to see the notifications in the Smarts Global console, couple of configuration changes are needed. Dxa file (configuration file used to specify which objects and properties are sent to from underlying servers to SAM server) needs to be modified to forward MyApplication class and its properties to SAM server and subscribe to the events on MyApplication class. The following may be added to the dxa files:
...
class MyApplication
attr Name
attr isDown
attr isDegraded
attr lastResponseTime
...sub MyApplication::.*::.*/e
...
The “Dynamic Modeling Tutorial” document (it's under lock and key; you can get it if you have a EMC Powerlink account) has information on what configuration changes need to be made.
Let's see it working
We can now compile the model, restart the servers and already see it working by setting values of the properties via dmctl commands. First, we will create a new application object (via dmctl) and set the initial property values.
create MyApplication::MyApp1
put MyApplication::MyApp1::degradedThreshold 80
put MyApplication::MyApp1::downThreshold 100
put MyApplication::MyApp1::lastResponseTime 50
At this time, there is no notification since the response time is OK. Now we can set the response time to 80 and expect a degraded notification.
If the response time is set to -1 (meaning we did not get a response in 100 seconds), the Degraded notification is cleared and a Down notification is created instead.
If the response time is set to lower than the degraded threshold, the Down notification would also be cleared.
So we now have a class in Smarts we can use to perform generate notifications for applications. We don't yet have something to actually monitor the application response times, but it's important to emphasize that we now have the infrastructure and it's decoupled from how we determine the response time. This allows us to use any tool we may have to monitor our applications and integrate it naturally with Smarts. The response time information can come from a third party monitoring solution or we can write scripts, etc. and set the properties of the MyApplication class. This method is superior to typical trap processing integration mechanism for a number of reasons, and it is more inline with the Smarts philosophy of monitoring.
In the next post, I'll go through how to use the relationships and the propagate command to correlate the host events with the application events.
