Open lunkwill42 opened 2 years ago
An extra level in the metric path for location may also be needed. This could in reality be any prefix configured into the integration script, something like:
* `nav.dhcp.trondheim.vlan511` * `nav.dhcp.oslo.vlan511`
NAV separates broadcast domains that share a common VLAN tag by using a netident
attribute (which it parses from the router port description). The most feasible way for NAV to separate DHCP pools into the correct broadcast domains is if the netident NAV knows is part of the of the DHCP pool name and subsequently encoded into the Graphite metric path.
E.g. nav.dhcp.vlan511.somenetident
to group multiple pools by VLAN number, or nav.dhcp.somenetident.vlan511
to group by netident.
Another question is how to handle the situation where there is no netident in a DHCP pool name, just the vlan tag: What metric path should be used then?
IRL discussion landed us on nav.dhcp.vlanXXX.netidentYYY
is the preferred prefix for DHCP pool stats. We should probably also support the simple case where no VLAN tags are reused, so dhcp pool names of just vlanXXX
should be logged directly under nav.dhcp.vlanXXX
.
Actions:
.
would be preferable, it matches nicely with Graphite metric levels.) @knutvi ,
is a valid part of a Graphite path name (since many netidents as parsed by NAV from the NTNU convention will contain one or two commas) @lunkwill42 * [x] Verify that comma `,` is a valid part of a Graphite path name (since many netidents as parsed by NAV from the NTNU convention will contain one or two commas) @lunkwill42
Commas do not seem to be valid, or at least they will interfere with the interpretation of graphite render commands if used in metric names. We will need to escape these commas somehow (standard for most special chars so far has been to either strip them or replace them with underscores)
The CNaaS team wants to be able to integrate DHCP statistics into NAV.
Overview
A DHCP server can be made to summarize stats on its networks, address ranges, the current number of leases vs. the maximum number for each range. A third party script could gather these metrics and send them to NAV's Graphite server. However, NAV has no way to interpret or graph these metrics, since they didn't come from NAV. At best, you can add threshold rules on these "foreign" metrics.
We have identified three goals for a minimally viable feature:
Examples
For ISC DHCP, a command line utility exists to summarize information about each configured DHCP pool:
dhcpd-pools
. The command can output both human-readable tables to stdout, or as JSON data, which is excellent for a script to parse and push to Graphite.Using the output of a dhcpd-pools command as an example (IP-ranges have been anonymized):
What we want to submit to Graphite are the max, cur and touch numbers for each network listed under Shared networks. The networks/pools are named after the VLAN it belongs to (which is a matter of policy, not requirement).
For this example, we might want to submit metrics like:
nav.dhcp.vlan511.max 239
nav.dhcp.vlan511.cur 39
nav.dhcp.vlan511.touch 0
nav.dhcp.vlan1100.max 1001
nav.dhcp.vlan1100.cur 389
nav.dhcp.vlan1100.touch 591
The actual IP ranges are of less importance in an MVP: As long as NAV can parse a VLAN name from level below
nav.dhcp
, it can create DHCP utilization graphs in the VLAN details page: When viewing the VLAN details for VLAN 1100, NAV could find that there are DHCP metrics that match this VLAN innav.dhcp
, and draw a graph from that.The network names can also be something like
vlan1100_some_description
, orsome_description_vlan1100
, but this should still match as VLAN 1100 in NAV.An extra level in the metric path for location may also be needed. This could in reality be any prefix configured into the integration script, something like:
nav.dhcp.trondheim.vlan511
nav.dhcp.oslo.vlan511