[Top] [All Lists]

RE: [nv-l] Flooding TEC

To: "Delaire, Patrick" <delairep@aetna.com>, <nv-l@lists.tivoli.com>
Subject: RE: [nv-l] Flooding TEC
From: "Ray Westphal" <westphal2002@charter.net>
Date: Tue, 17 Jun 2003 19:39:38 -0500
Delivered-to: mailing list nv-l@lists.tivoli.com
Delivery-date: Wed, 18 Jun 2003 08:54:58 +0100
Envelope-to: nv-l-archive@lists.skills-1st.co.uk
Importance: Normal
In-reply-to: <42ECCCDA0A4E0D4EB2CA941C442785446E2723@MDDP-MSG-001.aeth.aetna.com>
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
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@aetna.com]
Sent: Tuesday, June 17, 2003 3:38 PM
To: nv-l@lists.tivoli.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@Aetna.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
<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web