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 <cars...@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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 

Attachment: signature.asc
Description: Message signed with OpenPGP

_______________________________________________
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to