Tivoli Netcool Probe Rules best practices.
This paper analyzes Tivoli Netcool’s event processing methodology and asserts that the
greatest threat to the useful lifespan of the rules files is natural entropy. Rule entropy is
enabled by:
• Configuration Flexibility via the rules files programming syntax.
• Code obfuscation:
o The uncoupling of knowledge management, which
describes the meaning/purpose of the rules files
code.
o Poor presentation means for both meaning and
function of the rules.
o Lack of audit ability of the rules.
To combat entropy and extend the useful lifespan of the rules files, additional best practices are proposed. Due to depth of the material, the best practices, case study, and future direction of event management is presented first. For those with a deeper interest
the argument, theory, and proof behind these best practices are presented later in the paper.
Impact Alternatives
There are alternatives to purchasing Impact. Many NOCs require only simple automated diagnostics, notifications, and/or escalation
processes. The purpose of this document is to explore Impact alternatives for these cases through either:
• Omnibus Automations and Database Fields
• Probe Rules and Database Fields
• Customized Scripts and Database Fields
Several case studies are provided within this document that fully document how this is done:
• Lights Out NOC: Automated notification and escalation.
• XinY: Flagging X Events occurring in Y period of time.
• Event Audit: What policy/automation/probe touched which events when.
• Impact Replacement: A Impact-like PERL script that emulates Impact behavior. Procedures to emulate policies can be written and embedded in the script to replace Impact functionality.
This module will find the ITNM entityID of a given router's interface by using the inhereted routine called find_id_by_ifName or find_id_by_ifIndex. It will also give you the current monitoring status of that entityID via the monitoring_ctl routine along with the ability to turn monitoring off or on via the same routine. Contributed by Mike Clark
This module will find the ITNM entityID of a given router's interface by using the inhereted routine called find_id_by_ifName or find_id_by_ifIndex. It will also give you the current monitoring status of that entityID via the monitoring_ctl routine along with the ability to turn monitoring off or on via the same routine. Contributed by Mike Clark
