icinga-service-status-details.png
[ZBXNEXT-3189] Add 'Last Check' column to Monitoring-Triggers Created: 2016 Mar 11 Updated: 2016 Mar 15 |
|
| Status: | Open |
| Project: | ZABBIX FEATURE REQUESTS |
| Component/s: | Frontend (F) |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Change Request | Priority: | Trivial |
| Reporter: | Stepan A. | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | sorting, triggerstatus, usability | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
icinga-service-status-details.png
|
| Description |
|
Now in Monitoring-Triggers there are 2 columns with effectively the same data: "Last Change" and "Age". Replacing "Last Change" with "Last Check" column would make this table much more informative - you'll see not just trigger statuses but also how current they are. And also it would be great not to reset automatically 'Triggers status' to 'Recent problems' in filter settings, but let it stay in the last selected state (like 'Minimum trigger severity'). |
| Comments |
| Comment by richlv [ 2016 Mar 11 ] |
|
trigger status filtering is not remembered on purpose, but only when you have selected all/all for group and host filters - such a combination can very easily lock users out of trigger page in larger installations. as for the main suggestion, what exactly should "last check" show? last time trigger was evaluated ? |
| Comment by Stepan A. [ 2016 Mar 12 ] |
|
Hmm, for me it resets 'Trigger status' even with specific group and host, for example, after switch to Events tab and back to Triggers (version 3.0.1 from Zabbix repository for CentOS 7). Since "trigger status (the expression) is recalculated every time Zabbix server receives a new value that is part of the expression" (https://www.zabbix.com/documentation/3.0/manual/config/triggers), as far as I undestand, the trigger last evaluation time should be enough to estimate how fresh the data is. And it's probably easier than to figure out timestamp of corresponding item. |
| Comment by richlv [ 2016 Mar 12 ] |
|
1. sorry, i phrased it wrong - trigger status is not remembered on purpose, as that is a problem when host and group selection is set to all/all - but it is not remembered always. 2. not only then - if you trigger includes any time-based trigger function like nodata(), it is also recalculated every 30 seconds. such a column might be a bit tricky and possible to misinterpret - a tooltip could be a big help then |
| Comment by Stepan A. [ 2016 Mar 15 ] |
|
Well, may be it's worth to just add a new field 'lastcheck' to 'triggers' table and update it with every trigger evaluation? |
