Submit a ticketCall us
Home > Success Center > Log & Event Manager (LEM) > LEM - Knowledgebase Articles > LEM: Common issues with Rules

LEM: Common issues with Rules

Updated September 6, 2018


Learn more about common issues with Rules in Log and Event Manager (LEM).


  • All versions of LEM


Common issues with Rules

  • Rules trigger or fire excessively. If any rule triggers more than 200 or 300 times per day, it is considered to be excessive, and can be an issue because each time it consumes CPU, Memory, and Disk resources.
  • Rules that are misconfigured capture incorrect data, or no data at all,  when tested. This is logic based and needs to be reviewed very closely by running the query from the rule to review the event data that triggers the rule to commit the action.
  • Rules that are set to incorrect timing can use too many resources or fail to trigger. If you have settings in the Correlation Time, they should be checked to make sure they would actually trigger and initiate the expected action on time without causing a performance issue. For more information, see the explanations below.

Rules settings

  • Number of Events

    If the number of events set within the time frame is incorrect, it can prevent the rule from triggering and will only commit an action on the last received event. This means that if you set the number of events to two instead of one, and the two events do not occur within 30 seconds, the rule would not commit the action, and only the second event within 30 seconds would be recorded and processed from the events triggering the rule. All events before the final event work as a counter, but their information does not get passed over to emails, incident alerts, or inferred alert actions.

  • Events Within

    If the timing on the Events Within is changed, it expands or contracts the time frame that the events can occur within to trigger the rule. Setting these to too wide or too narrow can cause the rule not to trigger, or to stay open, and consume resources. It is recommended to not go below 10 seconds, and in almost 100 percent of  your rules, they should not go above 1-2 minutes. Some of our template rules do not follow this advice, but those are special situations that require a lot of testing to make sure they will work correctly in the right circumstance. Otherwise, our advice is to stick to the time frames mentioned above.

  • Response Window

    This setting tells LEM how long to wait for the event to cross the network from your devices before it fails to trigger the rule.

    SolarWinds recommends that you never change this setting unless you have a known network transfer timing issue. Most customers do not need to change this setting.

  • Other Correlation Time information

    When a rule is set to correlate with more than one event, there is an option to Set Advanced Thresholds. This option allows the rule to isolate the incoming event correlations further by subfields, such as EventName.Subfield. For example, if your rule is based on UserLogonFailure events, and you are basing the rule trigger on two events within 30 seconds, and a response window of five minutes, click the gear icon on the top right of the Correlation Time box in the rule, select UserLogonFailure, and then in the subfields, select DestinationAccount. Then, in the dropdown options below, you select either Same or Distinct. In this example, if you select Same, the rule will only trigger if the same username fails to log in two times within 30 seconds. If you choose Distinct, every username must be a different one in order to trigger this rule. The first option (Same) might be a better pick for setting the advanced thresholds. For more information on this topic, see Manage Rules.



Last modified