InfoScale™ Cluster Server 9.0 Bundled Agents Reference Guide - AIX
- Introducing bundled agents
- Storage agents
- DiskGroup agent
- Notes for DiskGroup agent
- Sample configurations for DiskGroup agent
- DiskGroupSnap agent
- Notes for DiskGroupSnap agent
- Sample configurations for DiskGroupSnap agent
- Volume agent
- VolumeSet agent
- Sample configurations for VolumeSet agent
- LVMVG agent
- Notes for LVMVG agent
- Mount agent
- Sample configurations for Mount agent
- SFCache agent
- Network agents
- About the network agents
- IP agent
- NIC agent
- IPMultiNIC agent
- MultiNICA agent
- About the IPMultiNICB and MultiNICB agents
- IPMultiNICB agent
- Sample configurations for IPMultiNICB agent
- MultiNICB agent
- Sample configurations for MultiNICB agent
- DNS agent
- Agent notes for DNS agent
- About using the VCS DNS agent on UNIX with a secure Windows DNS server
- Sample configurations for DNS agent
- File share agents
- NFS agent
- NFSRestart agent
- Share agent
- About the Samba agents
- Notes for configuring the Samba agents
- SambaServer agent
- SambaShare agent
- NetBios agent
- Service and application agents
- Apache HTTP server agent
- Application agent
- Notes for Application agent
- Sample configurations for Application agent
- CoordPoint agent
- LPAR agent
- Notes for LPAR agent
- MemCPUAllocator agent
- MemCPUAllocator agent notes
- Process agent
- Usage notes for Process agent
- Sample configurations for Process agent
- ProcessOnOnly agent
- RestServer agent
- WPAR agent
- Infrastructure and support agents
- Testing agents
- Replication agents
Level two monitoring through MonitorProgram
MonitorProgram can be executed as a second level monitor whereas PidFiles/MonitorProcesses are monitored as first level monitor. To enable level two monitoring for the Application agent, the LevelTwoMonitorFreq attribute of Application type has to be set to a value greater than zero. When configured, the MonitorProgram is executed in monitoring cycles at intervals specified in LevelTwoMonitorFreq attribute.
For example, if j is the value of the MonitorFreq key of the IMF attribute and k is the value of the LevelTwoMonitorFreq attribute, and if the resource is in online state, then traditional monitors for PidFiles/MonitorProcesses run in every j-th monitor cycle and MonitorProgram runs in every k-th monitor cycle.
When MonitorProgram runs as a second level monitor by setting the LevelTwoMonitorFreq value, the limitation of Application agent to leverage IMF for monitoring PidFiles/MonitorProcesses when resource is in online state is overcome. The processes configured in PidFiles/MonitorProcesses are then registered for IMF monitoring.
If the LevelTwoMonitorFreq attribute is set to zero and when MonitorProgram is configured, then none of the processes specified in PidFiles/MonitorProcesses are registered with IMF for monitoring when the resource is online. In this case, MonitorProgram and the checks for PidFiles and MonitorProcesses execute in every monitor cycle.
LevelTwoMonitorFreq is a type-level attribute. The default value for the LevelTwoMonitorFreq attribute is one (1) so by default MonitorProgram runs as a second level monitor in every monitor cycle. Any changes to this attribute at the Application type level changes the behavior for all application resources.
To modify the LevelTwoMonitorFreq value at type level to a non-default value (for example, 3), execute the following command:
# hatype - modify Application LevelTwoMonitorFreq 3
If you want to change the LevelTwoMonitorFreq value for selected resources, execute the following commands for each resource in the following sequence. Note that the LevelTwoMonitorFreq value used in the command is only an example.
# hares - override app_res_name LevelTwoMonitorFreq
# hares - modify app_res_name LevelTwoMonitorFreq 3
The preceding commands override the LevelTwoMonitorFreq attribute at resource level and modify the value of the attribute for a particular resource.