This blog post is the second installment in this series of blogs on the DevKit. In this blog post, I will provide you with deep insight into the event handling capabilities of DevKit. I strongly recommend that you go through the overview blog post as well as the additional references listed at the end of this blog for more information. I have also included a video in this blog post to aid your better understanding of this topic.
The DevKit works with the Perl programming language. So, the Event APIs are also in Perl. The Event APIs of the DevKit completely abstract you, as the developer, from the underlying product specific implementations. They provide you a generic and easy-to-use interface to handle the event generation logic.
Event APIs have the intelligence to detect standalone mode versus production run time mode and behave accordingly. In standalone development mode, the event APIs print the results of generated events to the console. In production run time mode, the event APIs automatically invoke the underlying product APIs resulting in actual event generation.
You can test the event logic using console output in the development mode and the seamless switchover ensures correct behavior in production run time. This allows you to implement the Event logic without worrying about the underlying product API implementations. This is the core idea behind the Event APIs.
You can classify events in OMi MP into two types:
Event messages triggered for abnormal/exception conditions like unreachable network interface, no permission to write to disk, and so on.
Event messages triggered for threshold violations when specific monitored metrics cross the predefined threshold value.
Event APIs of the DevKit support both of these use cases. Let me show you how to use the Event APIs—it is actually quite easy.
Sending events on encountering abnormal runtime or external conditions is addressed by a simple Event API implementation in the DevKit, (which is not surprisingly called event()). The event() API accepts a well-defined set of arguments. The best place to look for all the details around this is the OMi MP DevKit Developer Guide referenced at the end of this blog post. But, for a quick understanding see the following example:
As a developer, all you need to do is fill up a Perl Hash structure with the right set of fields and invoke the Event API with that Hash data structure as the argument. Can’t get simpler, right?
The event() API when running in the standalone developer mode prints the details of the event being generated to the console. You can test the event logic from the console output and certify the monitoring solution. Rest assured that a proper event will be sent to the OMi server during production run time.
It is a little different with threshold violation alerts, though. The DevKit provides APIs that combine the functionality of logging/storing the metrics and alerting on threshold violations. The DevKit supports metric logging of type “Counter”, “Gauge” and “String’. When logging metrics, the APIs also check whether a threshold value is defined for that particular metric. An alert it generated when the threshold value is exceeded.
The metric logging API takes a set of well-defined arguments, and once again the best place to refer to is the OMi Management Pack DevKit Developer Guide referenced at the end of this blog. But, for a quick understanding see the following example. As a developer, all you need to do is fill up a Perl data structure and invoke a simple Perl API.
The developer can define threshold violation related configuration using a simple YAML configuration file.
The examples depicted on the left side illustrate the type of threshold violation related fields that is available at the disposal of the developer.
I have made a video for you that explains the points we have discussed so far—but in a deeper and more exhaustive manner. It should help explain some of the unanswered questions in the blog. Check it out.
Don’t forget to review these related blog posts and documents for more information on the DevKit and on developing an OMi MP.