Hi Ruben, Configuration looks allright. And it can't supposedly happen with libpcap that you have packets for the current (and/or future time slots) when writing to the file: this might happen with nfacctd instead, ie. in case NetFlow timestamps are in future because of routers not being NTP sync'd.
I was wondering if plugin_buffer_size is not maybe too much for your scenario but then again you would not see a smaller amount of packets before a larger one. Maybe worth trying reducing it anyway and see if this has any effect. What pmacct version you are running? Should the buffering idea above not work, would it be an option to get temporary remote access to your box for some troubleshooting? Cheers, Paolo On Tue, Feb 04, 2014 at 08:31:42AM +0100, Ruben Laban wrote: > Hi, > > I'll start with my config: > > daemonize: true > pidfile: /var/run/pmacctd.pid > syslog: daemon > aggregate: dst_host > interface: eth5 > plugins: print[traffic] > print_output_file[traffic]: /tmp/traffic-eth5-%Y%m%d_%H%M.txt > print_output[traffic]: csv > print_refresh_time[traffic]: 60 > print_history[traffic]: 1m > plugin_buffer_size: 402400 > plugin_pipe_size: 402400000 > print_cache_entries: 999991 > print_output_file_append: true > print_history_roundoff: m > > What I observe is that every minute when the data gets flushed to > disk, 2 files get updated: the file for the previous minute, and the > file for the current minute. This leads to files containing the > following: > > # for i in /tmp/traffic-eth5-20140204_09* ; do echo $i: ; cat $i ; done > /tmp/traffic-eth5-20140204_0900.txt: > DST_IP,PACKETS,BYTES > 192.168.0.1,1496262,68828052 > 192.168.0.1,87794632,4038553072 > /tmp/traffic-eth5-20140204_0901.txt: > DST_IP,PACKETS,BYTES > 192.168.0.1,662553,30477438 > 192.168.0.1,45962195,2114260970 > /tmp/traffic-eth5-20140204_0902.txt: > DST_IP,PACKETS,BYTES > 192.168.0.1,1495840,68808640 > > (This time I'm using psend to send traffic through the monitored > interface, which uses a single destination IP.) > > As you can see this leads to "duplicate" entries (more than one > entry per aggregate). One way to get rid of the duplicates would be > to disable print_output_file_append, but then I'd lose data. > > I'm *guessing* that what happens is that when it's time to flush the > data of the previous interval to file, there's already data for the > current interval. And then pmacct decides to flush that part of the > data as well. Is this correct? > > Regards, > Ruben > > _______________________________________________ > pmacct-discussion mailing list > http://www.pmacct.net/#mailinglists _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
