NagVis - NDO claims that nagios did not status update

[ssoliveira]

Hi guys,

The operation of NagVis is better.

Apparently; the old configuration was generating an overhead on the Broker layer.

I continue with high CPU in Apache processes.

I'm looking into the possibility of changing NDOMOD; of Socket; for TCP; so I can move the NDO to a separate server; In order to; not impact the NDO when the machine is high CPU utilization.

Do you consider it a good idea?

[ssoliveira]

My CORE machine, where Nagios runs, is always CPU intensive. Due to Apache processes.

The MySQL server is practically asleep.

When we restart Nagios, the NDOMOD socket is restarted.

Apparently, in this scenario, NDOMOD Daemon loses the connection to the socket, and waits for the output socket to return to reestablish the connection.

My hypothesis is: If I move the NDO2DB to the same MYSQL server, and change the UNIX Socket connection to TCP; I believe that the time for the system to return to normal (after restarting the NAGIOS service) will be much lower because the NDO2DB service will no longer be affected by performance problems and will always be connected directly to MySQL.

Does this make sense?

[cdienger]

That config does make sense and I follow the logic although can't say for certain it will make a big difference. I would look forward to hearing your results if you do give this a try.

[SteveBeauchemin]

Apache load is high because of the Ajax refresh rate. If you poll less often, the load will decrease. At least that is what happens in my setup.

I made the following changes and no one even noticed.

These are my notes:
In order to reduce httpd load, the primary Nagios XI GUI refresh rates can be changed. The current default intervals are set to 7 seconds and 10 seconds for different parts of the GUI. We can change those by modifying the PHP code and making the interval longer.

Change to the file locations. There are 3 files we can modify
cd /usr/local/nagiosxi/html/includes/components/xicore

These are the files

status-object-detail.inc.php
status-utils.inc.php
status.php

We can change the defaults by looking for lines like this:
Search for the text "everyTime"

To set it to 30 seconds
...blah.everyTime(30*1000, blah...

To set it to 60 seconds
...blah.everyTime(60*1000, blah...

Example of actual code from a file

Code: Select all

       $("#' . $id . '").everyTime(90*1000, "timer-' . $id . '", function(i) {

In the status-object-detail.inc.php file I found that these changes had the most influence
7 second default is now set to 60 - in 4 places
10 second default is now set to 90 - in 8 places

(Default) x 4

You would need to make changes in increments slowly and see how your installation is affected.
These 'performance' changes are supposed to be part of an upcoming release.

Good luck.

Steve B

[dwhitfield]

These 'performance' changes are supposed to be part of an upcoming release.

I think this already happened:

Fixed dashlet refresh rates on object status pages to show up in "dashlet" tab in performance settings [TPS#11974] -JO

I could be wrong though. Are you talking about something else?

At the very least, the performance settings are definitely an option to help!