→ English Version

Derzeit arbeiten wir an einem Check zur Prüfung von Autosupport-Events, konkret also einem Check der alarmiert, wenn das Versenden oder schon das Erstellen einer Autosupport-Nachricht fehlgeschlagen sein sollte. Abgefragt werden die jeweils letzten 50 ASUP-Events und alarmiert wird immer dann, wenn eine Nachricht mit einem failed status (transmission failed oder collection failed) aufscheint.

Folgend ein Beispiel, wie die Ausgabe aussehen kann:

./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)

Dieser Check wurde als stand-alone Check konzipiert da die Zwischenspeicherung in einem Store keinen Mehrwert ergeben würde.  Als direkter, stand-alone Check ist er schneller und spart Ressourcen am Monitoring System. Die Anzahl von 50 maximal überprüfbaren Events ist übrigens durch die API vorgegeben.

Rückmeldungen zum aktuellen Planungsstand dieses Checks sind wie immer sehr willkommen. Kommentieren Sie dazu diesen Artikel oder schreiben Sie an developer@rfi.net. Jedenfalls wird er in einem der nächsten Testingreleases auch in einer lauffähigen Version erscheinen.