Optimization #5123
closedBug #5124: alerts: 5.0.8/6.0.4 count noalert sigs towards built-in alert limit (5.0.x backport)
alerts: use alert queing in DetectEngineThreadCtx (5.0.x backport)
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.
JL Updated by Jeff Lucovsky about 4 years ago
- Copied from Optimization #4943: alerts: use alert queing in DetectEngineThreadCtx added
JF Updated by Juliana Fajardini Reichow about 4 years ago
- Related to Optimization #5178: detect/alert: improve packet alert queue handling added
JF Updated by Juliana Fajardini Reichow almost 4 years ago
- Assignee changed from OISF Dev to Juliana Fajardini Reichow
- Target version set to 5.0.10
JF Updated by Juliana Fajardini Reichow almost 4 years ago
- Status changed from New to In Progress
JF Updated by Juliana Fajardini Reichow almost 4 years ago
- Status changed from In Progress to In Review
PR for review: https://github.com/OISF/suricata/pull/7379
JF Updated by Juliana Fajardini Reichow almost 4 years ago
- Subject changed from alerts: use alert queing in DetectEngineThreadCtx to alerts: use alert queing in DetectEngineThreadCtx (5.0.x backport)
VJ Updated by Victor Julien almost 4 years ago
- Parent task changed from #5120 to #5124
JF Updated by Juliana Fajardini Reichow almost 4 years ago
- Status changed from In Review to Closed
Merged PR: https://github.com/OISF/suricata/pull/7394