Werk #6662: Timespecific check parameters: Changed computation algorithm to allow more flexible configurations
Component | Setup | ||||||||||||||
Title | Timespecific check parameters: Changed computation algorithm to allow more flexible configurations | ||||||||||||||
Date | Sep 24, 2018 | ||||||||||||||
Level | Prominent Change | ||||||||||||||
Class | New Feature | ||||||||||||||
Compatibility | Incompatible - Manual interaction might be required | ||||||||||||||
Checkmk versions & editions |
|
Werk #4840 introduced timespecific parameters, which allowed timedependant check parameter configuration through timeperiods. Customer feedback has shown that these configuration were not flexible enough. Thats why we've changed the computation algorithm. The new algorithm only affects dictionary based check parameters, tuple based check parameters remain unchanged.
H3:Ruleset example old configuration (deprecated with this werk)
- Use parameters {"warn": 90} on saturday, default {"warn": 75, "crit": 80}
- Use parameters {"warn": 85, "crit": 92"} on weekend, default {"warn": 70, "crit": 75, "bandwidth": 1000}
- Use parameters {"check_mode": "auto"} (no timespecific rule)
The old mechanism created the following parameters
- Monday till Friday: {"warn": 75, "crit": 80"}
- Saturday: {"warn": 90}
- Sunday: {"warn": 75, "crit": 80}
As you can see, only the parameters from the first rule were taken into account.
H3:Ruleset example new configuration
- Use parameters {"warn": 90} on saturday, default {"warn": 75, "crit": 80}
- Use parameters {"warn": 85, "crit": 92"} on weekend, default {"warn": 70, "crit": 75, "bandwidth": 1000}
- Use parameters {"check_mode": "auto"} (no timespecific rule)
The new mechanism now creates the following parameters
- Monday till Friday: {"warn": 75, "crit": 80", "check_mode": "auto"}
- Saturday: {"warn": 90, "crit": 80, "bandwith": 1000, "check_mode": "auto"}
- Sunday: {"warn": 85, "crit": 92, "bandwith": 1000, "check_mode": "auto"}
As you can see, only the parameters from the first rule were taken into account.
The rule evaluation now starts at the bottom rule and then progresses to the top rule. For each rule, first of all the default parameters are applied. Afterwards the timespecific component(s) are applied. If a single rule have more than one timespecific parameter, these parameters are merged, too.
For example:
- Use parameters {"warn": 75, "crit": 80, "check_mode": "auto"} on Saturday 10-14h, Use parameters {"special_parameter": True} on Saturday 12-14h
- Use parameters {"warn": 85, "crit": 92"} on weekend, default {"warn": 70, "crit": 75, "bandwidth": 1000}
- Use parameters {"check_mode": "auto"} (no timespecific rule)
Result
- Saturday 11:00: {"warn": 75, "crit": 80, "bandwidth": 1000, "check_mode": "auto"}
- Saturday 13:00: {"warn": 75, "crit": 80, "bandwidth": 1000, "check_mode": "auto", "special_parameter": True}