It can be important to test the Alarms before real issues occur in production. This can be done to ensure that all configured Alarm Handlers are working as expected. This could include verifying that incident management systems receive the alerts, or that emails are properly received by the people who should receive them.
On the Alarm Handler page there is an option to trigger a test alarm:
Fig. 16 Trigger a test alarm
This opens a dialog where an alarm can be triggered. It is also possible to configure exactly what type of alarm should be sent. If a real resource is selected, the alarm will contain a proper impact analysis for that resource.
Fig. 17 Trigger a test alarm options
The last toggle in the advanced section Update Admin Node Alarm List indicates if the alarm should show up in the UI. If this is not selected then the alarm will only be sent to the alarm handlers.
Fig. 18 A test alarm
Test alarms are clearly marked with Test both in the UI and in the title of the alarm, so that it’s possible to distinguish these alarms from regular alarms.
Many deployments don’t have the Admin Web UI enabled in production. In that case the CLI is a good alternative to trigger these tests. The same parameters can be used inside the CLI
admin@localhost> request environments environment alarms trigger-self-test-alarm \ alarm-type failed-communication resource-type data-source\ resource-id myDb severity major update-admin-node-alarm-list true
The CLI has an additional advantage in that it can be used from any node. This means that it is possible to trigger a test alarm from any node in the cluster, which can be important if the runtime nodes are deployed in different networks.
By default the test alarm is triggered from the node that calls the alarms trigger. When using the Admin Web UI the alarm originates from the admin node, but when using the CLI it can be any node.
The alarms.log file in the $IDSVR_HOME/var/log directory can be read to ensure that the alarm was triggered properly.
alarms.log
$IDSVR_HOME/var/log