All it is doing, as I understand it, is noting that the current value is
less than
the last value, therefore it must have wrapped, OR been reset by the
operator.
It does not presume to know what the maximum value might have been, and
therefore discards that particular datapoint as unknowable. It resumes with
the delta it gets from two subsequent, increasing values. Is this different
from
what you are seeing, or did I misunderstand your situation?
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
Clarence Hart <rti1clh@ismd.ups.com>@tkg.com on 11/30/2000 04:11:45 PM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
Sent by: owner-nv-l@tkg.com
To: nv-l@tkg.com
cc:
Subject: Re: Antwort: Re: Antwort: Re: [NV-L] Better Graphing tools for
Netview
Hey , All...
I understand that snmpCollect is supposed to save ifInOctets (for
example) as COUNTER data and
store the info in the respective data files.
I'm wondering is this a bug... Check this out....
snmpCollect grabs data (bugus here of course:)
from snmpColDump -tT
11/29/00 16:49:00 switch1234.com 115546 975530942 975534540
11/29/00 19:26:34 switch1234.com 113586 975540394 975543994
Heres the log entry....
Wed Nov 29 17:26:35 2000 : SNMPget(switch1234 ifInOctets.24): counter
init/wrap
Wed Nov 29 18:26:34 2000 : ifInOctets.24 Counter wrapped on switch1234
(4036900444->129311686) Waiting
until next collection to compute
Wed Nov 29 18:26:34 2000 : SNMPget(switch1234 ifInOctets.24): counter
init/wrap
Wed Nov 29 19:26:34 2000 : SNMPget(switch1234 ifInOctets.24): 113586
As you can see the data looks good until the COUNTER value exceeds the
32-bit number.
OK, my question is why does snmpCollect state that it will compute the
value at the
next collection time but it never makes and entry in the inInOctets.24 file
for
"Nov 29 17:26 or 18:26"? snmpcollect seems to know that the counter
wrapped but it doesnt
do anything about it.
Is snmpCollect supposed to do update the ifInOctets file with the missing
amount ?
Or is my version of snmpCollect bad?
It seems like snmpCollect should get a value from the device...
Then state the counter wrapped...
Then update the ifInOctets.x file at the next collection time
with 2 values
instead of one.
Thank You!!
CoolC
> From: Jochen.Friedrich@genorz.de
> Subject: Antwort: Re: Antwort: Re: [NV-L] Better Graphing tools for
Netview
> To: IBM NetView Discussion <nv-l@tkg.com>
> Date: Wed, 29 Nov 2000 16:06:00 +0100
> X-Priority: 3 (Normal)
> X-MIMETrack: Serialize by Router on
GFSLNT85/Servers/GENO-RZ/GENO/DE(Release 5.0.1b (Intl)|30
September 1999) at 29.11.2000 16:06:17
> MIME-Version: 1.0
> X-Sorted: Bulk
>
>
> Hi Clarence,
>
> > This is what I'm doing;
> >
> > 1) snmpCollect collects and saves all data from OID.#! files.
> >
> > 2) I then read/dump the OID.# data to create the rrd's.
> >
> > 3) webpage displays on-the-fly graphs.
>
> Sounds familiar ;-)
>
> > The problem happens during step 1. My network devices have 32bit
> > counters so once or twice a day on busy ports the counters reset or
> > wrap. This causes a gap in the rrd database. Have you run into this
> > problem?
>
> We currently only use snmpCollect to collect Interface statistics and
> CPU load for all our routers. For the interface statistics, snmpCollect
> already does the conversion from COUNTER to GAUGE type data.
>
> > Also I'm wondering has anyone change the mib.coerce data file
> > to store GAUGE instead of COUNTER type data to resolve similar
issues.
>
> This might be a possibility. The standard interface statistics (under
> mibII.if) seem to be handled correctly.
>
> Cheers,
> Jochen
>
> _________________________________________________________________________
> NV-L List information and Archives: http://www.tkg.com/nv-l
Clarence Hart
UPS
Office: 410-560-4182
Fax: 410-560-4329
chart@ups.com
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
|