Project

General

Profile

Actions

Optimization #4943

closed

Bug #4941: alerts: 5.0.8/6.0.4 count noalert sigs towards built-in alert limit

alerts: use alert queing in DetectEngineThreadCtx

Added by Victor Julien almost 3 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Normal
Target version:
Effort:
Difficulty:
Label:

Description

Currently each alert is written directly to Packet::alerts during rule evaluation. Then at the end of the detection run for a packet, PacketAlertFinalize removes entries again, when applying thresholding, suppression and noalert. This leads to the issue in #4941 but is often also not very efficient esp when there are multiple rules to remove.

The idea of this ticket is to use a per DetectEngineThreadCtx specific queue of some sort to store the alert "candidates" and have PacketAlertFinalize only write the final alerts to the Packet structure.


Related issues 3 (1 open2 closed)

Related to Suricata - Documentation #5274: devguide: document how the alert flow worksIn ProgressJuliana Fajardini ReichowActions
Copied to Suricata - Optimization #5123: alerts: use alert queing in DetectEngineThreadCtx (5.0.x backport)ClosedJuliana Fajardini ReichowActions
Copied to Suricata - Optimization #5127: alerts: use alert queing in DetectEngineThreadCtx (6.0.x backport)ClosedJuliana Fajardini ReichowActions
Actions

Also available in: Atom PDF