→ deutsche Version

We are currently working on a check that monitors AutoSupport events, i.e. a check that sends an alarm if a AutoSupport message could not be created or sent. The last 50 ASUP events are polled and an alarm is triggered for any message with a failed status (transmission failed oder collection failed).

Here’s an example how the output could look like:

./check_netapp_asup.pl -H sim91
NETAPP_ASUP CRITICAL - 30 asup-messages checked, 7 critical and 0 warning
sim91-01 msg 7: transmission_failed MANAGEMENT_LOG (CRITICAL)
sim91-01 msg 7: transmission_failed MANAGEMENT_LOG (CRITICAL)
sim91-01 msg 7: transmission_failed MANAGEMENT_LOG (CRITICAL)
sim91-01 msg 6: transmission_failed MANAGEMENT_LOG (CRITICAL)
sim91-01 msg 5: transmission_failed MANAGEMENT_LOG (CRITICAL)
sim91-01 msg 4: transmission_failed WEEKLY_LOG (CRITICAL)
sim91-01 msg 3: transmission_failed MANAGEMENT_LOG (CRITICAL)
sim91-01 msg 16: re_queued REBOOT (after giveback)
sim91-01 msg 17: queued PERFORMANCE SNAPSHOT
sim91-01 msg 15: queued MANAGEMENT_LOG
sim91-01 msg 15: queued MANAGEMENT_LOG
sim91-01 msg 15: queued MANAGEMENT_LOG
sim91-01 msg 17: ignore PERFORMANCE SNAPSHOT
sim91-01 msg 17: ignore PERFORMANCE SNAPSHOT
sim91-01 msg 16: ignore REBOOT (after giveback)
sim91-01 msg 16: ignore REBOOT (after giveback)
sim91-01 msg 6: ignore MANAGEMENT_LOG
sim91-01 msg 6: ignore MANAGEMENT_LOG
sim91-01 msg 5: ignore MANAGEMENT_LOG
sim91-01 msg 5: ignore MANAGEMENT_LOG
sim91-01 msg 4: ignore WEEKLY_LOG
sim91-01 msg 4: ignore WEEKLY_LOG
sim91-01 msg 3: ignore MANAGEMENT_LOG
sim91-01 msg 3: ignore MANAGEMENT_LOG
sim91-01 msg 2: ignore PERFORMANCE SNAPSHOT
sim91-01 msg 2: ignore PERFORMANCE SNAPSHOT
sim91-01 msg 2: ignore PERFORMANCE SNAPSHOT
sim91-01 msg 1: ignore REBOOT (after giveback)
sim91-01 msg 1: ignore REBOOT (after giveback)
sim91-01 msg 1: ignore REBOOT (after giveback)

This check was designed as a standalone check since using the store for caching has no real benefit. As such it is faster and uses fewer resources on the monitoring system. In case you were wondering, the API has a set limit of maximum 50 events that can be monitored at once.

As always, we appreciate any feedback that you might have on our plans for this check. Please leave a comment below or send us an email: developer@rfi.net. In any case, a runnable version of this check will be included in the next testing release.