The following agent was designed for a company to put applications under VCS control (OS Win2003). Though I could have used the existing Service resource type, I decided to write an own agent to perform some kind of secondary monitoring. I called the new type "ServiceExt" which stands for "Service resource type, extended".
Four configurable monitor procedures are implemented:
1. Check for the service state: psservice query <Service> (ServiceExt.pm, line 332)
2. Check for running processes: ps -eo pid,comm (ServiceExt.pm, line 359)
3. Optionally check if specified network ports are open: netstat -a (monitor.pl, line 160)
4. Optionally issue application accessing commands and match their outputs to defined Perl patterns (monitor.pl, lines 211-372)
As you can see, Windows ps tools were added to the OS in order to execute command based service and process monitoring.
Network port checking (monitor procedure 3) was implemented due to occasionally closed ports in the company network (nobody knew the reason). Procedure 4 is quite flexible: The agent's "output" subfolder stores manually created files containing the regular command output or only parts of that output. The actual command outputs are compared to them using Perl pattern matching.
Here is the list of agent files:
monitor.pl: The monitor entrypoint
online.pl: The online entrypoint
offline.pl: The offline entrypoint
clean.pl: The clean entrypoint
ServiceExt.pm: A Perl module contaning basic functions
ServiceExt.dll: The agent binary itself
ServiceExt.xml: The agent description loaded by the Java console
VRTSvcsW2KServiceExt.bmc: The Binary Message Catalog (mapped into HAD.bmcmap)
ServiceExt.cf: The Resource Type configuration file
The following Resource attributes may be defined:
ServiceList [string/association]: List of services to be controlled (keys) together with their relating processes (values)
PortMonitorRatio [integer/scalar]: Ratio of network port monitoring in monitor cycles (0 = disabled)
PortList [integer/vector]: List of network ports to be monitored
AccessMonitorRatio [integer/scalar]: Ratio of application access monitoring by commands in monitor cycles (0 = disabled)
AccessList [string/association]: List of application accessing commands (keys) together with their output definition files (values)
OnlineMonitorDelay [integer/scalar, default 0]: Delay for confirming monitor after online entrypoint
OfflineMonitorDelay [integer/scalar, default 0]: Delay for confirming monitor after offline entrypoint
The VCS agent framework does not distinguish the resource's state context when monitoring. Since my resource type (compare VCS database agents) is capable to control more than one service, process, port or application access by only one configured resource (required for resource restart purposes), the physical counterpart of the resource can be completely online, partially online or completely offline. VCS agents normally focus on the "completely online" state in order to detect any application damage (online context). But after an only partially successful offline entrypoint (offline context), monitor should detect that the resource is still not completely offline to prevent a servicegroup failover. Therefore my monitor entrypoint first checks for the current context by evaluating the resource's State and IState attributes (described in more detail in monitor.pl, lines 28-57).
PrivDoz. Dr. Albrecht Scriba