nv-l
[Top] [All Lists]

Re: [nv-l] MIB Bata Collector Problem and Very big snmpcol.trace

To: Karl Prinelle <Karl.Prinelle@elyzium.co.uk>, NetView mailing list <nv-l@lists.tivoli.com>
Subject: Re: [nv-l] MIB Bata Collector Problem and Very big snmpcol.trace
From: Jane Curry <jane.curry@skills-1st.co.uk>
Date: Tue, 02 Sep 2003 11:26:55 +0100
Delivered-to: mailing list nv-l@lists.tivoli.com
Delivery-date: Tue, 02 Sep 2003 11:27:28 +0100
Envelope-to: nv-l-archive@lists.skills-1st.co.uk
In-reply-to: <000c01c37139$d092ebf0$720b0a0a@pozow2k>
List-help: <mailto:nv-l-help@lists.tivoli.com>
List-post: <mailto:nv-l@lists.tivoli.com>
List-subscribe: <mailto:nv-l-subscribe@lists.tivoli.com>
List-unsubscribe: <mailto:nv-l-unsubscribe@lists.tivoli.com>
Mailing-list: contact nv-l-help@lists.tivoli.com; run by ezmlm
References: <000c01c37139$d092ebf0$720b0a0a@pozow2k>
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425
I have similar experience and make similar recommendations. There are
all sorts of detailed ways in which the Windows product behaves less
well than the Unix product, even though the marketing bullets are the same.

One area where I had particular pain was in the management of a
hierarchy of NetViews with a Manager of Managers NetView on AIX and sub
NetViews on NT. In addition to the data collection problems you found,
many of the general housekeeping routines I use on Unix NetView are
inappropriate / harder / unimplementable on Windows.

So, like Karl, I would ONLY recommend NetView on Windows where thers is
NO Unix experience, the installation is small, single NetView, and data
collection was not required. This isn't necessarily a fundamental
problem with NetView per se - many of the limitations are due to
underlying Operating System limitations.

Whilst on the soap box........
Please IBM - can we have the Linux NetView upgraded to support all the
features of AIX and Solaris - RDBMS, MLM Configuration, APM, ........

Cheers,
Jane

Karl Prinelle wrote:

