toasters

toasters@lists.teaparty.net

2 participants
13520 discussions

SNMP CPU usage in "TIMETICKS" is interpreted as uptime and corrupts logfile
by Darrell Root 27 Apr '98

27 Apr '98

I'm trying to use mrtg to show the CPU utilization on a Network Appliance. Here's the relevant portion of the netapp MIB (output of an SNMPwalk, with my notes on the right side): 1.3.6.1.4.1.789.1.2.1.1.0: TIMETICKS: 1016121072 (uptime in ticks {1/100sec}) 1.3.6.1.4.1.789.1.2.1.2.0: TIMETICKS: 33513506 (cpu ticks used since uptime) 1.3.6.1.4.1.789.1.2.1.3.0: INTEGER: 3 (% cpu util since uptime) 1.3.6.1.4.1.789.1.2.1.4.0: TIMETICKS: 982607568 (cpu idle ticks since uptime) 1.3.6.1.4.1.789.1.2.1.5.0: INTEGER: 97 (% idle since last boot) 1.3.6.1.4.1.789.1.2.2.1.0: INTEGER: 311445413 (nfs ops since boot) 1.3.6.1.4.1.789.1.2.2.2.0: INTEGER: 4503517 (total kbytes recd on all nets) 1.3.6.1.4.1.789.1.2.2.3.0: INTEGER: 1224614 (total kbytes trans since boot) I can't use the "% cpu util since uptime" figure because that's just an average cpu utilization since the last reboot, which isn't particularly informative when your server is usually up for months at a time. So I figured I'd use the "cpu ticks used since uptime" and "cpu idle ticks since uptime" MIB entries. The problem is that SNMP entry is of type "TIMETICKS", which is interpreted by the BER.pm module as an "uptime statistic". When I run that one, here's what the mrtg logfile looks like afterwards: 893639038 9 days, 8:48:06 9 days, 8:48:06 893639038 0 0 0 0 893638500 0 0 0 0 893638200 0 0 0 0 Ouch! The second time I run mrtg it fails with a "corrupt logfile" error (for good reason, that's corrupt all right!). Here's the output of mrtg with the DEBUG level set at 8: SNMPGET OID: 1.3.6.1.2.1.1.3.0 SNMPGET OID: 1.3.6.1.2.1.1.5.0 1.3.6.1.4.1.789.1.2.1.4.0&1.3.6.1.4.1.789.1.2.1.4.0:public@fs11 --> in: 9 days, 8:48:06 out: 9 days, 8:48:06 name: fs11.nas.nasa.gov getting SNMP variables for target: 1:public@fs12 snmpget: ifInOctets.1 ifOutOctets.1 fs12 public SNMPGET OID: 1.3.6.1.2.1.2.2.1.10.1 SNMPGET OID: 1.3.6.1.2.1.2.2.1.16.1 Now, here's the part of the BER.pm source code which decodes the SNMP reply: sub pretty_print ($) { my ($packet) = @_; my ($type,$rest); my $result = ord (substr ($packet, 0, 1)); return pretty_intlike ($packet) if $result == int_tag; return pretty_unsignedlike ($packet) if $result == snmp_counter32_tag || $result == snmp_gauge32_tag; return pretty_string ($packet) if $result == octet_string_tag; return pretty_oid ($packet) if $result == object_id_tag; ###THIS LINE return pretty_uptime ($packet) if $result == uptime_tag; ###THIS LINE return pretty_ip_address ($packet) if $result == snmp_ip_address_tag; return "(null)" if $result == null_tag; return "#<unprintable BER type $result>"; } The "pretty_uptime" subroutine is about what you'd expect, converting the ticks to "up for 4 days 3 hours..." format. So, if the result is an "uptime_tag" (which probably means the same thing as TIMETICKS), the BER.pm module formats it as an uptime string before it even gives it to mrtg. That's exactly what we want for the "this router has been up for ...." mesages on our webpages, but makes Netapp CPU information unavailable (except for the uptime since the last boot). I really want to avoid maintaining homegrown customizations to mrtg. I'd prefer a solution to be incorporated into the main mrtg source code. Here are some suggestions on a fix: 1) Have mrtg spawn a separate script which uses snmpget, and then reports this information as an integer (Peter Buschman recently send such a script to the toaster's alias...I was wondering why he didn't just have mrtg get the data directly...now I know). 2) Have the NetApp MIB report CPU ticks as an INTEGER or COUNTER instead of TIMETICKS 3) Have BER.pm report uptimes as an integer, and have the mrtg perl script do the "pretty_uptime" conversion if appropriate (ie. for "router uptime" information at the top of the webpage, but not for data put in graphs). 4) ??? Any suggestions anyone? I'm probably going to go with #1 unless someone has a better idea, but I thought this would be of sufficient interest that I'd spam you guys with it. Darrell Root rootd(a)nas.nasa.gov

1 0

Re: SNMP, mrtg, queries
by tjt＠netapp.com 24 Apr '98

24 Apr '98

> The numbers for cpu busy percent (1.3.6.1.4.1.789.1.2.1.3.0) aren't > working so good. It keeps returning "48". Does anyone know why this > would be? A 5 minute sysstat (sysstat 300) is showing more variation. That value isn't an instantaneous snapshot of the busy percentage, it's a busy percentage over the total running time of the filer. To compute a busy percentage over a specific amount of time, you need to sample the cpuBusyTime (.1.3.6.1.4.1.789.1.2.1.2.0) and cpuIdleTime (.1.3.6.1.4.1.789.1.2.1.4.0) values, and use the changes in those values (over whatever time period you want) to compute the busy percentage, i.e.: ( change_in_cpuBusyTime ) / ( change_in_cpuBusyTime + change_in_cpuIdleTime ) > The numbers for net usage (1.3.6.1.2.1.2.2.1.10.2 and > 1.3.6.1.2.1.2.2.1.16.2) keep returing zeros. Should I be using a > different set of numbers for an F220? I'm not sure why they're returning zeros. (They're returning non-zero for the machines, with more recent versions of ONTAP, that I've tried here.) As an alternative to those numbers, you should be able to get the total KBytes received and sent (since the last boot) from miscNetRcvdKB (.1.3.6.1.4.1.789.1.2.2.2.0) and miscNetSentKB (.1.3.6.1.4.1.789.1.2.2.3.0). ...Tim Thompson...Network Appliance, Inc...tjt(a)netapp.com...

2 1

RE: TBU
by Chris Fairbanks 24 Apr '98

24 Apr '98

Nope :( Its a sony. -chris -----Original Message----- From: Timothy A. McCarthy [mailto:tmac@netapp.com] Sent: Friday, April 24, 1998 9:33 AM To: Chris Fairbanks Cc: 'toasters(a)mathworks.com' Subject: Re: TBU Well, if it happens to be an HP 1533A or HP 1553A then you are in luck...it is supported now. Anything else, I do not know.... Chris Fairbanks wrote: > Does anyone know if netapp plans on supporting 4mm DDS-3 Dats? I have > one lying around I would like to put on my filer. > > Thanks, > Chris -- Timothy A. McCarthy --> System Engineer, Eastern Region. Network Appliance http://www.netapp.com 301-230-5840 Office \ / Page Me at: 301-230-5852 Fax \/ 800-654-9619

1 0

Unsubscribe
by Kenneth Zola #5 24 Apr '98

24 Apr '98

unsubscribe

1 0

TBU
by Chris Fairbanks 24 Apr '98

24 Apr '98

Does anyone know if netapp plans on supporting 4mm DDS-3 Dats? I have one lying around I would like to put on my filer. Thanks, Chris

3 2

SNMP, mrtg, queries
by Mark D Simmons 24 Apr '98

24 Apr '98

I feel a little dumb to be asking this but how does one actually get the NetApp MIB into mrtg to be able to query and plot information about one's filers? Currently I'm under the impression that I need to convert the fine NetApp MIB in ASN.1 to the serialised integer format, to build into the mrtg script. Now after much searching and thinking I've found a number of BER compilers that'll do the job, outputting C/C++ tables, but nothing that just outputs simple ascii strings. Am I on the right track? Is there a cunning and clever way to do the job without these steps? Has anyone done this before AND are willing to help me out/contrib the work back to the mrtg site? Any and all help sincerely appreciated!

3 2

None
by Kevin McNamara 24 Apr '98

24 Apr '98

subscribe toasters

1 0

Re: SNMP, mrtg, queries
by Mark D Simmons 24 Apr '98

24 Apr '98

Many thanks Peter, I'll scrutinize and learn from your example 8)

1 0

Extended Exabyte Mammoth support in 5.0R2
by grant＠netapp.com 24 Apr '98

24 Apr '98

Hi, Just in case you havn't heard: ----- Begin Included Message ----- New Features in Data ONTAP Release 5.0R2 Support for the Exabyte mammoth tape drive on the F630, F520, and the F230 ----- End Included Message ----- Available on NOW (http://now.netapp.com) Cheers, Grant

1 0

Subscribe
by rickleft＠worldnet.att.net 23 Apr '98

23 Apr '98

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters