"Lemire, Mark" wrote:
> I am a co-worker of David Tremblay. Dave hurt his back (unrelated to
> Netview :) and is out today so I'll reply to the posts.
>
> You are correct that we mean the standard Events Window.
>
Do you *only* forward to TEC using scripts? You don't have any rulesets that
are used to forward events to TEC using the standard NetView Method? I had
this problem before (about 2 years ago). The symptoms were nvcorrd waiting
(zero CPU time), and nvserverd looping using much CPU time. It was a problem
related to TEC forwarding. We had a PMR opened, but I don't recall if we
recievced a fix or if the problem went away with an upgrade, but it is gone
now. It may not be the same as yours, escpecially if you don't forward
directly to TEC.
> The two Netview environments are identical with respect to the database,
> generally everything under /usr/OV including scripts that are called from
> Event Configuration. All network devices forward SNMP traps to both
> servers. We do no direct forwarding to TEC; rather via postemsg commands in
> the scripts. The scripts are all run in the background, so as not to
> interfere with trapd or ovactiond. An environmental variable is set which
> differs on the two servers -- that is how scripted events get forwarded
> differently to our production TEC, and debugging TEC.
>
> trapd.log shows relatively low incoming activity (just checked - 10 events
> in the last 5 minutes). In spite of the Events Window problem, as I
> mentioned trapd.log is normal, traps are being handled correctly and the
> scripts are forwarding to TEC just fine. nvserverd is still pegged at 50%
> of the total CPU load (2 CPUs).
>
> Mark Lemire
>
> -----Original Message-----
> From: James_Shanks@tivoli.com [SMTP:James_Shanks@tivoli.com]
> Sent: Tuesday, June 06, 2000 5:25 PM
> To: IBM NetView Discussion
> Subject: Re: [NV-L] Question concerning Netview Event History
> Window???
>
> I've given this some more thought, and I'll bet we have a
> terminological problem
> here. You said "Events HIstory" but I'll bet you don't mean that.
> I'm betting
> that what you really mean is the standard (current) events window,
> the one you
> get when you start the GUI or type in "nvevents" from the command
> line. Events
> History is a different application all together.
>
> Anyway, I seriously doubt if your two boxes are really identical,
> because then
> they would both be forwarding to TEC. Are they really? Even if
> they are, I'll
> also bet that the test box doesn't get nearly the same volume of
> traps that the
> production one does, correct?
>
> In any case if nvserverd is using 50% of the cpu, then he is one
> busy boy, and
> that can only mean that (a) traps are coming in at a fairly rapid
> rate, and
> that he has multiple event windows he's trying to send to, and I'll
> wager that
> he is also having difficulty sending to TEC, as well. Are you sure
> that TEC
> events are not being cached in /etc/Tivoli/TEC/cache? Are you sure
> that the
> last event you see in trapd.log that should be forwarded to TEC is
> not in the
> cache and that you can see it with wtdumprl over on the TEC?
> Because if you
> have TEC transmission problems that will most definitely slow
> nvserverd down to
> crawl and could produce the symptoms you are seeing.
>
> James Shanks
> Tivoli (NetView for UNIX and NT) L3 Support
>
> James_Shanks@tivoli.com on 06/06/2000 04:30:33 PM
>
> Please respond to IBM NetView Discussion <nv-l@tkg.com>
>
> To: IBM NetView Discussion <nv-l@tkg.com>
> cc: (bcc: James Shanks/Tivoli Systems)
> Subject: Re: [NV-L] Question concerning Netview Event History
> Window???
>
> Events History has nothing to do with trapd.log or current events
> being sent to
> TEC. trapd maintains the trapd.log, and nvserverd sends the events
> to TEC,
> after they have been processed by trapd and nvcorrd.
>
> Events History is maintained by a separate process which registers
> for traps
> from trapd, just like all the current event daemons do. That
> process is
> ovesmd, the ems_sieve_agent. He formats them and passes them to the
> ems_log_agent, ovelmd, who stores them in formatted form in
> /usr/OV/log/ovevent.log. That's where they are read from.
>
> And remember that Events History, unlike current Events, does not
> update
> automatically. Once you have done your initial Query, the contents
> of the
> window are fixed, until you refresh it by pulling down "Query"
> again and
> clicking "Display Event".
> Then they are updated with the current contents of the ovevent.log.
>
> So if this isn't working, I would first check whether your
> ovevent.log is
> growing and if not, whether the ems_log_agent and the
> ems_sieve_agent are still
> running. ovstatus should tell you that.
>
> James Shanks
> Tivoli (NetView for UNIX and NT) L3 Support
>
> "Tremblay, David A." <dtremblay@JHANCOCK.COM> on 06/06/2000 04:07:45
> PM
>
> Please respond to IBM NetView Discussion <nv-l@tkg.com>
>
> To: "'IBM NetView Discussion'" <nv-l@tkg.com>
> cc: "Lemire, Mark" <mlemire@JHANCOCK.COM> (bcc: James
> Shanks/Tivoli Systems)
> Subject: [NV-L] Question concerning Netview Event History Window???
>
> Hello all,
>
> I am currently working with support on this issue but I am wondering
> if
> anyone else has experienced this problem.
>
> Has anyone ever had their Event History Window stop taking in events
> but
> their trapd.log continue to run ok and even continue forwarding
> events to
> TEC?? All the Netview Daemons look ok for the exception of one that
> pegs
> the CPU at 50% which is nvserverd. After a reboot everything is ok
> for a
> day or so and then we are back into the same problem with the Event
> Viewer
> not picking up events anymore.
>
> This is the situation we are currently experiencing but their weird
> part is
> that our test/staging server which is supposed to be identical has
> not
> exhibited any of the symptoms I have mentioned above. The
> test/staging
> server even uses the exact same database that is copied over
> nightly!!!
>
> We are running NetView 5.1.1 (on purpose) with integration
> forwarding events
> to Tivoli/TEC on a Solaris 2.5.1 box with over 2 gig of memory.
>
> If anyone has any ideas, please reply.
>
> Thank you.
>
> David A. Tremblay John Hancock Financial Services
> Lead Systems Analyst Information Technology Services
> Enterprise Management Tools Technology Shared Services
>
> E-Mail: dtremblay@jhancock.com
>
>
> _________________________________________________________________________
> NV-L List information and Archives: http://www.tkg.com/nv-l
>
>
> _________________________________________________________________________
> NV-L List information and Archives: http://www.tkg.com/nv-l
>
>
> _________________________________________________________________________
> NV-L List information and Archives: http://www.tkg.com/nv-l
> _________________________________________________________________________
> NV-L List information and Archives: http://www.tkg.com/nv-l
--
Ray Schafer | schafer@tkg.com
The Kernel Group | Distributed Systems Management
http://www.tkg.com
|