Todd,
there are "best practices", James may actually say "rules" to follow when
writing rulesets.
1. If you need the output of a rule to feed another rule, then the output
should be an action that creates another snmp trap.
2. In the ruleset that is forwarding events to TEC, there should NEVER be
any kind of action in that ruleset. It should simply be deciding, should
I forward this or not. Nothing more. You can use thresholds in this
rule to help you decide. Leslie's earlier post made a lot of sense for
making this a smaller ruleset. Update the "source" in trapd to something
unique for just the events to forward. So now you have one event
attribute box and maybe a few threshold boxes pointing to a forward box.
The default pizza box should be block so you only forward events that make
it through the rule.
3. For the rules started in ESE.automation. You can split them into what
makes sense for maintaining them. You should not have a need to merge
them into one big one. The default pizza box should be block. There
should be NO forward boxes in this ruleset. These rules are for actions
that you feel netview must take. Every leg should end in a do not forward
box. If after some actions and checks you find you need to send
something to TEC, you should be generating a new trap that has the proper
"source" configured in trapd.conf.
4. If you are simply calling a script from a ruleset for a particular trap,
move it out of your ruleset and into trapd.conf. If you have multiple
NetViews, use addtrap to configure each one easily.
5. A technique I have used to setup NetView to send to TEC traps xxxx for
a specific list of nodes was.
a. create a file that holds the hostnames I care about
write a script that receives varbinds for this trap. the first thing
it does it grep the file with the hostname from trap. If not there, exit.
If it is there, then regenerate the trap with my own OID and trap number.
My TEC forwarding ruleset sees the regenerated trap...forwards it with no
more testing. This is efficient, only decision point is one grep
command. Second, the administrator only has to update the hostname file
when changes are needed, no ruleset editing or scripting needed. I have
used this to handle 10000s of traps without impact to the NV server.
update trapd.conf to call my script for a particular trap
Thanks,
Stephen Hochstetler shochste@us.ibm.com
ITSO Tivoli Coordinator - Austin
Office - 512-436-8564 FAX - 512-436-1991
|