Good point, Ray. If you have an MLM as a trap receiver, then you could
solve your problem by implementing thresholding there, rather than using
the NetView-to-TEC ruleset to do it. The MLM would provide a way to
control not only the flooding in TEC but also the flooding in NetView
itself. An excellent suggestion.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and NT
Tivoli Software / IBM Software Group
"Ray Westphal"
<westphal2002@cha To: "Delaire, Patrick"
<delairep AT aetna DOT com>,
rter.net> <nv-l AT lists.tivoli DOT com>
cc:
06/17/03 08:39 PM Subject: RE: [nv-l] Flooding
TEC
Hello Patrick.
You don't mention a trap rate or a duration of the trap storm. I know you
are talking about overwhelming TEC, but if we reduce the traps forwarded to
TEC somehow, the bottleneck will likely move to the NetView server's trapd
daemon. If the trap rate is too high for too long, trapd will fail or traps
will fill the queue. Then they are delayed for so long they become useless
to provide any warnings.
Remember, the NetView server has to process all the traps received even if
you chose not to forward them or not even log them. So running a ruleset
that referenced a ksh or perl script to limit the events forwarded, still
means trapd could fail.
You have disabled MLM which is often suggested as a filtering mechanism
when a NetView server is getting overwhelmed with traps. If you cannot
enable MLM, I suggest you start by limiting more of the traps sent by your
IVR. Hopefully many of the traps could be eliminated. If many of them are
threshold traps, raise the threshold until you find a comfortable level.
Good luck and let us know what happens.
Ray Westphal
Enterprise Rent-A-Car
[Ray Westphal] -----Original Message-----
From: Delaire, Patrick [mailto:delairep AT aetna DOT com]
Sent: Tuesday, June 17, 2003 3:38 PM
To: nv-l AT lists.tivoli DOT com
Subject: [nv-l] Flooding TEC
We are running AIX 4.3 with Netview 7.1.3. Our new IVR (voice
response system) is sending SNMP data to our Netview platform
which is then forwarded to TEC. The problem we are experiencing a
times is our IVR application/s including speechworks and conversant
servers machine gun both Netview and TEC when we experience problems.
This results in TEC buffering messages and eventually
stop functioning. The voice response people cannot do any more
filtering from the source. Does any one on this list have any
suggestion
on how we could stop 'machine gun' type alert processing either on
the Netview side or TEC side.
Side note: We have filtering on TEC but only after the alerts has
been processed through TEC. The buffering issue occurs before the
alerts
are processed, which at times bring down TEC.
P.S. We have disabled MLM.
Automation & Systems Monitoring
Enterprise System Management
Aetna Information services
E_mail: DelaireP AT Aetna DOT com
phone: 860-636-8126
Fax: 860-636-6807
This e-mail may contain confidential or privileged information. If you
think you have received this e-mail in error, please advise the sender by
reply e-mail and then delete this e-mail immediately. Thank you. Aetna
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe AT lists.tivoli DOT com
For additional commands, e-mail: nv-l-help AT lists.tivoli DOT 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)
|
