[ZBXNEXT-443] History view with lots of events and several items needs to be improved Created: 2010 Jun 28  Updated: 2016 Sep 29

Status: Open
Project: ZABBIX FEATURE REQUESTS
Component/s: Frontend (F)
Affects Version/s: 1.8.3
Fix Version/s: None

Type: Change Request Priority: Major
Reporter: Oleksii Zagorskyi Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: eventlog, log, logmonitoring
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

1.8.3


Issue Links:
Duplicate
is duplicated by ZBX-6384 "all" does not show all values for a ... Open

 Description   

this request as a continuation of the ZBX-2201

After I worked intensively with the monitoring of Windows events log, I decided to write a few serious request. This is the first of them

In most cases it is meant that the selected multiple items for display, but not only.
Also it is meant to display the history of windows events logs.

It would be useful at the bottom of the table to add statistics on how many lines from each items was displayed.
Also, if limitations defined in the "Search / Filter elements limit" is reached, then need to display a warning (at the bottom of the table) about the limits for each items, because without it is difficult to understand displayed all events or not from range of time and why displayed not all.

Also another problem: Set a limit of 1000.
Add in the history two items, which have more than 1000 events each in the selected time period.
At what first items has 1000 events in the early period, and the second - later towards the end.
You'll see that actually displays the event on only first item, because it triggered a limit of 1000 in the SQL-request and were returned only the first 1000 events (with a smaller 'id' in the table 'history_log'). This is bad - because quite understand why the events are not visible from the second and other items.

I propose to consider the proposal - to make individual requests for each item selected in the list. And set limit 1000 for each items individualy and not for all together.
It should be added the first column with a simple line number - this will facilitate the viewing of a large list and positioning.

Also very useful would be to add the ability to sort by user not only on the field "id", as well as the "clock" and "timestamp".
This needed because that under the influence of various factors (I will not dwell on them here) the events may come to the server, not in the same order as they created on Host, when viewing history will not show up in the real sequence.

And sometimes really, really need to see how events actually occur on the Host in real order with several journals simultaneously. Possibility of manualy user sorting by "clock" and "timestamp" should help in this.
Also, maybe sorting by default on the field "timestamp" more correct than on the field "id"? Please think about it.
Maybe position of column "Item" is best with ?3? Why it is between two columns of time? I do not see the logic in this.

Sorry for my english



 Comments   
Comment by richlv [ 2010 Jul 07 ]

these issues will be very hard to work on, because too many things are piled in them. numbered summaries would be helpful... in this case :

1. in log monitoring, showing stats for each added log would be useful (how many lines from each);
2. if search/filter limit is reached, a warning should be displayed;
3. if multiple items are added, limit is applied for them all together. it is suggested here to apply limit to each individual item.
4. ability to sort by clock & timestamp is requested
5. default sorting by timestamp is suggested
6. it is suggested to position column "item" as 3rd

Comment by richlv [ 2010 Jul 07 ]

...and my take on some of them

3. regarding this suggestion, it could cause problems - this limit is for performance reasons, and making it per item could result in lots and lots of data to be displayed. additionally, it might increase sql query count (just a guess)
5. might be undesirable, as this is only populated for windows eventlog

Comment by richlv [ 2010 Jul 07 ]

...and this is really a feature request, not a bug

Comment by Oleksii Zagorskyi [ 2011 Feb 13 ]

answers to Richlv:
2. very similar with a ZBX-3296
3. about performance reasons - i know about performance, but if i increase limit to the 10 000 (instead of default 1000), then i do not feel any discomfort.
Or you can to divide total limit by count of viewed items. And limit every item request to this new decreased limit.

Comment by Oleksii Zagorskyi [ 2015 Sep 16 ]

See also ZBX-9548

Generated at Wed Apr 24 05:28:36 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.