Re: [pmacct-discussion] stamp_inserted
Hi Jaroslav, Unfortunately not as they are integral part of the sql_history feature (which you need to populate the time-related variables of the tables). As an alternative, only for the 'all' tables where you have the other timestamps, you may disable sql_history and write to a fixed, say, 'router1_in' 'router1_out' tables and, ie. via a sql_trigger script, you can take care yourself of the logics of renaming the tables so to include some time-related variable. Cheers, Paolo On Wed, Nov 30, 2016 at 01:00:02PM +0100, Jaroslav Jirásek wrote: > Hi, I use this scerario: > > sql_refresh_time: 120 > sql_history: 2m > sql_history_roundoff: m > sql_dont_try_update: true > nfacctd_pro_rating: true > > aggregate[router1.all.in]: > src_host,dst_host,proto,src_port,dst_port,timestamp_start,timestamp_end > aggregate[router1.all.out]: > src_host,dst_host,proto,src_port,dst_port,timestamp_start,timestamp_end > aggregate[router1.sums.in]: dst_host > aggregate[router1.sums.out]: src_host > > plugins: > mysql[router1.all.in],mysql[router1.all.out],mysql[router1.sums.in],mysql[router1.sums.out] > > sql_table[router1.all.in]: %Y%m%d_router1_in > sql_table[router1.all.out]: %Y%m%d_router1_out > sql_table[router1.sums.in]: %Y_router1_sums_in > sql_table[router1.sums.out]: %Y_router1_sums_out > > sql_startup_delay[router1.all.in]: 240 > sql_startup_delay[router1.all.out]: 240 > sql_startup_delay[router1.sums.in]: 240 > sql_startup_delay[router1.sums.out]: 240 > > in tables %Y%m%d_router1_in and %Y%m%d_router1_out I have columns > stamp_inserted and stamp_updated, > but I don´t need them, because I aggregate nothing. timestamp_start > and timestamp_end is enough. > In these tables I need to store everything for best accuracy when > finding problems. > > In sums tables I don´t need column stamp_updated. > > Is there any way to not store these columns? > > Thank you, Jaroslav > > > ___ > pmacct-discussion mailing list > http://www.pmacct.net/#mailinglists ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
[pmacct-discussion] stamp_inserted
Hi, I use this scerario: sql_refresh_time: 120 sql_history: 2m sql_history_roundoff: m sql_dont_try_update: true nfacctd_pro_rating: true aggregate[router1.all.in]: src_host,dst_host,proto,src_port,dst_port,timestamp_start,timestamp_end aggregate[router1.all.out]: src_host,dst_host,proto,src_port,dst_port,timestamp_start,timestamp_end aggregate[router1.sums.in]: dst_host aggregate[router1.sums.out]: src_host plugins: mysql[router1.all.in],mysql[router1.all.out],mysql[router1.sums.in],mysql[router1.sums.out] sql_table[router1.all.in]: %Y%m%d_router1_in sql_table[router1.all.out]: %Y%m%d_router1_out sql_table[router1.sums.in]: %Y_router1_sums_in sql_table[router1.sums.out]: %Y_router1_sums_out sql_startup_delay[router1.all.in]: 240 sql_startup_delay[router1.all.out]: 240 sql_startup_delay[router1.sums.in]: 240 sql_startup_delay[router1.sums.out]: 240 in tables %Y%m%d_router1_in and %Y%m%d_router1_out I have columns stamp_inserted and stamp_updated, but I don´t need them, because I aggregate nothing. timestamp_start and timestamp_end is enough. In these tables I need to store everything for best accuracy when finding problems. In sums tables I don´t need column stamp_updated. Is there any way to not store these columns? Thank you, Jaroslav ___ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
Re: [pmacct-discussion] stamp_inserted and sql_history
Hello Jamie, On Tue, Aug 16, 2005 at 05:07:33PM +1000, Jamie Wilkinson wrote: Actually, I'm still not clear: the FAQ suggests that only sql_history is required, though sql_history_roundoff is advised. Is that true? True. sql_history writes the stamp fields; sql_history_roundoff enables the roundings. sql_history_roundoff alone (ie. supplied without sql_history) is silently ignored. Cheers, Paolo
Re: [pmacct-discussion] stamp_inserted and sql_history
This one time, at band camp, Paolo Lucente wrote: On Sat, Aug 13, 2005 at 02:14:00AM +1000, Jamie Wilkinson wrote: Ok. Does this mean that unless the config options 'sql_history' and 'sql_history_roundoff' exist, then pmacctd will not write time stamps to the database? yes. Thanks for the clarification. I've done so, but I've also added these two config options back to my config file, and I'm seeing a lot of 'We are missing data' errors in the syslog. Such error shouldn't be related in any way with the stamps. It signals that the shared memory segment between the Core Process (which collects packets from the network) and the Plugin (which writes flows into the DB) is full. (*) It's very likely that you have not enabled bufferization. Try adding to your configuration the two following lines (then tune the parameters in order to fit your scenario): === plugin_pipe_size: 8192000 plugin_buffer_size: 4096 === Ok, I already have a plugin_pipe_size, but no buffer_size. Anyway, there were only a couple of 'We are missing data' messages at startup so I suspect they are transient. Thanks.
Re: [pmacct-discussion] stamp_inserted and sql_history
On Sat, Aug 13, 2005 at 02:14:00AM +1000, Jamie Wilkinson wrote: Ok. Does this mean that unless the config options 'sql_history' and 'sql_history_roundoff' exist, then pmacctd will not write time stamps to the database? yes. I've done so, but I've also added these two config options back to my config file, and I'm seeing a lot of 'We are missing data' errors in the syslog. Such error shouldn't be related in any way with the stamps. It signals that the shared memory segment between the Core Process (which collects packets from the network) and the Plugin (which writes flows into the DB) is full. (*) It's very likely that you have not enabled bufferization. Try adding to your configuration the two following lines (then tune the parameters in order to fit your scenario): === plugin_pipe_size: 8192000 plugin_buffer_size: 4096 === CONFIG-KEYS and docs/INTERNALS give further hints and some details about them and how communication between Core Process and Plugins works. Give them a try and let me know how things get evolved. Cheers, Paolo (*) note that since versions 0.8.x, shared memory support is compiled in by default. This was not the case of previous versions that were requiring the './configure --enable-mmap'. This *might* explain why you didn't get such messages before.
