Request - limit number of unconfigured objects per page

[kevinmjacobsen]

Hey,

I'd like to have a limit of the number of objects showing in unconfigured objects at any one time.

The problem I'm experiencing (even after modifications to php.ini and other config files) is that the list is just so long that, while I can choose all the items on the page, I get errors regularly stating "Configurations failed to write to file."

Basically I'd like to have it so I can do 100 at a time (or 25 or 50 or ???) without having to click on the box N number of times.

This is an issue for me as we have a Federated setup that has 1 system as the HUB. When I add a nagios xi server that has 300-500+ nodes I have to painstakingly add these to the hub.

Anyone want to suggest solutions?

[tgriep]

The changes you have done to the php.ini file, can you post them especially the max_input_vars option?
One thing you can do it to double it again.

Also, one more thing to try is to edit the following file on the Nagios server

Code: Select all

/etc/httpd/conf/httpd.conf

Add this line to the bottom of that config file.

Code: Select all

LimitRequestLine 100000

Save the file and restart the Apache process by running

Code: Select all

service httpd restart

See if doing both of the changes make it so you can add all of the unconfigured objects at once.

[kevinmjacobsen]

Yes all of these options have been set.

The problem isn't being able to choose a large number of unconfigured objects and attempting to configure them.

httpd.conf adjustments

##
## Added by Kevin
##

LimitRequestFieldSize 1000000
LimitRequestLine 1000000


php.ini adjustments

max_execution_time = 60
max_input_time = 60
memory_limit = 256M

I've now got:
max_input_time = 120

BTW - don't the changes to the httpd.conf file tend to make this host now much more easily be DDOSed?

Still the same results after bumping max_input_time to 2X what I had...

Unconfigured Passive Object Monitoring Wizard
Configurations failed to write to file.
Configuration Error
An error occurred while attempting to apply your configuration to the monitoring engine. Contact your Nagios administrator if this problem persists.

[tgriep]

One more thing to do, add the following line to the /etc/php.ini file

Code: Select all

max_input_vars=10000

Save the changes and restart Apache by running

Code: Select all

service httpd restart

Then run this as root to tail the Apache logs

Code: Select all

tail -f /var/log/httpd/*_log

Then login to the GUI and configure the unconfigured objects.
If it works, then the last change to the php.ini file fixed it, if it fails again, post the output from the tail command.

[dwhitfield]

In addition to what @tgriep said...

This is an issue for me as we have a Federated setup that has 1 system as the HUB.

Maybe I am misunderstand what is going on, but this sounds like exactly what Fusion is designed to do: https://www.nagios.com/products/nagios-fusion/

[kevinmjacobsen]

@dwhitfield

If you can show me how to allow a user the ability from the fusion server to show a set of servers in a dashboard, get alerting from those various nodes on various Nagios servers, pull historical metrics for a random list of servers and metrics... etc.

Then I'll gladly use the fusion we have deployed. As far as I can tell it is good for one thing - seeing all of your nagios servers. And that is about all the use I've been able to glean out of it.

The federated model (using inbound & outbound) allows me to grant users a single pane of glass approach for my nearly 15 nagios xi deployments. I can grant access to a user and they can then be customized to allow them to see a limited set of servers and do things they care about like alerting, reporting, etc.

I'm glad to learn that I can get this model/info in Fusion... but to me fusion is a horrible product that doesn't deliver on what it was intended to deliver.

[kevinmjacobsen]

From the error_log

[Fri May 19 16:30:41 2017] [notice] caught SIGTERM, shutting down
[Fri May 19 16:30:41 2017] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Fri May 19 16:30:41 2017] [notice] Digest: generating secret for digest authentication ...
[Fri May 19 16:30:41 2017] [notice] Digest: done
[Fri May 19 16:30:41 2017] [notice] Apache/2.2.15 (Unix) DAV/2 PHP/5.3.3 mod_ssl/2.2.15 OpenSSL/1.0.1e-fips configured -- resuming normal operations
[Fri May 19 17:14:59 2017] [error] [client 127.0.0.1] PHP Fatal error: Maximum execution time of 60 seconds exceeded in /usr/local/nagiosxi/html/includes/components/ccm/includes/applyconfig.inc.php on line 237

So, I'm upping that number now -

max_input_time 300.

I'll update on status.

[dwhitfield]

Unfortunately, despite the new fusion being officially under "release candidate" status, there is no changelog. As I filed an unofficial bug report about this, I suspect that will change today or early next week. That said, the following are on the public roadmap:

New modern interface design like all Nagios products
Increased usability for integrating our products and solutions
Improved performance and retention settings for data
Improved integration with Nagios XI and Nagios Core
Dashboards and editable dashlets
New and improved user settings and permissions (including auto-logging into XI systems per user, set by individual users)
Component and dashlet management like in Nagios XI

We did have a customer beta program for fusion, but since it is now a release candidate, I don't know if that's still an option.

If you've looked at the "current" fusion and found it doesn't meet your needs, I see no reason to take another look at it with the new version so close to release.



As far as your error, it looks like you also need to set a high execution time in your /etc/php.ini, not just input time.

[kevinmjacobsen]

yeah typed the wrong thing...
I've set
max_execution_time = 300

The future release of Fusion might be just the ticket. Hope to hear about it soon so I can upgrade quickly and perhaps dump this federated approach.

[dwhitfield]

I am going to PM you about Fusion. If increasing your timeout in XI didn't fix the issue, please let us know.