Hi Mathias, I see now. Can you try with 'nfacctd_time_new: true' It will cause time-binning to use arrival time of the flow to the collector (that time should be reasonably close to flow end time and stamp_updated).
Let me know if any luck; if not, we can switch to unicast email and you could send me a sample of your flow data so to get a better idea of what could be possible. Paolo On Wed, Aug 30, 2017 at 11:10:50AM +0200, Mathias Gumz wrote: > Hi Paolo, > > > On Tue, Aug 29, 2017 at 05:00:34PM +0200, Mathias Gumz wrote: > >> > Currently I have set the "sql_history" and "sql_refresh_time" to 60s. I > >> > wonder, > >> > how the algorithm works. "sql_refresh_time" seems to scan the cache and, > >> > if > >> > needed, writes/updates an entry in the current bin. But what exactly is > >> > "sql_history" doing? Will there be only "one" entry of a certain flow > >> > which is > > > > Essentially sql_history makes stamp_inserted being added to the key. So, > > yes, this will ensure only "one" entry for a certain aggregate during > > the time-bin. > > > >> Also: currently I am trying to write to a new table every hour. So, I have > >> tables events0, events1, events2 etc. I have established a SSH-session > >> which > >> crosses the full hour (which started 00:55 and ends 01:05). I received the > >> NAT > >> event 4 for the created TCP connection in events0. The closing event (NAT > >> event > >> 5) for the session is also stored in events0. My expectation is events1. > >> Why is > >> that? > > > > You have tables events0, events1, events2, etc.: is that the actual name > > of the tables or just an example where 1, 2, etc. should be replaced by > > a timestamp filled in by pmacct? Also, basing on what assumption would > > you expect one event to go in events0, the other going in events1? Based > > on time? > > sql_table[natev]: events_%H > > I started the SSH-session at 0:55, the event is stored in events_0. The > SSH-session ends at 1:05. The hour part now would be "1" (events_1) but the > events_0 table is used. As you outlined above, the reason for this is that > the "stamp_inserted" field is used (at least that is my understanding). > > How can I enforce the desired behaviour to store the events in (effectively) > "timestamp_end" / "stamp_updated" based tables? Do I need something like > "sql_history_roundoff" or "nfacctd_pro_rating" (which would split the > transmitted bytes over all involved bins evenly? > > Thanks in advance, > -- > Mathias Gumz > > Email: [email protected] > Phone: +49-391-819099-228 > > ----------------------- enabling your networks ---------------------- > > Travelping GmbH Phone: +49-391-81 90 99 0 > Roentgenstr. 13 Fax: +49-391-81 90 99 299 > 39108 Magdeburg Email: [email protected] > GERMANY Web: http://www.travelping.com > > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 > --------------------------------------------------------------------- > > _______________________________________________ > pmacct-discussion mailing list > http://www.pmacct.net/#mailinglists _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
