23.09.2009 20:19, Paolo Lucente пишет: >>> OK: accounting for local IP addresses traffic and UA-IX networks >>> is two different things - no traffic matrix required. Hence, i >>> would propose you to change your config as follows: >>> >>> aggregate[hourly]: src_host, dst_host >>> aggregate[hourly_ua]: src_host, dst_host >>> plugins: mysql[hourly], mysql[hourly_ua] >>> sql_table[hourly]: acct_base >>> sql_table[hourly_ua]: acct_base_ua >>> networks_file[hourly]: /etc/pmacct/networks-local.list >>> networks_file[hourly_ua]: /etc/pmacct/networks-ua-ix.list >>> >>> The effect will be that the "hourly_ua" plugin will give you >>> a breakdown of the traffic at the UA-IX, plus you will find a >>> "catch all" entry every hour, ie. ip_src = 0, ip_dst = 0, >>> which is the hourly sum of all the traffic between your local >>> IP addresses and networks besides UA-IX. >>> >>> >> Many thanks for the answer. >> But in that case to a database will get all IP that are specified in >> /etc/pmacct/networks-ua-ix.list. Namely it also is to be avoided. >> And then to me it is not necessary [hourly] since local IP enter UA-IX >> >> But I think it the best variant that it is possible to make. >> > You would get the IP address granularity for the networks listed, > if that's what you want. Otherwise you might aggregate on network > boundaries (as specified within the networks_file): > > aggregate[hourly_ua]: src_net, dst_net > > Or even aggregate at the AS level if you put such information into > the list pointed by the networks_file (see the examples for syntax > reference) without resorting to BGP: > > aggregate[hourly_ua]: src_as, dst_as > > Both these should keep the data volume more manageable. Once again, > if that's what you are trying to achieve. And this would be yet a > further advantage of the networks_file approach in this scenario. > No, it is all does not approach. If I use networks_file [hourly_ua]:/etc/pmacct/networks-ua-ix.list that I receive many rows in a database: mysql> select stamp_inserted,count(*) from acct_base_ua group by stamp_inserted; +---------------------+----------+ | stamp_inserted | count(*) | +---------------------+----------+ | 2009-09-23 16:00:00 | 12135 | | 2009-09-23 17:00:00 | 23889 | | 2009-09-23 18:00:00 | 20117 | +---------------------+----------+ 3 rows in set (0.29 sec)
For a month it will be more then 10 millions. 20000 * 24 hrs * 30 days = 14 400 000 rows I have found other solution. With the help pre_tag_map. From networks-ua-ix.list I have made pretag.map in sort: id=1 ip=192.168.21.1 filter='net 173.194.0.0/24' id=1 ip=192.168.21.1 filter='net 188.163.0.0/24' id=1 ip=192.168.21.1 filter='net 193.0.227.0/24' id=1 ip=192.168.21.1 filter='net 193.0.228.0/24' id=1 ip=192.168.21.1 filter='net 193.0.240.0/24' id=1 ip=192.168.21.1 filter='net 193.0.247.0/24' id=1 ip=192.168.21.1 filter='net 193.9.28.0/24' id=1 ip=192.168.21.1 filter='net 193.16.45.0/24' ... And the config looks so: aggregate[hourly_ua]: src_host, dst_host, tag plugins: mysql[hourly_ua] sql_table[hourly_ua]: acct_v2 sql_table_version[hourly_ua]: 2 networks_file: /etc/pmacct/networks.list pre_tag_map: /etc/pmacct/pretag.map pre_tag_map_entries: 50000 And now all that gets under the filter has tag 1 and all that is not in - 0. It increases quantity of rows only twice. That is very good. :-) But I have now doubts that pretag filter works correctly. Example: in networks_file: /etc/pmacct/networks.list 91.206.226.0/23 91.209.165.0/24 in pre_tag_map: /etc/pmacct/pretag.map id=1 ip=192.168.21.1 filter='net 91.206.226.0/23' id=1 ip=192.168.21.1 filter='net 91.209.165.0/24' aggregate[hourly_ua]: src_host, dst_host, tag And it put tag 1 and 0 in the same ip_src and ip_dst mysql> select agent_id,ip_src,ip_dst,bytes from acct_v2 where ip_src like '91.206.226.104' and ip_dst like '91.209.165.1'; +----------+----------------+--------------+--------+ | agent_id | ip_src | ip_dst | bytes | +----------+----------------+--------------+--------+ | 0 | 91.206.226.104 | 91.209.165.1 | 156040 | | 1 | 91.206.226.104 | 91.209.165.1 | 19040 | +----------+----------------+--------------+--------+ 2 rows in set (0.01 sec) Can you explain it? -- WBR, Dubrovskiy Vyacheslav
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
