Re: [pmacct-discussion] More precise flow timestamp
Hi Paolo, I have correct timestamp_start value and I will disable sql_history. In latest trail I found I missed aggregate 'timestamp_end'. But I noticed a weird thing that my timestamp_end was wrong: I also checked the post @2013. It seems ' timestamp_end' aggregate was already done. Do you have any idea? [root@LDeltaR1S9 ~]# sfacctd -l -P print -c timestamp_start,timestamp_end -r 1 INFO ( default/core ): Reading configuration from cmdline. INFO ( default/core ): waiting for sFlow data on 0.0.0.0: TIMESTAMP_STARTTIMESTAMP_END PACKETS BYTES INFO ( default/print ): *** Purging cache - START (PID: 6707) *** 2014-09-10 19:52:52.702513 1970-01-01 08:00:00.0 1 98 2014-09-10 19:52:52.702552 1970-01-01 08:00:00.0 1 98 Yours, TC -Original Message- From: pmacct-discussion [mailto:pmacct-discussion-boun...@pmacct.net] On Behalf Of Paolo Lucente Sent: Wednesday, September 10, 2014 9:14 AM To: pmacct-discussion@pmacct.net Subject: Re: [pmacct-discussion] More precise flow timestamp Hi, Yes, with the timestamp_start primitive you can get a timestamp per sFlow packet. If timestamps_secs config directive is set to false (which is default) then you get also residual time after secs populated (which is what you want). sql_history does not clash with the timestamp_start primitive, you can use both. Cheers, Paolo On Tue, Sep 09, 2014 at 12:14:12PM +, itria30...@itri.org.tw wrote: Hi Paolo and all, Hope this is right place to post my question. For recording flow’s corresponding timestamp I use sql_history primitive and my sfacctd.conf looks like: …… sql_dont_try_update: true sql_history: 1m !ql_history_roundoff: mh ….. The sql data I got mysql select * from acct_v9 limit 3; +-+---+--+--+-+--+---+---+--+++-+---+--+--+---+--+-+-+---+---+-+-+ | cos | etype | mask_src | mask_dst | tag | class_id | mac_src | mac_dst | vlan | as_src | as_dst | ip_src | ip_dst| port_src | port_dst | tcp_flags | ip_proto | tos | packets | bytes | flows | stamp_inserted | stamp_updated | +-+---+--+--+-+--+---+---+--+++-+---+--+--+---+--+-+-+---+---+-+-+ | 0 | 800 |0 |0 | 0 | unknown | 00:26:55:55:e0:06 | 80:71:1f:4c:be:01 | 100 | 0 | 0 | 10.100.1.2 | 140.96.27.220 | 53 |34504 | 0 | udp | 0 | 1 | 428 | 0 | 2014-09-09 19:39:00 | 2014-09-09 19:40:01 | | 0 | 800 |0 |0 | 0 | unknown | 00:26:55:55:82:84 | 02:a0:98:28:51:d9 | 98 | 0 | 0 | 10.98.1.32 | 10.98.1.22| 678 | 2049 |16 | tcp | 0 | 1 | 1522 | 0 | 2014-09-09 19:39:00 | 2014-09-09 19:40:01 | | 0 | 800 |0 |0 | 0 | unknown | 00:e0:81:ce:9b:10 | 80:71:1f:4c:be:01 | 236 | 0 | 0 | 10.236.39.1 | 140.96.27.144 | 22 |52098 |16 | tcp | 16 | 3 | 4566 | 0 | 2014-09-09 19:39:00 | 2014-09-09 19:40:01 | +-+---+--+--+-+--+---+---+--+++-+---+--+--+---+--+-+-+---+---+-+-+ 3 rows in set (0.00 sec) Flow are written into mysql every 1 second. (It’s nice to have such a timestamp for each flow.) And is there any more precise primitive or mechanism to use , for example, some timing information in packet header in millisecond precision? Thanks in advance. And good day :) TC Wu 本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。 This email may contain confidential information. Please do not use or disclose it in any way and delete it if you are not the intended recipient. ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists 本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。 This email may contain confidential information. Please do not use or disclose it in any way and delete it if you are not the intended recipient. ___ pmacct-discussion mailing list http://www.pmacct.net
Re: [pmacct-discussion] More precise flow timestamp
Hi TC, timestamp_end applies to NetFlow/IPFIX only. sFlow samples do not contain a start and an end time but only an observation time. Cheers, Paolo On Wed, Sep 10, 2014 at 12:04:27PM +, itria30...@itri.org.tw wrote: Hi Paolo, I have correct timestamp_start value and I will disable sql_history. In latest trail I found I missed aggregate 'timestamp_end'. But I noticed a weird thing that my timestamp_end was wrong: I also checked the post @2013. It seems ' timestamp_end' aggregate was already done. Do you have any idea? [root@LDeltaR1S9 ~]# sfacctd -l -P print -c timestamp_start,timestamp_end -r 1 INFO ( default/core ): Reading configuration from cmdline. INFO ( default/core ): waiting for sFlow data on 0.0.0.0: TIMESTAMP_STARTTIMESTAMP_END PACKETS BYTES INFO ( default/print ): *** Purging cache - START (PID: 6707) *** 2014-09-10 19:52:52.702513 1970-01-01 08:00:00.0 1 98 2014-09-10 19:52:52.702552 1970-01-01 08:00:00.0 1 98 Yours, TC -Original Message- From: pmacct-discussion [mailto:pmacct-discussion-boun...@pmacct.net] On Behalf Of Paolo Lucente Sent: Wednesday, September 10, 2014 9:14 AM To: pmacct-discussion@pmacct.net Subject: Re: [pmacct-discussion] More precise flow timestamp Hi, Yes, with the timestamp_start primitive you can get a timestamp per sFlow packet. If timestamps_secs config directive is set to false (which is default) then you get also residual time after secs populated (which is what you want). sql_history does not clash with the timestamp_start primitive, you can use both. Cheers, Paolo On Tue, Sep 09, 2014 at 12:14:12PM +, itria30...@itri.org.tw wrote: Hi Paolo and all, Hope this is right place to post my question. For recording flow’s corresponding timestamp I use sql_history primitive and my sfacctd.conf looks like: …… sql_dont_try_update: true sql_history: 1m !ql_history_roundoff: mh ….. The sql data I got mysql select * from acct_v9 limit 3; +-+---+--+--+-+--+---+---+--+++-+---+--+--+---+--+-+-+---+---+-+-+ | cos | etype | mask_src | mask_dst | tag | class_id | mac_src | mac_dst | vlan | as_src | as_dst | ip_src | ip_dst| port_src | port_dst | tcp_flags | ip_proto | tos | packets | bytes | flows | stamp_inserted | stamp_updated | +-+---+--+--+-+--+---+---+--+++-+---+--+--+---+--+-+-+---+---+-+-+ | 0 | 800 |0 |0 | 0 | unknown | 00:26:55:55:e0:06 | 80:71:1f:4c:be:01 | 100 | 0 | 0 | 10.100.1.2 | 140.96.27.220 | 53 |34504 | 0 | udp | 0 | 1 | 428 | 0 | 2014-09-09 19:39:00 | 2014-09-09 19:40:01 | | 0 | 800 |0 |0 | 0 | unknown | 00:26:55:55:82:84 | 02:a0:98:28:51:d9 | 98 | 0 | 0 | 10.98.1.32 | 10.98.1.22| 678 | 2049 |16 | tcp | 0 | 1 | 1522 | 0 | 2014-09-09 19:39:00 | 2014-09-09 19:40:01 | | 0 | 800 |0 |0 | 0 | unknown | 00:e0:81:ce:9b:10 | 80:71:1f:4c:be:01 | 236 | 0 | 0 | 10.236.39.1 | 140.96.27.144 | 22 |52098 |16 | tcp | 16 | 3 | 4566 | 0 | 2014-09-09 19:39:00 | 2014-09-09 19:40:01 | +-+---+--+--+-+--+---+---+--+++-+---+--+--+---+--+-+-+---+---+-+-+ 3 rows in set (0.00 sec) Flow are written into mysql every 1 second. (It’s nice to have such a timestamp for each flow.) And is there any more precise primitive or mechanism to use , for example, some timing information in packet header in millisecond precision? Thanks in advance. And good day :) TC Wu 本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。 This email may contain confidential information. Please do not use or disclose it in any way and delete it if you are not the intended recipient. ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
