DNSTAP overload condition logging

Chris Buxton clists at buxtonfamily.us
Fri Nov 19 20:43:34 UTC 2021


Hi Carsten,

From our reading of the code, it appears that when the buffer fills up, it refuses to accept new entries. Older events are not overwritten, but newer events are refused. The fstrm_iothr_submit() function can return success, failure, or “fstrm_res_again”, which indicates the queue is full.

BIND stats reports two counters, dnstapSuccess and dnstapDropped. It appears that the dropped counter is incremented for either failure condition.

Regards,
Chris

> On Nov 18, 2021, at 9:50 PM, Carsten Strotmann <carsten at strotmann.de> wrote:
> 
> Hi,
> 
> how can a BIND 9 operator detect an DNSTAP overload condition?
> 
> My understanding is that BIND 9 worker threads write DNSTAP information
> into a circular buffer in memory, which is that read by a different
> thread to write out the data (to file or socket).
> 
> Is there any indication to the user (log message, marker in DNSTAP data)
> in the situation where BIND 9 receives more DNSTAP events than it could
> write out, so that older events get overwritten in the buffer?
> 
> I've read dnstap.c and I could not find a hint, but I've could missed
> it.
> 
> Greetings
> 
> Carsten
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20211119/ce36b21b/attachment.bin>


More information about the bind-users mailing list