Feature request: more than 100 rows per page in monitoring and configuration

[btassite]

Centreon version 2.8.22
Centreon Engine 1.8.1
Centreon Broker 3.0.14

Administration, Parameters, Centreon UI, "Limit per page for Monitoring" can only be set to a maximum of 100. Please make this a user changeable setting and/or decouple monitoring view from configuration (e.g. curves, Configuration/Services etc.) where dynamic refresh slowdowns are not an issue.

For configuration this is useful on massive changes involving more than 100 hosts/machines where you can't select the maximum number from the drop down menu (e.g. 3500 services, see older bug for massive changes not working for over 1000 items).

[lpinsivy]

@btassite their is no limit in configuration listing menus.

But yes the select list is limited to 100 for realtime. Can you explain me a case when you need to select more than 100 to apply actions?

[btassite]

On acks/downtime/massive changes for several thousands of services you now have to do them per 100. I wouldn't mind having a "pause" button so it doesn't try to refresh in the meantime if your system can't handle it, but that would be a separate feature request. The maximum should be up to the user though.

[btassite]

Also sometimes searching/scrolling through many services is much quicker if you don't have to keep clicking next page.

[btassite]

BTW, in configuration you can either select 10-100 or the maximum, which is on our case several thousand, so I was thinking apart from keeping the maximum maybe you could increase jumps above 100 to per 200, 300 etc. to 1000, then per 1000 to 10000 and so on, depending on the limit set by the user. "10000 rows should be enough for everybody!" ;)

[lpinsivy]

I dont know web interface or other capable of configuring several hundred or even thousands of objects at the same time. I think you should use the APIs to make mass modifications.

[btassite]

The infrastructure and the options in the web interface are there, why not let the admin decide?
In fact a limit above 100 is already allowed on some pages, e.g. host configuration. The issue is you can't set your own limits, just fixed ones up to 100 and then the maximum services/hosts.

Generating a page with ~1000 hosts here takes 5 seconds on the server side and almost immediately displays on a reasonable laptop. If the configuration was not a drop down menu up to 100 but a text box, I could put in 1000 and be both fast enough and not have to click through ten pages.

Scripting everything through CLAPI is not a solution as it would be both more complex and slower overall (not in the least because CLAPI itself isn't a speed demon).

[lordtaki]

+1 for this request.
OPS team may have to deal with hundreds of alerts of the same type and prefer to ack all at once instead of repeat the same action on several pages.

At least maybe increase the 100 limit?

[lpinsivy]

@lordtaki we are developing the possibility to do this with API.

https://github.com/centreon/centreon/pull/7187

[btassite]

Doing this by CLAPI doesn't solve the issue, most of our monitoring users have no clue about CLAPI and are using the web front-end.

If this is going to be implemented by CLAPI only I need to basically reproduce the web frontend, that's kinda reinventing the wheel..

[lpinsivy]

@btassite I can understand that for one time it is difficult but normally you shouldn't have too much resource in non-ok state if you configure parentship and/or dependencies

[btassite]

We need this for configuration changes, not acknowledgements. But now that you mention it, we have a store network with hundreds of hosts and thousands of services that basically go down every evening :)

BTW, the 2.8.x version has the added irritating habit of restricting the number of items to 30, even if you have set 100 in the config and/or used the drop down menu to set it to 100 and navigate elsewhere (in 2.7.x it remembered this selection). The same goes for forgetting strings in the host and service fields, so every time you configure something you need to re-restrict your selection.

[lpinsivy]

Yes we will work soon on filters fields to keep in memory user definition.

For your issue with your store, you can program recurrent downtimes :D.

[btassite]

Management doesn't like downtime since they can use the down states for statistical persuasion purposes :)