-
-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
file logger: buffer still full despite "chan-buffer-size" changes #636
Comments
Could you share more details ?
|
Sure! Thanks Denis. We are using 0.41.0. Config:
Log files:
The error would repeat over and over:
|
(Just to give a volume indication, feeding on 34M dnstap file results in " dnstap - logger[fileall] buffer is full, 2003 packet(s) dropped" with the configuration file from the previous message) |
In your case, the bottleneck is the It occured because this logger is too slow regarding the amount of incoming data. To avoid to block the collector processing, the overhead of packets are dropped. Could you try some adjustments
chan-buffer-size: 131070 |
Good thinking, thank you! After testing, it turns out that:
For the record, the postrotate script we use is:
I will continue to investigate what is causing the bottleneck there and update this ticket with any possible solution. |
@arvchristos @romainw The best way will be that the pdnssoc-cli uses natively the 'flat-json' model generated by DNScollector to avoid a new JSON generation from an external script. Also the I think that the pDNSSOC and DNScollector integration can be greatly improved to support a higher load :) |
Hey @dmachard ! The main reason why we relied on an external script for JSON generation is to be able to store only the required for correlation fields and save on size. I am not sure whether there is any transformer to remove fields from the JSON output but it seems useful for space optimization (combined with We essentially need to store minified logs so that we can run correlation on past data with new indicators of compromise, apart from the live correlation we do with various other sources that |
Great idea, can you open a ticket to track this? |
Sure, here it is: |
Custom JSON relabeling has been implemented. It's will be implemented in next release v0.43.0. |
Hi @dmachard Im seeing similar issue with v1.0.0 while writing it to a local file. if you can suggest any tweak is needed in the config file. `global: pipelines:
Oct 07 18:06:16 dnscollector go-dnscollector[3564495]: WARNING: 2024/10/07 18:06:16.724111 worker - [tap] (conn #1) dnstap processor - worker[file] buffer is full, 1596 dnsmessage(s) dropped Thanks. |
Hi @arvchristos @romainw, I pushed a fix in the head of the repository to ensure the post-rotate command no longer blocks execution. I think this should be helpful for you! |
Fixed in release 1.2.0. If you encounter any further issues, please feel free to open a new ticket. Thank you for your feedback! |
Many thanks for your time and effort with go-dnscollector!
We are using go-dnscollector as part of the pDNSSOC project (https://github.com/CERN-CERT/pDNSSOC)
We process incoming dnstap files for a number of resolvers with little/no control over the files size or content.
We feed go-dnscollectors with dnstap files in a directory "watched" by the ingestor. Each file is about 50MB in size.
Unfortunately we suffer from a buffer full, dropping packets error.
We typically loose hundreds of thousands of packets, and our logs are flooded with "buffer full" error messages.
We tried increasing the value of "chan-buffer-size" to a larger value (e.g. 10485760) but it does not change the amount of errors or the amount of lost packets in each error.
I am not sure this is a bug or just a configuration issue, or just us doing it wrong, or what we can do about this.
Any advice welcome.
Current configuration:
The text was updated successfully, but these errors were encountered: