DHCP pool statistics from Kea DHCP API#3397
Conversation
...the client fetches stats through the Kea API which is connected to a Kea DHCP server.
...stats are obtained from clients defined in nav.dhcpstats and sendt to the Carbon backend.
Test results 12 files 12 suites 12m 5s ⏱️ Results for commit 639601f. ♻️ This comment has been updated with latest results. |
johannaengland
left a comment
There was a problem hiding this comment.
Some questions, but mostly just nitpicks on typos/phrasing
Co-authored-by: Johanna England <johanna.england@sikt.no>
|
johannaengland
left a comment
There was a problem hiding this comment.
Approved, but @lunkwill42 should have a look too, since I know very little about DHCP itself
lunkwill42
left a comment
There was a problem hiding this comment.
I've reviewed the code over your shoulder a couple of times by now, so most of this should be good by now. Now we're just down to the nitty-gritty of make this a robust tool in production use...
|
Force pushing to fix history of last four commits |
671a931 to
84ac480
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #3397 +/- ##
===========================================
+ Coverage 0 60.96% +60.96%
===========================================
Files 0 608 +608
Lines 0 44509 +44509
Branches 0 43 +43
===========================================
+ Hits 0 27135 +27135
- Misses 0 17364 +17364
- Partials 0 10 +10 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
We are still targeting Python 3.9 compatibility, but hopefully not beyond 2025.
|
Scope and purpose
Fixes #2931 and #2369. Deprecates #2937.
This pull request
Adds a package
nav.dhcpstatswhere a Kea DHCP API client is defined innav.dhcpstats.kea_dhcp.Adds a cronjob script called
navdhcpstatsthat runs every 5 minutes. It fetches DHCP stats using Kea DHCP API clients and stores the stats in graphite.Adds a
dhcpstats.conffile that configures which DHCP serversnavdhcpstatsshould fetch from and how.Stores stats as graphite metrics in
nav.dhcp.4.pools.<server-name>.<pool-name>.<range-start>.<range-end>.{assigned,total,declined}.<range-start>and<range-end>is necessary to map graphite metrics to NAV's internalVlanandPrefixmodels. It also makes it easy to show the user how DHCP IP-ranges have changed over time.<pool-name>, stats can be displayed/grouped on a per-pool basis such that any changes in<range-start>or<range-end>won't change how stats are displayed/grouped. Having a flexible scheme for how the names of pools are obtained (usually from a DHCP server's configuration), administrators should be able to choose for themselves what a<pool-name>represents, e.g. the name of a VLAN, the name of a subnet, the name of a set of IP-ranges, or the name of a single IP-range, and thus how stats are displayed/grouped.<server-name>, there won't be any conflicts due to two independent DHCP servers being configured the same way. That is, there won't be any conflicts when NATed pools are named the same on two independent DHCP servers. Since<server-name>is specified indhcpstats.confwe can ensure server names are unique whenevernavdhcpstatsis being used to store stats in graphite (the implementation in this PR does sort-of inherently ensure this, given that administrators follow advice given indhcpstats.confand abstain from using characters not supported by graphite/carbon).Adds an explicit dependency to
urllib3.Contributor Checklist
Added/changed documentation(documentation will be added in separate pull requests)and is 50 characters or less long. See https://cbea.ms/git-commit/<major>.<minor>.x). For a new feature or other additions, it should be based onmaster.If applicable: Created new issues if this PR does not fix the issue completely/there is further work to be done.If this results in changes in the UI: Added screenshots of the before and after.