FR: Summarized graphs per facility

[rasssta]

Is your feature request related to a problem? Please describe.
We currently use an in-house script to build graphs from another source than IXP Manager and would, of course, prefer to use IXP Manager as the source (and get rid of the other system) to limit the amount of SNMP polling (and systems) to the switches. In our system (https://www.sthix.net/stats/switches-day.php) we organize the graphs per PoP in one phase/step, and that is not currently possible via the grapher API as I understand it(?). The closest thing I can get is per switch, but it becomes a bit tricky (impossible?) to merge multiple switches to get the graphs (RRD file, etc.) as you cannot output the raw RRD data per switch via the API as I understand it (to be able to merge it).

Describe the solution you'd like
An addition to MRTG's infras/ixp/members/switches called "facilities" or similar that merges all customer traffic on the switches within each facility.

Describe alternatives you've considered
It should not be very hard to add this to the MRTG configuration, but it might be somewhat tricky to generate a backlog/history of data, which would be preferable but isn't a deal breaker.

[nickhilliard]

are you talking here about:

• an aggregate graph of all ingress + egress ixp participant traffic in a cluster of switches
• the aggregate graph of traffic to/from that cluster of switches to the rest of the network
• the aggregate graph of all switch traffic in the cluster of switches

[rasssta]

• an aggregate graph of all ingress + egress ixp participant traffic in a cluster of switches

[barryo]

an aggregate graph of all ingress + egress ixp participant traffic in a cluster of switches

For the avoidance of doubt - what's being coded is the aggregate of all traffic originating and / or terminating in a cluster of switches in a PoP but not simply passing through that PoP. I.e. core ports are excluded.

[barryo]

Completed via b54df92, d646bc7, d74c1dc and documented via inex/ixp-manager-docs-md@cb441ca

[barryo]

also:

but it might be somewhat tricky to generate a backlog/history of data, which would be preferable but isn't a deal breaker

yeah, this is neither done nor necessary really. it'll build up.