[ZBX-9485] flexible interval "0" is considered to be more frequent than others Created: 2015 Apr 15 Updated: 2019 Dec 10 |
|
| Status: | Open |
| Project: | ZABBIX BUGS AND ISSUES |
| Component/s: | Documentation (D), Server (S) |
| Affects Version/s: | 2.4.4 |
| Fix Version/s: | None |
| Type: | Incident report | Priority: | Trivial |
| Reporter: | richlv | Assignee: | Alexander Vladishev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | flexibleintervals | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
zabbix manual says on flexible intervals : "If multiple flexible intervals overlap, the smallest Interval value is used for the overlapping period" this would seem to be intended to use more frequent interval. but if a positive number interval overlaps with interval 0, item is not checked - that is, 0 is just considered "smaller" than the other number. it should probably be considered "larger" interval instead. if this is changed, the behaviour should be also clarified in the manual (item and lld rule pages); if it is not changed, it should be documented |
| Comments |
| Comment by Martins Valkovskis [ 2015 Apr 15 ] |
|
Is this more of a bug report about current behaviour of flexible intervals, rather than documentation? Just wanted to add that in the current documentation, in "smallest Interval value", "Interval" is actually in italics to emphasize that it is the field value, not necessarily a smaller "interval" in reality. |
| Comment by richlv [ 2015 Apr 15 ] |
|
yes, it's suggested to change the current behaviour as it seems to go against the overall logic to make the more frequent polling win - but if it is decided against that, a specific note on how "0" works would be appreciated |
| Comment by Martins Valkovskis [ 2015 Apr 15 ] |
|
Just in case the current behaviour remains in place, I added "Note that if the smallest value of overlapping flexible intervals is '0', no polling will take place" to flexible interval information. |
| Comment by Glebs Ivanovskis (Inactive) [ 2017 Jan 05 ] |
|
Another counter-intuitive aspect (for me) is that flexible interval overrides default update interval, even if default is shorter. Therefore flexible interval with 1-7,00:00-24:00 period is different from "simple" update interval. Documentation says: I haven't seen such limitation in C code and I have just created item with 8 flexible intervals in the frontend. |
| Comment by richlv [ 2017 Jan 06 ] |
|
regarding the limit of 7 flexible intervals, this was enforced by the frontend. 7 was chosen as the highest possible flexible interval count that would never (or unlikely ?) exceed the database field length. it might or might not have changed with the development of scheduling. note that the limit of 7 was added some time ago, as this comment from 2012 already talks about that limit. |