I am trying to work out how this is calculated exactly, and thought I would post hers as so far I have not found an answer.
The issue I am trying to solve may well be very simple, but I have a device (as an example) that shows this for a "show int"
30 second input rate 131520000 bits/sec, 27308 packets/sec
30 second output rate 188926000 bits/sec, 39843 packets/sec
But my graph shows the max throughput in and out at ~113mb (Not exactly the same but close) so I am trying to figure out a few things to troubleshoot.
First, and most basic where can I see the above counters in an snmpwalk to validate what snmp (And thereby cacti) sees when this switch is polled over snmp as opposed to the show interface command at the CLI, I suspect this is not a single OID but a calculated value but I am not sure where the 30 second calculation or counter even is.
Actually that's pretty much the only question that matters at this point, simply validating the data I show at the switch CLI against what snmp shows, and cacti ingests.. If I cannot validate that then that explains the entire issue I think.. If I CAN validate it I think the question (I have already asked internally) is going to be is this throughput sustained or bursty, if it is bursting it means I need to again circle back and put time into migrating to spine as the issue is probably going to just be my collection interval?
This output is off a cisco switch, I do not have the running IOS version but could get it if relevant, but if this value is simply calculated off the IF-MIB outputs I can get those easily, I am just trying to work out how to manually validate what Cacti shows against the device itself.
Interface Throughput Calculation
Moderators: Developers, Moderators
Re: Interface Throughput Calculation
First, check and make sure you are using the 64 bit graph, not the 32 bit.
Re: Interface Throughput Calculation
OK I did set up a second copy of this device and selected the 64 bit graph template but the data appears to be more or less the same (But not identical which is a little odd, but I assume that is just jitter on the device between when the first and second copies are polled) it is not a massive difference though.
I am still playing with this, assuming the data off the switch (Still trying to figure out how to validate it) is accurate then I am betting i have something stupid wrong in a formula..
I am still playing with this, assuming the data off the switch (Still trying to figure out how to validate it) is accurate then I am betting i have something stupid wrong in a formula..
Re: Interface Throughput Calculation
OK the more I dig at this, and the more reading I do the more I think the next step here is to get Spine working (I've put it off for years due to odd segfaults and lack of time to properly troubleshoot) but while the divide between host 1 and host 2 results is not massive, it is enough to make me wonder what the impact of a 5 minute poller cycle really is vs a more aggressive polling interval which should be possible with spine I believe.
Going to continue reading but I think that is going to be my next step, will post results either way in the event someone else finds this thread in 2 years so it has some actual info in it
Cheers!
Going to continue reading but I think that is going to be my next step, will post results either way in the event someone else finds this thread in 2 years so it has some actual info in it
Cheers!
Re: Interface Throughput Calculation
OK poll interval is definitely the issue, upgrading to spine and moving to a 1m poll window appears to have corrected the issue. I just need to sort the new errors I see now that I am using spine lol.
So I guess the answer here is that a 5 minute poll window can easily introduce this kind of behavior.. Which kind of supports the strong suggestion to use spine.
So I guess the answer here is that a 5 minute poll window can easily introduce this kind of behavior.. Which kind of supports the strong suggestion to use spine.
Who is online
Users browsing this forum: No registered users and 5 guests