On Wednesday, April 15, 2026 11:21:52 AM Eastern Daylight Time Paul Moore wrote: > On Wed, Apr 15, 2026 at 11:19 AM Paul Moore <[email protected]> wrote: > > On Tue, Apr 14, 2026 at 11:45 PM Steve Grubb <[email protected]> wrote: > > > On Friday, April 10, 2026 5:34:08 PM Eastern Daylight Time Paul Moore wrote: > > > > On Mon, Mar 23, 2026 at 11:07 AM Ricardo Robaina > > > > <[email protected]> > > > > > > wrote: > > ... > > > > > ... compliance-driven systems that must use a finite backlog limit for > > > memory safety but cannot tolerate dropped events ...> > > You must pick one of those two requirements, or at the very least > > prioritize them; it is simply impossible to both limit the backlog > > queue and require zero dropped events. > > To be perfectly honest, it's also impossible to require zero dropped > events. Even in the most extreme configurations where the admin > decides to panic the system, that only happens once the system reaches > the point where it is dropping events. We try *really* hard to not > drop events, but it is always going to be a possibility.
You're helping make the point. Those administrators have decided reliable auditing is more important than system availability. backlog_max_depth gives them the one thing they currently lack: advance warning. If the high-water mark is consistently approaching the backlog limit, they have actionable information to raise the limit, reduce audit rule coverage, or address the underlying load - before the system goes down. These are exactly the users who would benefit the most from this metric. -Steve
