Automatically Disabled Rules

A rule can be manually disabled by an administrator or automatically disabled by ESM. ESM automatically disables improperly written rules that would produce excessive or meaningless events.

The Rules resource tree on the Navigator panel displays a manually-disabled rule as greyed out (). An auto-disabled rule is displayed with a special icon (). It shows with the same disabled symbol overlaid by an ArcSight logo to indicate that the system disabled it.

When a rule is disabled, ESM generates an audit event indicating that this happened so that administrators can follow up as needed. See Rule Activations for more information on related audit events.

Tip: About the Rules Status dashboard:

ESM profiles rule performance by measuring their evaluation time on a sampling basis. You can view these results from the All Dashboards\ArcSight Administration\ESM\System Health\Rules\Rules Status dashboard, which includes a collection of data monitors reporting on different rules statistics. Based on information from this dashboard, manually disable rules which you deem expensive.

The Sortable Rule Stats data monitor on this dashboard does not include pre-persistence rules.

Why Rules are Automatically Disabled
Cause	Description
Rule is invalid	An invalid rule is automatically disabled and displayed as broken in the Navigator. If an administrator configures a rule or related resource in a way that “breaks” the rule and leaves it in an invalid state, the system automatically disables the rule. If a rule is disabled automatically due to an invalid configuration, an `Invalid Reason` field is displayed in the Rule Editor on the Inspect/Edit panel. When the rule is reconfigured to a valid state and enabled, the `Invalid Reason` field is no longer displayed. The `Invalid Reason` field is not displayed for rules that are manually disabled.
Rule is recursive	Rules that trigger themselves in a recursive loop is automatically disabled temporarily. A rule that is automatically disabled due to recursion is re-activated after a time frame that matches the aggregation time frame for the rule. (The default aggregation time frame is 2 minutes.) A rule can be inherently recursive due to a flaw in its design, or temporarily recursive because of some particular events involved. In the first case, temporarily disabling the rule often clears out the problem, and allows the rule to run normally when it is re-activated. If the rule is inherently recursive, it is continuously re-enabled and auto-disabled. The solution in this case is to redefine the rule logic and redeploy it, since it is effectively a “broken” rule.
Excessive event alias matching	This is the number of events matching that alias, independent of other defined aliases. The default limit for event matching is 100000.
Partial event matching	If more than one event alias is defined in the rule, partial matching is the number of events matching the aliases defined before the current one, and for the current one, and for their join condition (if present). The default limit for partial matches of any event aliases is 100000.
Generated event counts	This is the number of correlation events generated. The default limit is five correlation events for each base event the rule processes.
Base event counts	The number of base events used by the rule to generate correlation events.
Time unit counts	This is the number of time units (minutes) that passed since the current rule activated. The default is 1000 correlation events in one time unit.
Number of rule triggers exceeds configured limits	Number of rule triggers exceeds configured limit of 1000 firings per minute for the same aggregated values. A rule that exceeds configured limits show as disabled ()in the Navigator, and offer a right-click option for the user to manually disable it permanently. To change this setting, do so in the `server.properties` file. For example, if you want the limit to be 10000 instead of 1000, enter this setting: `rules.max.fan-out.time-unit.ratio=10000` For information on how to set properties, refer to the Configuration chapter of the ESM Administrator's Guide, topic on "Managing and Changing Properties File Settings." Note: A rule in this state continues to attempt to run until the user disables it permanently by right-clicking it in the Navigator and choosing Disable.
CPU usage has exceeded threshold	ESM takes the aggregated evaluation time of all deployed rules. If a rule's evaluation time exceeds 50% of this aggregated time, the rule is automatically disabled. To change this setting, do so in the `server.properties` file. For example, if you want 60% instead of 50%, enter this setting: `rules.max.fractional.cpu=60` For information on how to set properties, refer to the Configuration chapter of the ESM Administrator's Guide, topic on "Managing and Changing Properties File Settings."

For rules that are disabled automatically, right-click the disabled rule and select Disable so that the rule is permanently disabled until you can fix the rule. If you don’t manually disable these rules, they continuously attempt to run, then are enabled and disabled by the system in a cyclical manner. This can impact system performance.