To test that events are being sent, use the INITIAL option
available with conditional notification when creating a monitoring
request. This option sends an initial event that you can examine
to make sure your request is properly configured and showing up
in the correct system management tool.
An alternative is to use the "At each interval"
notification to test that events are being sent in the correct system
management tool. Once you establish that events are being sent properly,
you can modify the request.
Testing
Disk Monitor Requests |
 |
Configuring the INITIAL option may be enough. However, if
you want to test that events are sent when a disk fails, you may
want to detach the bus or power down the storage devices and see
if events are sent to the proper application, or if MC/ServiceGuard
fails over the appropriate package. This is only recommended on
clusters that are off-line, and not being accessed by users.
To test /vg/vgName/lv/copies and
/vg/vgName/lv/status, use the vgchange
command to deactivate and activate the volume group and see if the
proper alerts were sent.
Testing
Cluster Monitor Requests |
|
Use the cmviewcl -v command to display
detailed information about the current status of the cluster and
packages on the cluster. The EMS cluster monitor should return the
same values as this command.
Testing Network Monitor Requests |
|
If you want to test whether events are sent in case of network
failure, use the /usr/bin/ifconfig LANname down
command to bring a card down, and examine the event to make sure
it shows up in the correct system management tool.
Testing System Resource Monitor Requests |
|
Use the uptime command to verify the number of user and system
load. The EMS system resource monitor should return the sam values
as this command.
Making Sure Monitors are Running |
|
Monitor
daemons automatically start when you create a request to monitor
something. Because monitoring is designed to work in a high availability
environment, monitors are written to automatically restart if anything
causes them to fail.
A
daemon called p_client restarts all appropriate
monitors using the monitor restart interval defined in /etc/opt/resmon/config.
Therefore, a monitor cannot be permanently stopped or started by
a human.
Because the monitors are persistent, monitoring requests are
kept when you install a new monitor or update an existing monitor.
If a condition, such as "status > 3" is being
monitored for a resources that has a range of 1-7, and new version
of monitor is installed that supports a new status value, such as
"8", you may start seeing notifications for "status=8".
If
all monitors are running, you will see the following daemons:
- diskmond
if you are monitoring physical or logical volumes
- clustermond
if you are monitoring cluster or node status
- pkgmond
if you are monitoring MC/ServiceGuard package status
- lanmond
if you are monitoring network interfaces
- mibmond
if you are monitoring users or job queues
- fsmond
if you are monitoring available filesystem space
Clustermond, pkgmond, lanmond, mibmond, and fsmond are implemented
via a program called the MIB monitor. For the MIB monitor to function
correctly, the SNMP Master Agent and the appropriate subagents must
be running on the system being monitored. See snmpdm(1M)
for more information.
Printable version
