Page 1 of 1
bandwidth graphs and updating interface info
Posted: Tue Dec 01, 2020 12:53 pm
by pspagnola
I am graphing bandwidth on some cisco switch interfaces via SNMP. When the interface description changes or the max interface speed changes, is there a way to auto update that on the service object or via wizard? if no, how do I do it manually. The service object does not hold as much info as expected for me to modify.
Re: bandwidth graphs and updating interface info
Posted: Wed Dec 02, 2020 2:15 pm
by ssax
There isn't a way to automatically update them, I submitted a feature request recently for development to add that functionality but it doesn't exist today.
What I would do is just disable the current services in CCM > Services and then re-run the Network Switch / Router wizard again using the same hostname and then it will add new services with the updated service descriptions.
You could also just re-run the wizard and stop after it lists the port descriptions and then manually update the service names in CCM > Services with what they show.
You could also get the names by running the command from the top of your /etc/mrtg/conf.d/X.X.X.X.cfg and output it to a file.
Regardless of what method you choose, renaming the services (or adding new ones with different names) will cause the backend /usr/local/nagios/share/HOSTNAME/SERVICENAME.rrd files to not match so you won't see the historical graph data on the new one. What you can do is take the
new service name and use it run it in this command:
Code: Select all
echo 'Your Service Description' | sed 's/[ :\/\\]/_/g'
Then rename the old RRD file for that service to the new name that command outputs (it removes some invalid characters from the name of the service like the backend does):
Code: Select all
cd /usr/local/nagios/share/YOURHOSTNAME
mv YOURSERVICENAME.rrd YOURNEWSERVICENAMEFROMCOMMANDABOVE.rrd
Then you should be able to see the historical data.
Re: bandwidth graphs and updating interface info
Posted: Thu Dec 10, 2020 2:56 pm
by pspagnola
Thank you very much for explaining that. I hope the new feature gets added, it sounds great!
Part of my Problem is I don't understand where the current interface description is saved. I am ok changing it manually for important things. I don't like the idea of losing historical data.
Re: bandwidth graphs and updating interface info
Posted: Fri Dec 11, 2020 4:10 pm
by ssax
You would edit it in Configure > Core Config Manager > Services by editing the service and changing the service description to change them, Save, then Apply Configuration.
To not lose historical perfdata, it's really as simple as updating the service description via the steps above to what you want, waiting for the new perfdata rrd to be created (either by forcing a check or waiting for the next one) on the backend, and then just copying the old one over the new one and then you'd see the historical perfdata again.
Code: Select all
cp -p /usr/local/nagios/share/perfdata/hostname/OLD_RRD_NAME.rrd /usr/local/nagios/share/perdata/hostname/NEW_RRD_NAME.rrd
Re: bandwidth graphs and updating interface info
Posted: Fri Dec 11, 2020 4:20 pm
by pspagnola
thank you for that reply.
I guess my real question is how does nagios know which physical port on the switch a service is monitoring?
I want to understand the design and how the nagios objects correlate to the switch.
if I go to CCM and rename service "TwentyFiveGigE1/0/39 Server01-02-1Gb Bandwidth" to "watermelon" will it still function? There must be a separate field somewhere that contains the port index ID or something like that. on previous monitoring systems I have used it had a service description and some type of port ID field that had no relation. description could be any string.
Re: bandwidth graphs and updating interface info
Posted: Tue Dec 15, 2020 6:26 pm
by ssax
For the bandwidth checks it uses
/etc/mrtg/conf.d/X.X.X.X.cfg which uses the interface ID.
- The bold part is the interface ID, you can see yours if you look in that file
Target[192.168.X.X_
14502]
See here for the architecture:
https://support.nagios.com/kb/article/n ... re-62.html
For the interface status checks it uses the interface ID as well which is stored directly on the service in $ARG2$.
Yes it would still work if you did that. The service description can be anything you want as it doesn't really matter (except for historical perfdata as described earlier).
Re: bandwidth graphs and updating interface info
Posted: Mon Dec 21, 2020 10:50 am
by pspagnola
Thank you.
I was able to get everything figured out.
on my cisco switch I needed to run: snmp-server ifindex persist
then I deleted all the old services, and ran the config wizard again.
all my indexes had shifted by 1 after a switch reboot. which was causing alerts for a notconnected 1 gigabit interface because it was using the interface index of a connected 10 gigabit interface.
It was very confusing.
It may be helpful for others to know that you can check the interface index on your cisco switch like this:
show snmp mib ifmib ifindex | include [index id]
that way if you have the index id from nagios and you want to know which interface on the switch correlates, run that command.
cisco command info:
https://www.cisco.com/c/en/us/td/docs/i ... D243B70A66
Re: bandwidth graphs and updating interface info
Posted: Mon Dec 21, 2020 12:09 pm
by scottwilkerson
pspagnola wrote:Thank you.
I was able to get everything figured out.
on my cisco switch I needed to run: snmp-server ifindex persist
then I deleted all the old services, and ran the config wizard again.
all my indexes had shifted by 1 after a switch reboot. which was causing alerts for a notconnected 1 gigabit interface because it was using the interface index of a connected 10 gigabit interface.
It was very confusing.
It may be helpful for others to know that you can check the interface index on your cisco switch like this:
show snmp mib ifmib ifindex | include [index id]
that way if you have the index id from nagios and you want to know which interface on the switch correlates, run that command.
cisco command info:
https://www.cisco.com/c/en/us/td/docs/i ... D243B70A66
thanks for sharing your findings
Locking thread