Feature: fragmentation metrics
This PR adds packet fragmentation data for both VL1 and VL2 to the Prometheus metrics collected in the core agent.
Credit goes to @aaronjohnson for the bulk of the implementation; I've just tried to rebase, clean up, and test it against the current dev branch.
Any info on how to verify or test some of these metrics?
If I do ping -s 9000 10.2.0.2 should I expect something to change in metrics.prom? stuff like that
Any info on how to verify or test some of these metrics?
If I do
ping -s 9000 10.2.0.2should I expect something to change in metrics.prom? stuff like that
If you're running this version, the fragmentation metrics should indeed appear in metrics.prom; figuring out how to trigger actual fragmented traffic is left as an exercise for the reader. ;)
I'm concerned about an .Observe() call being in the put() function in the tap. Has anyone tested the performance impact of this?
My performance measurements to date have not indicated a performance impact. That said, I have not re-created non-zero counters. I'd like to confirm this is true for customers as well.
@joseph-henry would the counter need to increment? Or just that the code path is followed.
I have not been able to set up the scenario where these code branches are reached using netns.
This is in support of collecting detailed information about a theory of VL1 MTU << VL2 MTU implications from impacted customers.
Is there another more performant way to collect this than using prometheus?
Would a local.conf non-default switch to enable these counters suffice?
Any info on how to verify or test some of these metrics?
If I do
ping -s 9000 10.2.0.2should I expect something to change in metrics.prom? stuff like that
Also the -v option.
Performance comparison proposal.
https://github.com/zerotier/network_test_lab/compare/product-benchmark-comparison-fragmentation-metrics?expand=1
This is still in my queue, not forgotten