KBI 310096 When Good Rules Go Bad
Version
All
Date
2 Sep 2007
Summary
A brief article on important rule features.
Technical Background
While rule creation is generally a simple point-and-click process, over time even the best defined rules can be modified beyond all definition.
After all, easily defined rules are also easy to modify.
Generally it’s someone “just tweaking some settings” without considering the possible results.
Being aware of the features below will greatly assist in keeping your optimal configuration.
- Do you want to report on the metric being gathered by a Windows performance rule? If so, make sure you tick
the “Save Performance Data To The Argent Predictor” option.
- If you want to be alerted every time a rule breaks – even if you have already been notified about that
particular event – make sure to use the “Post Event even if same event is still
Outstanding” option.
If this option is left un-ticked, you will be alerted once per event detected
(except, of course, for any escalation alerts you may choose to configure).
- To generate service SLA reports from Windows Service Rules, just use the “Save Service
Uptime data for Trend Analysis
” option. - Instead of configuring a Windows Service Rule for each critical Windows service, you could try using the
“Alert if any Auto-Started Service is in Stopped Mode” option.
- If false alerts are being returned from your Relators, go back to basics and double-check the metric being
defined in the Rule. You may not have changed anything, but someone else could have.
-
In some rules you can be alerted if the Argent cannot access the monitored metric. For example, in the Argent SQL
Monitor you can use the “Rule is broken if failed to connect to SQL Server” option.
Keep in mind using this extensively can result in an “alarm storm” when a SQL server
goes down.
- When monitoring SNMP traps, you can include the details of the trap in your alerts by using the
“Include The Description Of SNMP Monitor In Event Details” option.
Resolution
N/A