Don Seitz wrote:
> I've seen this before but can't find it now. How many events(traps) can
> Netview handle vs the TEC?
> I thought Netview was around 6000 per minute and the TEC was like 100 per
> minute...
>
> I am making recommendations on where correlation should happen, someone
> here wants to do all correlation at the TEC, I tried to explain that the
> TEC can not handle all the traps that NetView can.
>
> Please give me good information to work with
>
I will try.
You are correct. When you are doing correlation, TEC is slower. Howver there
are advantages to using TEC. For one thing, the Netview daemon that does
correlation does so by keeping events in memory. TEC uses database storage.
If you want to correlate interface up with interface down, network up with
network down, etc, in Netview, you are limited with how long you can correlate
these things by the amount of memory you have. With TEC, you can keep it in
the database for days I suppose, and correlate the up event with the previous
down, even if TEC crashes in between. This would be impossible to do with
Netview (if nvcorrd dies, the memory is released and the previous events are
lost and cannot be correlated).
Since TEC is slow, make sure you filter all you can in Netview before TEC sees
it. Sending 100 traps per second will bury TEC, it will get way behind. Here
are the rules I like to live by:
1. Filter as close to the source as possible. For example, if a node is
sending lots of traps about some unimportant event, turn it off at the
node instead of filtering it out upstream.
2. Never forward any trap (or event) that no one will do anything about. For
example, if no one is going to do anything about network down events,
don't send them.
3. Start out by turning all traps off except for those you *know* will be
needed. If someone has a requirement for a trap to be turned on, make
sure that person has a real need for that trap. The best way to do this
is to require them to fill out some form that will detail what action to
take when the trap is recieved. That requires them to think more about
what they really need.
4. As network or node problems are resolved, try to find a way that would let
you know before hand that the problem will re-appear. If you can turn on
a trap, or poll for a condition, do it and add it to future forwarded
events.
If you follow this, your events will be usefull from the start. If you turn on
everything, you can't see the events you need because they are buried in those
you don't need.
>
> Thanks
>
> Don A. Seitz
> __/__/__/ __/_/ __/ __/__/__/
> Network Systems Consultant __/ __/ _/ __/ __/
> don_seitz@ins.com __/ __/ _/ __/ __/__/__/
> pager 1-800-INS-1INS __/ __/ _/__/ __/
> www.ins.com __/__/__/ __/ ___/ __/__/__/
--
Ray Schafer | schafer@tkg.com
The Kernel Group | Distributed Systems Management
http://www.tkg.com
|