Werk #22327: EC: honor ascending priority ranges
| Component | Event Console | ||
| Title | EC: honor ascending priority ranges | ||
| Date | Oct 22, 2026 | ||
| Level | Trivial Change | ||
| Class | Bug Fix | ||
| Compatibility | Compatible - no manual interaction needed | ||
| Checkmk versions & editions |
|
Rules of the Event Console with a Match syslog priority range like "from emerg to warning" usually didn't match any messages. Likewise, a Syslog priority to cancel event range like "from notice to debug" usually didn't cancel any events, unless the rule had no Match syslog priority range. The event simulator showed such rules as matching nonetheless. Ranges in the other direction, like the default "from warning to emerg", were not affected.
Both directions of priority ranges work now. A rule edited by hand with a
priority beyond debug in such a range is ignored now, like a rule with an
invalid regular expression, and the Event Console logs an error about it in
var/log/mkeventd.log. Previously, with the global setting Optimize rule
execution enabled, the Event Console usually ignored such a rule if its range
started at the more severe priority. With a range in the other direction, it
failed to start, and when reloading its configuration, it ignored all rules
after that one. With the setting disabled, such a rule matched like one with a
range up to debug.
Technical background
The global setting Optimize rule execution, which is enabled by default, pre-selects the rules to try for each combination of syslog facility and priority. It assumed the "from" priority of a range to be the less severe one, so it ignored a range in the other direction when pre-selecting a rule. Such a rule was only tried for the priorities of its other range, if it had one, or for all priorities if it needed that anyway, e.g. because it had no Match syslog priority range or a Text to cancel event(s) without a cancel priority range.