The function get_counter() is now deprecated in the programming ofchecks. There is a new function called get_rate() that should beused as a replacement.
def get_rate(countername, this_time, this_val, allow_negative=False, onwrap=SKIP): ... return rate
The call syntax is almostthe same - just with the new optional parameteronwrap. Important however: now just the rate (counter stepsper second) is being returned. The formerly additional return valuetimedif has been dropped since it is of no real use. So the returntype has changed from tuple to float.
The most imporant change - however - is in the handling of counter wraps. Acounter wrap happens in three situations:
Wraps usually happen when a device reboots or when the valid range of thecounter is exceeded and it wraps through again to zero.
The old function get_counter() used to raise an exception of typeMKCounterWrapped. This exception was handeld by the main core ofCheck_MK, which skipped that check for one cycle. The problem were checkswith more than one counter: at the point of initialization the code of thecheck wasaborted after the first of these counters had been initialized.If you had 10 counters, you would need 10 check cycles until the first timea check result would be returned. So in order to avoid that the check hadto catch the MKCounterWrapped itself and handle this situation -very ugly.
The new function get_rate implements a different approach.Per default no exception is raised in case of a counter wrap, but simply thevalue 0.00 is being returned. But Check_MK keeps record of this wrapevent. After the check function has completed (and all counters are handled),Check_MK creates one final MKCounterWrapped exception, sothat the (invalid) check result is being skipped as it should be. This waythe check programmers' burden is a reduced a bit because now even if thecheck has several counters he does not need to catch counter wraps.
In order to give the check more flexibility there are two other behaviours,that can be selected by the optional argument onwrap:
Note: Using ZERO is generally not a good idea. This canmake a service jump from CRIT to OK from now and then and generate bogusnotifications.