...that's mean I'm the only one that switched from linux to windows.
main reasons:
- no rdbms support, (we need it for TDS)
- problems with MLM's configuration (netview try to set mib for
trapdestination to netview_IP+41472/tcp instead of 162 - I opened a PMR
and now there is an APAR for this)
- there is no netview native client!
anyway now I have lots of problems with netview@windows too:
- native client could not read maps from server (is this normal???)
- now netmon doesn't configure mlm anymore! IBM told me this is normal
for windows.. so I have to configure MLM manually by editing its
configuration file or by snmp set I guess (??!!) but I don't know how to
handle the list of nodes dicovered my a MLM
- there is no RIM support too so I keep all in some Access databases
so there are pros and cons for Linux and for windows too ..but probably
the linux version will be the winner in the future
Lucian
Jane Curry wrote:
>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)
>>
>>
>>
>>
>>
>>
>>
>
>
>
---------------------------------------------------------------------
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)
|