Hi Adam, please follow my replies inline:
On Wed, Aug 08, 2007 at 09:04:18AM +1000, Adam Niedzwiedzki wrote: > For only counting bytes,protocol,ip,port do I just need a v1 sql table? Yes, that's enough. You can even think at stripping the unused fields to make the table smaller and activate the "sql_optimize_clauses" directive in your config. > I wish to be able to at least store down to the hourly data transferred per > IP/port of my servers. > I was thinking of building queries that roll an hours worth of counts into a > table then deleting the original data, has anyone tried/done this? I wouldn't see any problem in having such sliding-window kind of approach. I would just be careful at looking at the amount of tuples the "src_host, src_port" and "dst_host,dst_port" couples might generate - ie. a trivial port scan against a public IP subnet. If the subnet is somehow filtered in a way that the boxes can't receive packets on any possible port but only on specific ones, then you should be OK. Otherwise it's as simple as ... you have to give it a try and see whether the footprint is too large to be easily manageable. > Should I use a filter for my ip range? (I don't quite understand the filter > side of things, if my class c is 202.45.102.0/24 is that what I add as an > aggregate_filter) Yes, you have to add the following lines to your config: aggregate_filter[in]: dst net 202.45.102.0/24 aggregate_filter[out]: src net 202.45.102.0/24 > Here is what I plan to run as my config has anyone got any tips on what I > should add? > debug: false > logfile: /var/log/pmacct.log > daemonize: true > promisc: false > interface: eth1 > > plugins: mysql[in], mysql[out] > > aggregate[in]: dst_port,dst_host,proto > sql_table[in]: acct_in > > aggregate[out]: src_port,src_host,proto > sql_table[out]: acct_out > > sql_host: xx.xx.xx.xx > sql_db: pmacct > sql_table_version: 1 > sql_passwd: xxxx > sql_user: pmacct > sql_refresh_time: 10 > sql_optimize_clauses: true > sql_history: 5m > sql_history_roundoff: mh If possible, i would just get that sql_refresh_time a bit more loose: say, 60 secs. If you don't need nearly real-time data, you can even raise the value to 300 secs (5 mins, ie. matching the sql_history value in your config) and avoid UPDATE queries at all - which translates in huge savings on CPU resources. If you go for it, then you need to add the "sql_dont_try_update" directive. Cheers, Paolo _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
