Joe Rogers article Yeah, there’s a module for that showed how easy it is to create your own module with the Module Builder. If like me you don't want to be trawling through loads of alerts and doing root cause analysis, you'll probably want to have an automation layer between you and the monitoring software filtering out the noise and only alerting you when necessary and with extra supporting analysis completed. From an automation perspective, having a pre-existing module to interact with an application is a great head start to have, allowing the Automation software interact with the Monitoring software as designed. But how about this scenario - you are just after creating your own module with Module Builder - how are you going to get the Automation software, in this case NetIQ Aegis, to perform automation tasks using this custom module?
To find out, I decided to build my old module using the Module Builder to monitor NetIQ Access Manager. This is a 2 part story, part 1 is my experience with configuring module builder in AppManager, and part 2 detecting and correcting a service down condition with Aegis.
Part 1: Configuring Module Builder
So on my Access Manager machine, I ran the module installer wizard. All I did was select Access Manger from the list of installed applications (also option to find an app if not listed) and it automatically found Processes, Services and LogFiles relating to the application.
I selected Expert Mode just to generate the module (ignoring the temptation to get into tailoring my monitoring), and it generated 4 Knowledge Scripts, a module discovery script and Knowledge scripts to monitor the Access Manager Processes, Services and Log Files. I imported them into AppManager in the usual way, ran the discovery KS and set off the monitoring using the defaults. That was pretty easy!
So onto Part 2, where the real heavy lifting will occur!
Part 2: Configuring Aegis
I started off by stopping the Tomcat service on the Access Manager machine to simulate a system down, waited for an event to be generated in AppManager, and then went about finding out how to have Aegis detect the event and restart the service.
Now normally AppManager Events should be displayed in Aegis in the event view, so I took a look and found the corresponding event:
So the event shows up like all other AppManager Events. I get event IDs, source computer, KS name and other event attributes and locators I expect to find. This means I can trigger a workflow on the event as normal, but it also means I can run out of the box AppManager Knowedge scripts based on the attributes of the event to restart the service. On further inspection I found a second event telling me the service was shutdown normally - now that is probably a scenario where I don't want to be notified - handle by trigger definition or the workflow. Hmmm .... end of Part 2.
Unfortunately this didn't turn out to be an epic technical document filled with clever scripts and exciting technical know how - but if you prefer an easy life then you can't really go wrong combining the powers of the Module Builder and Aegis.