Troubleshooting
Problem
Note: Converted to internal use only. Note that the use-case where these considerations are helpful are only those where customers are overcomplicating rules by combining otherwise simple filters into a single ariel filter test, making that test more expensive than necessary.
Performance Degradation seen at Custom Rule Engine due to inefficient use of Ariel Filter tests.
Performance Degradation seen at Custom Rule Engine due to inefficient use of Ariel Filter tests.
Cause
The most common cause of performance degradation in the Custom Rule Engine is an expensive rule that creates a bottleneck. However, there are some event match rule scenarios where there is no single rule causing the problem but is due to the overall way rules are constructed. That means there is a common practice that is not efficient but is spread across multiple rules.
The most efficient tests for custom rules are those tests, which, are built specifically for the custom rule engine. We also can use
and when the event matches this search filter tests to use ariel filter syntax when a built-in test is not available. Since the and when the event matches this search filter tests are borrowing code from ariel, by using built-in tests when available is always more efficient than using the ariel tests.Diagnosing The Problem
Here are some examples of rules that cause performance degradation.
Note: A single rule like the examples might not cause harm to custom rule engine performance. The problem arises when these patterns are consistently used in the overall way rules are designed.
- Using event matches filter instead of built-in tests.
Example 1: The test event matches cannot be used in this scenario because there is a built-in test for QID and Log Source Group.
Instead, use:
- Example 2: The test event matches cannot be used in this scenario either because there is a built-in test for Log Source Group, Log Source Type, and Category.
Instead, use:
- The third test is a good use of an
event matchesfilter. Since there is no built-in test for Event ID Testing several custom properties for a regex:
Therefore, in this scenario, all custom properties in the list are getting redundant information, and not all of them need to be tested, but only one. Each of the Custom Event Property (CEPs) needs to be reviewed in the log activity tab to confirm which is the Custom Property that is needed. It is advised to add extra tests before the regex test, as the regex test can be expensive by itself. Usually, the pattern is expected in a single QID. Adding a QID limit significantly reduce the number of events tested.
Resolving The Problem
Review your rules that use the
when event matches this search filter tests to identify any that are using criteria that could be converted to a built-in test.- Identify criteria in
when event matches this search filtertests that can be replaced by built-in tests.- Log in to the QRadar Console as admin user.
-
Select Use Case Manager.
- In the left pane, scroll down to the rule test and expand Test definition.
- Type in
event matches. - The right pane shows the list of rules that use the test
when event matches this search filter.
- Remove the identified criteria from the
when event matches this search filtertests. - Add extra built-in tests to replace the removed criteria.
Results
The built-in tests exactly replace the criteria removed from the
The built-in tests exactly replace the criteria removed from the
when event matches this search filter tests and improve the rule's performance in the custom rule engine.Document Location
Worldwide
[{"Type":"MASTER","Line of Business":{"code":"LOB77","label":"Automation Platform"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSBQAC","label":"IBM Security QRadar SIEM"},"ARM Category":[{"code":"a8m0z000000cwtiAAA","label":"Performance"}],"ARM Case Number":"","Platform":[{"code":"PF016","label":"Linux"}],"Version":"All Versions"}]
Was this topic helpful?
Document Information
Modified date:
07 March 2023
UID
ibm16569559