fix(bgp): eliminate per-peer route-table dumps that cause scrape time…#163
Open
jklaiber wants to merge 1 commit into
Open
fix(bgp): eliminate per-peer route-table dumps that cause scrape time…#163jklaiber wants to merge 1 commit into
jklaiber wants to merge 1 commit into
Conversation
…outs On hosts with large BGP tables (100k+ prefixes), `--collector.bgp.accepted-filtered-prefixes` triggered one `show bgp <afi> neighbors <peer> routes json` command per established peer. FRR serializes the entire Adj-RIB-In to produce this output — taking 30+ seconds for a single peer — which reliably exceeded Prometheus scrape timeouts and returned empty metric sets. - `acceptedPrefixCounter` and `sentPrefixCounter` are already maintained by FRR per neighbor per address-family and exposed in `show bgp vrf all neighbors json` (the single O(peers) call already issued for peer-descriptions/peer-groups). This field has been present since FRR 7.0. - `getPeerAcceptedFilteredRoutes` (the per-peer route-table dump) is removed entirely. `processPeerAcceptedFilteredPrefixes` now reads the counter directly from the neighbors JSON, reducing the accepted/filtered scrape from O(peers × prefixes) to O(1) additional work. - The AFI/SAFI key lookup normalises spaces and case so older FRR versions that emit `"IPv4 Unicast"` instead of `"ipv4Unicast"` are handled transparently.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
On hosts with large BGP tables (100k+ prefixes),
--collector.bgp.accepted-filtered-prefixestriggered oneshow bgp <afi> neighbors <peer> routes jsoncommand per established peer. FRR serializes the entire Adj-RIB-In to produce this output — taking 30+ seconds for a single peer — which reliably exceeded Prometheus scrape timeouts and returned empty metric sets.Solution
acceptedPrefixCounterandsentPrefixCounterare already maintained by FRR per neighbor per address-family and exposed inshow bgp vrf all neighbors json(the single O(peers) call already issued for peer-descriptions/peer-groups). This field has been present since FRR 7.0.getPeerAcceptedFilteredRoutes(the per-peer route-table dump) is removed entirely.processPeerAcceptedFilteredPrefixesnow reads the counter directly from the neighbors JSON, reducing the accepted/filtered scrape from O(peers × prefixes) to O(1) additional work."IPv4 Unicast"instead of"ipv4Unicast"are handled transparently.