>Since I had that experience with Win/Netview I've tried to always use a
>*nix platform for netview & had much better experiences.  On *nix you
>also get the ruleset editor which is really useful.
>If you have the time etc then I'd be tempted by a migration - personal
>view of course.
>K
>-----Original Message-----
>From: Haibo Yang [mailto:hbyang@sysway.com] 
>Sent: 02 September 2003 04:01
>To: nv-l@lists.tivoli.com
>Subject: Re: RE: [nv-l] MIB Bata Collector Problem and Very big snmpcol.
>trace
>
>
>Thank you very much for your help.
>
>In fact, I have noticed the problem with graphing. But I didn't realized
>that it is because of the holes on the collection.
>
>Well, What should I do then? Seems that most of netviewrs let netview
>running on other platform, but Windows. 
>
>Should I consider to migrate my netview to linux or unix too?
>
>Cordially
>
>Bruce Yang
>0086-755-26742343
>hbyang@sysway.com
>
>
>       
>
>======= 2003-09-01 18:45:00 您在来信中写道:=======
>
>  
>
>>Another issue I found terrible, Netview for Windows does not graph data
>>    
>>
>
>  
>
>>before a hole on the collection. You just have graph from the last 
>>continuous successful stream collection. I opened a call for support, 
>>and the answer was "Work by design" ! ok...:/
>>I moved for Netview/Linux.
>>
>>--
>>Helder Garcia
>>
>>On Sun, 2003-08-31 at 06:07, Karl Prinelle wrote:
>>    
>>
>>>Bruce,
>>>
>>>I've had the same problem in the past on w2k netview & had to change 
>>>netview platforms.
>>>
>>>In my situation the routers being monitored were quite busy.  If the 
>>>device is busy and you send an snmp query to it, then it can simply 
>>>ignore your query since it has higher priority work to complete 
>>>(routing!).  Also, if you send a query for a large number of objects 
>>>then this can cause the query to be ignored too.  The combination of 
>>>a busy router and large (no metric for how large is large I'm afraid)
>>>      
>>>
>
>  
>
>>>snmp query increases the chance of the query being ignored.  The 
>>>result is the deferred collection.
>>>
>>>You can reduce the snmpCollect deferred timeout value which is 1hr by
>>>      
>>>
>
>  
>
>>>default.  This won't mean the deferrals will stop, just that 
>>>snmpCollect will try that query again in a shorter timeframe.  When I
>>>      
>>>
>
>  
>
>>>did this I still ended up with large numbers of consecutive deferrals
>>>      
>>>
>
>  
>
>>>which created large holes in my data.
>>>
>>>I was pointed at the maxpuds value which is available on Unix/Linux 
>>>netview versions (not available on windows) - have a search on the 
>>>archive for that for more info.  As a test I tried putting a Solaris 
>>>Netview in place, set the maxpdus to 40 and it all worked fine.  I've
>>>      
>>>
>
>  
>
>>>tried w2k netview polling ~600 interfaces on two large but quiet 
>>>routers & it never completed a query - swapping to AIX/netview & 
>>>maxpuds=50 & all was ok.
>>>
>>>
>>>hth
>>>
>>>K
>>>
>>>---------------------------------------------------------------------
>>>---
>>>---
>>>Karl Prinelle
>>>Elyzium Ltd
>>>Office: +44 (0)1753 515000
>>>Mobile: +44 (0)7813 189198
>>> 
>>>E-mail: karl.prinelle@elyzium.co.uk
>>> 
>>>Website:www.elyzium.co.uk
>>> 
>>>---------------------------------------------------------------------
>>>---
>>>---
>>>Elyzium Disclaimer:
>>>This email transmission is confidential and intended solely for the
>>>person 
>>>or organisation to whom it is addressed. If you are not the intended 
>>>recipient, you must not copy, distribute or disseminate the
>>>      
>>>
>information,
>  
>
>>>or 
>>>take any action in reliance of it. Any views expressed in this
>>>      
>>>
>message
>  
>
>>>are 
>>>those of the individual sender, except where the sender specifically
>>>states 
>>>them to be the views of any organisation or employer. 
>>>If you have received this message in error, do not open any
>>>      
>>>
>attachment 
>  
>
>>>but please notify the sender (above) deleting this message from your
>>>system. 
>>>Please rely on your own virus check no responsibility is taken by the
>>> sender for any damage arising out of any bug or virus infection.
>>>
>>>      
>>>
>------------------------------------------------------------------------
>  
>
>>>--- 
>>>
>>>
>>>-----Original Message-----
>>>From: Haibo Yang [mailto:hbyang@sysway.com]
>>>Sent: 30 August 2003 10:20
>>>To: nv-l@lists.tivoli.com
>>>Subject: [nv-l] MIB Bata Collector Problem and Very big snmpcol.trace
>>>
>>>
>>>Hello List:
>>>
>>>Netview 7.1.3+Win2000 Server +MS SQL Server2000+ Popular Patches.
>>>
>>>There are currently more than 50 routers in my customers enviroment 
>>>and I have set the Mib datacolletor to collect data for all the 
>>>CisocDevices for avgBusy5, BandwitdthUtilHdx, ifInErrors, 
>>>ifOutErrors, BitsIn, BitsOut etc. which are all standard mib-2 OID or
>>>      
>>>
>
>  
>
>>>default Cisco OID or MIB Expression provided by Netview. When I use 
>>>sql to query the collected data in sql2000, I find that for a Cisco 
>>>7507, there are more than 300 entries for avgBusy5, but for some 
>>>other cisco 3664, 3662 there are much less entries and even there is 
>>>none!!!
>>>
>>>And for only less than one week, the snmpcol.trace has grown into a 
>>>monitor with the size up to 400Mb. I can not open it with a notebook!
>>>      
>>>
>
>  
>
>>>But I am quite sure what are recorded in the snmpcol.conf. it must be
>>>      
>>>
>
>  
>
>>>something like this "Thur. Aug 14 15:29:39  : Deferring SNMP 
>>>collection of avgBusy5.0 on
>>>        10.10.30.200 60 minutes (1.00 hours).  Consecutive deferral 
>>>#1. "
>>>
>>>How to make snmpcollect get data succefully every time it collects 
>>>configured OID values? If it can not do it successfully all the time,
>>>      
>>>
>
>  
>
>>>in the following .conf, how to make the Deferal interval shorter to 5
>>>      
>>>
>
>  
>
>>>minture?
>>>
>>>Collecting data correctly is very important in this scenario!
>>>
>>>The following is a sample snmpcol.conf
>>>
>>>############## beginning ########################
>>>MIB .1.3.6.1.2.1.2.2.1.11 .* ifInUcastPkts pkts/sec COUNTER S hbyang
>>>
>>>W 10.10.10.* 0xffffffff 3600 > 10000.000000 <= 50.000000  s 58720263
>>>
>>>MIB .1.3.6.1.2.1.2.2.1.17 .* ifOutUcastPkt units/sec COUNTER S hbyang
>>>
>>>W 10.10.10.* 0xffffffff 3600 > 10000.000000 <= 50.000000  s 58720263
>>>
>>>MIB .1.3.6.1.2.1.2.2.1.14 .* ifInErrors errors/sec COUNTER R hbyang
>>>
>>>C smartset:Routers 0xffffffff 1800 > 10.000000 <= 90.000000  s 
>>>58720263
>>>
>>>MIB .1.3.6.1.2.1.2.2.1.20 .* ifOutErrors errors/sec COUNTER S hbyang
>>>
>>>W 10.10.10.* 0xffffffff 3600 > 10.000000 <= 90.000000  s 58720263
>>>
>>>MIB .1.3.6.1.2.1.11.1 0 snmpInPkts units/sec COUNTER S hbyang
>>>
>>>W 10.10.10.* 0xffffffff 3600 > 10.000000 <= 70.000000  s 58720263
>>>
>>>MIB BandwidthUtilHdx .* BandwidthUtilHdx units EXPRESSION R hbyang
>>>
>>>C smartset:Routers 0xffffffff 1800 > 20.000000 <= 75.000000  s 
>>>58720263
>>>
>>>MIB .1.3.6.1.4.1.9.2.1.58 0 avgBusy5 units INTEGER R hbyang
>>>
>>>C smartset:CiscoDevices 0xffffffff 1800 > 90.000000 <= 75.000000  s 
>>>58720263
>>>
>>>MIB .1.3.6.1.4.1.9.2.1.46 0 bufferFail units INTEGER R hbyang
>>>
>>>C smartset:CiscoDevices 0xffffffff 1800 > 0.000000 <= 0.000000 x s 
>>>58720263
>>>
>>>MIB .1.3.6.1.2.1.6.9 0 tcpCurrEstab units GAUGE R hbyang
>>>
>>>C smartset:WebServers 0xffffffff 1800 > 0.000000 <= 0.000000 xA s 
>>>58720263
>>>
>>>#################### End 
>>>##############################################
>>>
>>>Thank you all!
>>>
>>>Cordially
>>>
>>>Bruce Yang
>>>0086-755-26743243
>>>hbyang@sysway.com
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com For 
>>>additional commands, e-mail: nv-l-help@lists.tivoli.com
>>>
>>>*NOTE*
>>>This is not an Offical Tivoli Support forum. If you need immediate 
>>>assistance from Tivoli please call the IBM Tivoli Software Group help
>>>      
>>>
>
>  
>
>>>line at 1-800-TIVOLI8(848-6548)
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com For 
>>>additional commands, e-mail: nv-l-help@lists.tivoli.com
>>>
>>>*NOTE*
>>>This is not an Offical Tivoli Support forum. If you need immediate 
>>>assistance from Tivoli please call the IBM Tivoli Software Group help
>>>      
>>>
>
>  
>
>>>line at 1-800-TIVOLI8(848-6548)
>>>
>>>      
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
>>For additional commands, e-mail: nv-l-help@lists.tivoli.com
>>
>>*NOTE*
>>This is not an Offical Tivoli Support forum. If you need immediate 
>>assistance from Tivoli please call the IBM Tivoli Software Group help 
>>line at 1-800-TIVOLI8(848-6548)
>>    
>>
>
>= = = = = = = = = = = = = = = = = = = =
>                       
>
>        致
>礼!
> 
>                                
>        Haibo Yang
>        hbyang@sysway.com
>          2003-09-02
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
>For additional commands, e-mail: nv-l-help@lists.tivoli.com
>
>*NOTE*
>This is not an Offical Tivoli Support forum. If you need immediate
>assistance from Tivoli please call the IBM Tivoli Software Group help
>line at 1-800-TIVOLI8(848-6548)
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
>For additional commands, e-mail: nv-l-help@lists.tivoli.com
>
>*NOTE*
>This is not an Offical Tivoli Support forum. If you need immediate
>assistance from Tivoli please call the IBM Tivoli Software Group
>help line at 1-800-TIVOLI8(848-6548)
>
>
>
>  
>

-- 
Tivoli Certified Consultant & Instructor
Skills 1st Limited, 2 Cedar Chase, Taplow, Bucks, SL6 0EU, UK
Tel: +44 (0)1628 782565
Copyright (c) 2003 Jane Curry <jane.curry@skills-1st.co.uk>.  All rights 
reserved.



---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com

*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)


<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web