The very useful --rm_ack=… parameter lets us decide how to deal with the posibility to remove a service acknowledgement in case of a reason-change. The optional arguments supplied until now have included ignore, always, never and reason-change, with the latter being the default. This parameter now has an …
An exciting feature release for check_netapp_pro is the new --rm_ack_handler parameter, which enables users to construct their own method to reset remote service acknowledgements for checks which have failed. This is not a matter of checking what has failed, but a way to manage the acknowledgements of what has failed; …
One of the most innovative features of check_netapp_pro is probably the option -rm_ack, which solves the problem of errors not being alarmed for confirmed overall checks. These errors will not be alarmed actively and can therefore be easily overlooked. This switch might soon be replaced by another, more sophisticated …
One of our customers came up with an interesting idea: simple checks, such as **check_netapp_health, **could be extended with ability to recognize a change in cause, a feature usually found in multi-instance checks. For multi-instance checks that are not OK, rm_ack investigates if a change of cause for the not-OK …
The abbreviation rm_ack stands for remove service acknowledgement, which refers to a rather simple algorithm that can be used to identify masked alarms. Masked alarms are a phenomenon that solely appears with checks on multiple instances, such as the simultaneous checking of all volumes on a NetApp device. In a …