Bug #7775: Event aggregation in reports seems broken (recurrence mechanism) - Mentat - Homeproj: Redmine for CESNET

Actions

Copy link

Bug #7775

closed

Event aggregation in reports seems broken (recurrence mechanism)

Added by Radko Krkoš 3 months ago. Updated about 1 month ago.

Status:

Closed

Priority:

Normal

Assignee:

Jakub Judiny

Category:

Design

Target version:

2.13.2

Start date:

09/06/2024

Due date:

% Done:

Estimated time:

To be discussed:

Yes

Description

There are issues with recent reports on mentat-dev, where there are two entries for a single IP address, one supposedly original, one supposedly recurring, with the timeframes in close succession.
Some examples:
https://mentat-dev.cesnet.cz/mentat/reports/206992/show [M20240905EL-RDN5O]
https://mentat-dev.cesnet.cz/mentat/reports/206991/show [M20240905EL-2VASC]

Also, there is the minor issue of both entries being numbered as 1.

Related issues

Actions

Copy link

Updated by Jakub Judiny 3 months ago

Just a note: Numbering of entries resets for the recurring events section. I think it makes sense, as the two sections are visually separated by a text.

Actions

Copy link

Updated by Jakub Judiny 3 months ago

Assignee set to Jakub Judiny
Target version changed from Backlog to 2.13.2

Actions

Copy link

Updated by Jakub Judiny 3 months ago

Related to Bug #7759: Reporter doesn't update thresholds in some cases added

Actions

Copy link

Updated by Jakub Judiny 2 months ago

Status changed from New to Resolved

Actions

Copy link

Updated by Rajmund Hruška 2 months ago

Status changed from Resolved to Feedback

Is that really an issue?

On 30 Aug at 18:20, this report was created. Consequently, a new record was created in the thresholding table.

2024-08-30 18:20:18,880 mentat-reporter.py [1359799] INFO: Updated thresholding cache with record - TTL=2024-09-05T16:20:00|RLP=2024-09-03T16:20:00|THR=2024-08-30T16:20:00|KEY=recon-scanning+++2001:xxxxxxxxxxxxxxxxxxxxxxx

Then every day at 18:20, mentat-reporter checked the events from the previous 24 hours and thresholded the ones with the same event class and source IP address.

On 5 Sep at 18:20, thresholding period ended. Instead of thresholding the events found within the last 24 hours (4 Sep 18:20 - 5 Sep 18:20), those events were marked to be sent. Additionally, all thresholded events up to that moment (until 4 Sep 18:20) were retrieved from the database and sent together with those new events.

Actions

Copy link