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: mathias.g...@travelping.com
> 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:  i...@travelping.com
> 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

Reply via email to