Nagios Support Forum

Hello,
We have been experiencing an issue where our bandwidth graphs would just go to 0Mb/s for hours when we know there is traffic going on. We're primarily seeing this only on Cisco interfaces. Our monitoring of servers continue to work with no issues. We are an ISP provider, so, this graph should never be at 0Mb/s, here is a URL to a graph. https://imgur.com/a/w7sl5H0
There are no interface errors..etc.
Thanks.

Here is a good place to start for performance graph problems.
https://support.nagios.com/kb/article.php?id=9

If you could run the commands in the doc and post back the results it will assist us in collecting the information we need.


The process that gathers the Bandwidth information for the Nagios server is called MRTG and it is scheduled to run every 5 minutes and if it cannot finish in that time, it could cause the issue you are having.
To see how long it takes, run the following command as root.
If it takes close to 5 minutes, you may have to remove the MRTG config files of devices that are no longer in service.
The config files are in the /etc/mrtg/conf.d folder and are named with the IP address of the device.
If you see some configs that are not in use anymore, delete the config file and that should speed up MRTG.

Hello,

Thank you for your response, I ran the "time LANG=C LC_ALL=C /usr/bin/mrtg /etc/mrtg/mrtg.cfg" command and am seeing a the following results:

time real 5m56.489s
user 0m40.547s
sys 0m2.147s

I removed well over 25 config files of removed devices from the /etc/mrtg/conf.d folder but I did not see a change in the timing. Is there any other way we can get the timing down?

Thanks

You can run this command and then look in the /tmp/mrtg.txt file for more configs you can delete. The ones that timeout or do not return data can be removed. Another option is to increase the MRTG forks. That will allow it to run more processes which will be faster.
Edit the /etc/mrtg/mrtg.cfg file and change this from to Save the file and restart crond by running See how long it takes.

This seems to be the fix for us.

real 2m11.229s
user 0m51.371s
sys 0m3.757s


Upgrading forks from 4 to 12.

That is good news that the changes works for you. I'll close and lock the post as solved but feel free to open a new post in the future if needed.