For "Many to One" rules the values for table size, time span and event count have to be specified.
This article contains information to help to calculate the correct values and explains the relation between the values.
When those values are not set correctly incidents might not get created as expected.
For "Many to One" rules a cache is kept in memory to keep track of the number of events occuring. The cache is kept for the field(s) specified in the Tracking fields and will count the number of occurences of events which meet the criterias specified in the Event Filter of the rule.
Create a rule which is trying to track unique combinations of User Name and Source IP and if there are 500 events occurring in an hour matching the criteria in the Event Filter an incident gets created.
The following settings would apply to this rule:
Event count: 500
Time Span: 60 mins
Table Size: 100 000
Tracking fields: User Name, souce IP address
With those settings the SSIM Correlation manager will create a cache of size 200 (100 000 / 500 ) to track the event count of each unique user and IP combination
and it will use a LRU (least recently used) algorithm to update this cache.
For example when SSIM get first unique user & IP combination (User&IP1) it will create first entry in cache with count 1. When it gets second unique combination
(User&IP2), it will add second entry with count 1. After some time the cache will look as below:
The size of the cache table is calculated as below:
Cache Size = Table Size / Event Count
In the above case:
100 000 / 500 = 200
If SSIM now gets a new User & IP combination, then to accommodate it in the cache, one of the entries in the cache will be replaced using the LRU algorithm.
That means the 201st User & IP combination which occurs in the 60 mins (time span) will cause the entry which hasn't been updated for the longest to be dropped from the cache.
To avoid this either the event count has to be lowered, resulting in an bigger cache size, or the time span can be lowered, to avoid the cache from overflowing.
Another potential solution to this problem would be to introduce some grouping either by User or Source IP. Then multiple rules can be created using the grouping information in the Event Filter of the rules.