Hi Saku,

aggregate [DSTAS]: label, dst_as, peer_dst_as, out_iface

aggregate [SRCAS]: label, src_as, peer_src_as, in_iface

aggregate[IP]: label, dst_as, src_host, out_iface, in_iface

And a script goes over this output to relate ifindex to ifalias from also influxdb SNMP counter DB (where the ifalias is stored) ( script has to be smart to know which port flows to store, as in edge ports for hosters for example cause you wouldnt want ibgp flow info in your DST AS database)

I'm attaching only the graph for IP aggregate series. And Cpu never goes above 30%.

As i said, per IP, per iface, per dst As information stored, cant get more pretties and betetr than this for a capacity manager :D

And if you add another tag adding a price per mbit to a carrier/port, you can find out how much a single customer is costing you for network usage based on per IP aggregation !!!!!!!!!!!!!!!!!!!!

You have to be "smart" with duration of your retention policy and continuous queries though :D

(again, Thanks Paulo for PMACCT!!! )

( and as an addition, we have a telegram bot you send a message to like "/dst as#",
and this pulls the graph from grafana, renders it and sends it to telegram chat :D
I worked at a few Hosting companies, and I haven't seen anything like this :D )

The idea is to put this whole thing on github but i need to make time for that...
And "aint nobody got time for that" :P

Hey,


On Wed, 2 Jan 2019 at 14:40, H I Baysal <hibaysal@gmail.com> wrote:

That absolutely depends on the amount of TAGs you use, and how you aggregate, etc.
I am collecting DSTAS, SRCAS, en DST AS per IP. And influx is not even sweating a single drop....

We have a 4 Tbps of traffic during peak, and as well as pmacct and influxdb or running very very smooth.

How many series do you have in the DB?

Your explanation makes it unclear to me what labels you have 'per IP'
is ambiguous to me. If only DST_IP is tag and you have low amount of
IPs in or behind your network, it seems very feasible indeed.