headers
Andy Dills | 31 Mar 2011 18:43

Getting frequent "NaN" gaps in graphs, yet data is being retrieved ok


I've been using cricket for around a decade.

In the last few years, we've grown to the gigabit ethernet level. Since 
then, we've been getting strange gaps in our graphs, with NaN listed as 
the current value if you look at the graph when the gap is occuring. It 
doesn't seem to be based on a traffic level threshhold...I'll see valid 
data displayed at times that are higher usage than the traffic rates when 
the data is NaN.

Whenever I run a manual collector, the data is being retrieved fine. I 
can't figure out why the data isn't being displayed properly, and I'm not 
able to think of a way to troubleshoot this further. I've tried specifying 
the speeds of the interfaces, and I've even tried doing a fresh install on 
a much more modern server (as the server cricket has been on since 2004 is 
still chugging along, and producing graphs a bit more slowly than it 
should).

Any suggestions?

Thanks,
Andy

---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---
(Continue reading)

Permalink | Reply | 6 comments |
headers
Clarke Morledge | 31 Mar 2011 20:13
Favicon

Re: Getting frequent "NaN" gaps in graphs, yet data is being retrieved ok

Andy,

Most probably, you are using 32-bit counters in your SNMP sources, and the 
counters are wrapping around.  When that happens, you'll get negative 
results in your deltas, which is what gives you the NaN values in your 
graphs.

I started running into this a few years ago once we started to put some 
load on our gigabit links.  Moving to using 64-bit counters (where 
possible) will fix this.  Just remember that you'll probably have to 
graduate from SNMPv1 to SNMPv2c or 3 to get the 64-bit support in your 
MIBs.

Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187

On Thu, 31 Mar 2011, Andy Dills wrote:

>
> I've been using cricket for around a decade.
>
> In the last few years, we've grown to the gigabit ethernet level. Since
> then, we've been getting strange gaps in our graphs, with NaN listed as
> the current value if you look at the graph when the gap is occuring. It
> doesn't seem to be based on a traffic level threshhold...I'll see valid
> data displayed at times that are higher usage than the traffic rates when
> the data is NaN.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Stephen Carville | 31 Mar 2011 19:59

Re: Getting frequent "NaN" gaps in graphs, yet data is being retrieved ok

On Thursday 31 March 2011 09:43, Andy Dills wrote:
> I've been using cricket for around a decade.
>
> In the last few years, we've grown to the gigabit ethernet level. Since
> then, we've been getting strange gaps in our graphs, with NaN listed as
> the current value if you look at the graph when the gap is occuring. It
> doesn't seem to be based on a traffic level threshhold...I'll see valid
> data displayed at times that are higher usage than the traffic rates when
> the data is NaN.
>
> Whenever I run a manual collector, the data is being retrieved fine. I
> can't figure out why the data isn't being displayed properly, and I'm not
> able to think of a way to troubleshoot this further. I've tried specifying
> the speeds of the interfaces, and I've even tried doing a fresh install on
> a much more modern server (as the server cricket has been on since 2004 is
> still chugging along, and producing graphs a bit more slowly than it
> should).
>
> Any suggestions?

Try using 64 bit counters.  I added the following to appropriate parts of the 
config tree to get statistics for 64 bit counters

OID    ifHCInOctets           1.3.6.1.2.1.31.1.1.1.6
OID    ifHCInUcastPkts        1.3.6.1.2.1.31.1.1.1.7
OID    ifHCOutOctets          1.3.6.1.2.1.31.1.1.1.10
OID    ifHCOutUcastPkts       1.3.6.1.2.1.31.1.1.1.11

dataSource  ifHCInOctets
    ds-source        =   snmp://%snmp%/ifHCInOctets.%inst%
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andy Dills | 31 Mar 2011 21:24

Re: Getting frequent "NaN" gaps in graphs, yet data is being retrieved ok


Thanks, and thank you to the people who replied off list as well.

The solution was as simple as adding "snmp-version = 3" to the interfaces 
file for the routers and switches that have gigabit interfaces.

Thanks,
Andy

On Thu, 31 Mar 2011, Clarke Morledge wrote:

> Andy,
> 
> Most probably, you are using 32-bit counters in your SNMP sources, and the
> counters are wrapping around.  When that happens, you'll get negative results
> in your deltas, which is what gives you the NaN values in your graphs.
> 
> I started running into this a few years ago once we started to put some load
> on our gigabit links.  Moving to using 64-bit counters (where possible) will
> fix this.  Just remember that you'll probably have to graduate from SNMPv1 to
> SNMPv2c or 3 to get the 64-bit support in your MIBs.
> 
> Clarke Morledge
> College of William and Mary
> Information Technology - Network Engineering
> Jones Hall (Room 18)
> Williamsburg VA 23187
> 
> On Thu, 31 Mar 2011, Andy Dills wrote:
>
(Continue reading)

Permalink | Reply | 2 comments |

Gmane