You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 15, 2019. It is now read-only.
Created by ronny.biering on 2014-08-22 09:25:18 +00:00
Assignee: (none)
Status: New
Target Version: Backlog
Last Update: 2015-05-18 12:18:06 +00:00 (in Redmine)
There is a need for sanity checks to open 'known' huge history cronks in large environment with for example more then 1000 hosts or 10000 service.
Otherwise a service/host/downtime history cronk could lead to a query which can't be executed until the reload triggers the next one. The result is a busy db server or even worse.
Possible solutions are prefiltering regarding to the size. Let's say to show only the last week if host/services exceeds amount X or the sum of the db entries is bigger the Y.
It would also be possible to just open the empty cronk and allow the execution of the query only with set filters - and disable the auto reload for it.
And an authorization per user/group to see/open these cronks would reduce unwanted problems with this case
The text was updated successfully, but these errors were encountered:
This issue has been migrated from Redmine: https://dev.icinga.com/issues/6990
Created by ronny.biering on 2014-08-22 09:25:18 +00:00
Assignee: (none)
Status: New
Target Version: Backlog
Last Update: 2015-05-18 12:18:06 +00:00 (in Redmine)
There is a need for sanity checks to open 'known' huge history cronks in large environment with for example more then 1000 hosts or 10000 service.
Otherwise a service/host/downtime history cronk could lead to a query which can't be executed until the reload triggers the next one. The result is a busy db server or even worse.
Possible solutions are prefiltering regarding to the size. Let's say to show only the last week if host/services exceeds amount X or the sum of the db entries is bigger the Y.
It would also be possible to just open the empty cronk and allow the execution of the query only with set filters - and disable the auto reload for it.
And an authorization per user/group to see/open these cronks would reduce unwanted problems with this case
The text was updated successfully, but these errors were encountered: