Hiya!

I'm looking to get this running on Pfsense, which is based around FreeBSD. It can run FRR natively, but SNMP doesn't expose BGP data.

• Because BSD != Linux, the Go binary doesnt work.

[2.5.2-RELEASE][[email protected]]/root/frr_exporter-1.1.0.linux-amd64: file frr_exporter 
frr_exporter: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=j-uoBu0kvj9N9iU6S4WE/wUB1coaxE8Ovw-9W0HY7/TZNeZIlTy7x2Eq-huA7I/pBehHD21XjCwDpcXTc0a, not stripped

• Pfsense cannot run Docker so a container is a no go :(

Couple of options

• FreeBSD go binaries? No idea if that is even feasible.
• Connecting to the socket remotely? If we are using the vtysh and could configure ssh less access, that could work?

Hi,

The collectors or enable by default and there is no way to disable them from the CLI.
This generates errors in the log output when OSFP is disabled in FRR for example.

Regards,

Following is my bgp vtysh configuration

router bgp 405
bgp log-neighbor-changes
no bgp ebgp-requires-policy
neighbor 172.18.0.2 remote-as 404
neighbor 172.18.0.2 disable-connected-check
neighbor 172.19.0.2 remote-as 406
neighbor 172.19.0.2 disable-connected-check
!
address-family ipv4 unicast
neighbor 172.18.0.2 next-hop-self
neighbor 172.18.0.2 soft-reconfiguration inbound
neighbor 172.18.0.2 route-map peer-routes in
neighbor 172.19.0.2 next-hop-self
neighbor 172.19.0.2 soft-reconfiguration inbound
neighbor 172.19.0.2 route-map peer-routes in
exit-address-family
exit
!

I have two neighbors 172.18.0.2 and 172.19.02, both are 'up'
I have two prefixes received from 172.18.0.2 neighbor

0d3500518d77# show ip bgp summary

IPv4 Unicast Summary (VRF default):
BGP router identifier 172.19.0.3, local AS number 405 vrf-id 0
BGP table version 21
RIB entries 5, using 1000 bytes of memory
Peers 2, using 41 KiB of memory

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
172.18.0.2 4 404 9647 9643 21 0 0 00:25:00 2 2 N/A
172.19.0.2 4 406 9642 9642 21 0 0 00:24:59 0 2 N/A

Total number of neighbors 2
0d3500518d77#

but FRR exporter metrics shows frr_bgp_rib_count_total as : 5

Not sure where is this 5 coming from as we have only 2 prefixes received .

Following are further logs:

0d3500518d77# show ip bgp neighbors 172.18.0.2 routes
BGP table version is 21, local router ID is 172.19.0.3, vrf id 0
Default local pref 100, local AS 405
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network          Next Hop            Metric LocPrf Weight Path

*> 51.51.51.0/24 172.18.0.2 0 0 404 i
*> 52.52.52.0/24 172.18.0.2 0 0 404 i

Displayed 2 routes and 2 total paths
0d3500518d77# show ip bgp neighbors 172.19.0.2 routes
0d3500518d77#

0d3500518d77# show ip bgp neighbors 172.18.0.2 received
BGP table version is 21, local router ID is 172.19.0.3, vrf id 0
Default local pref 100, local AS 405
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network          Next Hop            Metric LocPrf Weight Path

*> 51.51.51.0/24 172.18.0.2 0 0 404 i
*> 52.52.52.0/24 172.18.0.2 0 0 404 i

Total number of prefixes 2
0d3500518d77# show ip bgp neighbors 172.18.0.2 advertised-routes
BGP table version is 21, local router ID is 172.19.0.3, vrf id 0
Default local pref 100, local AS 405
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network          Next Hop            Metric LocPrf Weight Path

*> 51.51.51.0/24 0.0.0.0 0 404 i
*> 52.52.52.0/24 0.0.0.0 0 404 i

Total number of prefixes 2
0d3500518d77# show ip bgp neighbors 172.19.0.2 received
BGP table version is 21, local router ID is 172.19.0.3, vrf id 0
Default local pref 100, local AS 405
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network          Next Hop            Metric LocPrf Weight Path

*> 51.51.51.0/24 172.19.0.2 0 406 405 404 i
*> 52.52.52.0/24 172.19.0.2 0 406 405 404 i

Total number of prefixes 2
0d3500518d77# show ip bgp neighbors 172.19.0.2 advertised-routes
BGP table version is 21, local router ID is 172.19.0.3, vrf id 0
Default local pref 100, local AS 405
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network          Next Hop            Metric LocPrf Weight Path

*> 51.51.51.0/24 0.0.0.0 0 404 i
*> 52.52.52.0/24 0.0.0.0 0 404 i

Total number of prefixes 2

I am not able to match the value 5 with any of the above RIB tables
please help me clarify this.

Hello,

We have setup frr_exporter on one of our 6wind dev hosts. This one is showing an error when running with socket mode:

$ sudo /usr/local/bin/frr_exporter --frr.socket.dir-path="/etc/frr" --no-collector.ospf --collector.vrrp --collector.bgp6 --collector.bgpl2vpn --log.level=debug
level=info ts=2022-01-20T10:51:13.598Z caller=frr_exporter.go:65 msg="Starting frr_exporter" version="(version=1.1.0, branch=HEAD, revision=5ac721e047f91e8906ece32ac2ff62797e2a5d6a)"
level=info ts=2022-01-20T10:51:13.599Z caller=frr_exporter.go:66 msg="Build context" build_context="(go=go1.17.5, user=root@14669bca9510, date=20211221-20:17:31)"
level=info ts=2022-01-20T10:51:13.599Z caller=frr_exporter.go:67 msg="Listening on address" address=:9342
level=info ts=2022-01-20T10:51:13.599Z caller=tls_config.go:191 msg="TLS is disabled." http2=false
level=error ts=2022-01-20T10:51:18.088Z caller=collector.go:126 msg="collector scrape failed" name=bgp6 duration_seconds=7.4145e-05 err="dial unix /etc/frr/bgpd.vty: connect: connection refused"
level=error ts=2022-01-20T10:51:18.088Z caller=collector.go:126 msg="collector scrape failed" name=bgp duration_seconds=0.000258072 err="dial unix /etc/frr/bgpd.vty: connect: connection refused"
level=error ts=2022-01-20T10:51:18.088Z caller=collector.go:126 msg="collector scrape failed" name=bgpl2vpn duration_seconds=0.000128086 err="dial unix /etc/frr/bgpd.vty: connect: connection refused"
level=error ts=2022-01-20T10:51:18.088Z caller=collector.go:126 msg="collector scrape failed" name=vrrp duration_seconds=0.000720743 err="dial unix /etc/frr/vrrpd.vty: connect: no such file or directory"
level=error ts=2022-01-20T10:51:18.328Z caller=collector.go:126 msg="collector scrape failed" name=bfd duration_seconds=0.240504435 err="cannot process output of show bfd peers json: unexpected end of JSON input: command output: "

output of vtysh show version

FRRouting 7.3.1 (frr-7.3.1-2021.Q1.6-m2) (DEVmew).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
configured with:
    '--sysconfdir=/etc/frr' '--localstatedir=/etc/frr' '--sbindir=/usr/bin' '--bindir=/usr/bin' '--libdir=/usr/lib/x86_64-linux-gnu' '--enable-vtysh' '--enable-isisd' '--enable-multipath=16' '--disable-capabilities' '--disable-irdp' '--disable-doc' '--enable-user=root' '--enable-group=root' '--host=x86_64-linux-gnu' '--build=x86_64-linux-gnu' '--enable-cumulus' '--enable-wrap-script' '--enable-pmd' '--enable-pm-tracking' '--enable-bfd-tracking' '--enable-zebra-nhrp' '--enable-sharpd' '--with-pkg-extra-version= (frr-7.3.1-2021.Q1.6-m2)' '--enable-snmp' '--enable-rpki' '--enable-ldpd' '--disable-bgp-vnc' 'build_alias=x86_64-linux-gnu' 'host_alias=x86_64-linux-gnu' 'LDFLAGS=' 'LIBYANG_CFLAGS=-I/build/make-pkg/output/_packages/libyang/devel/usr/include' 'LIBYANG_LIBS=-L/build/make-pkg/output/staging/usr/lib/x86_64-linux-gnu -lyang' 'RTRLIB_CFLAGS=-I/build/make-pkg/output/staging/usr/include' 'RTRLIB_LIBS=-L/build/make-pkg/output/staging/usr/lib/x86_64-linux-gnu -lrtr'

when running in vtysh mode:

$ sudo /usr/local/bin/frr_exporter --frr.vtysh --no-collector.ospf --collector.vrrp --collector.bgp6 --collector.bgpl2vpn --log.level=debug
level=info ts=2022-01-20T10:55:44.098Z caller=frr_exporter.go:65 msg="Starting frr_exporter" version="(version=1.1.0, branch=HEAD, revision=5ac721e047f91e8906ece32ac2ff62797e2a5d6a)"
level=info ts=2022-01-20T10:55:44.098Z caller=frr_exporter.go:66 msg="Build context" build_context="(go=go1.17.5, user=root@14669bca9510, date=20211221-20:17:31)"
level=info ts=2022-01-20T10:55:44.098Z caller=frr_exporter.go:67 msg="Listening on address" address=:9342
level=info ts=2022-01-20T10:55:44.099Z caller=tls_config.go:191 msg="TLS is disabled." http2=false
level=error ts=2022-01-20T10:55:47.338Z caller=collector.go:126 msg="collector scrape failed" name=bgp6 duration_seconds=0.261798637 err="cannot process output of show bgp vrf all ipv6 unicast summary json: unexpected end of JSON input: command output: "
level=error ts=2022-01-20T10:55:47.350Z caller=collector.go:126 msg="collector scrape failed" name=bfd duration_seconds=0.274161169 err="cannot process output of show bfd peers json: unexpected end of JSON input: command output: "
level=error ts=2022-01-20T10:55:47.390Z caller=collector.go:126 msg="collector scrape failed" name=bgp duration_seconds=0.314233277 err="cannot process output of show bgp vrf all ipv4 unicast summary json: unexpected end of JSON input: command output: "
level=error ts=2022-01-20T10:55:47.464Z caller=collector.go:126 msg="collector scrape failed" name=vrrp duration_seconds=0.38777045 err="cannot process output of show vrrp json: unexpected end of JSON input: command output: "
level=error ts=2022-01-20T10:55:47.470Z caller=collector.go:126 msg="collector scrape failed" name=bgpl2vpn duration_seconds=0.39396483 err="cannot process output of show bgp vrf all l2vpn evpn summary json: unexpected end of JSON input: command output: "

thank you for this work, the project is really nice.
I wonder if someone has made a grafana dashboard?

Tests are failing

go test ./... results

# github.com/tynany/frr_exporter/collector [github.com/tynany/frr_exporter/collector.test]
collector/bgp_test.go:277:29: not enough arguments in call to processBGPSummary
	have (chan prometheus.Metric, []byte, string)
	want (chan<- prometheus.Metric, []byte, string, string)
collector/bgp_test.go:280:29: not enough arguments in call to processBGPSummary
	have (chan prometheus.Metric, []byte, string)
	want (chan<- prometheus.Metric, []byte, string, string)
?   	github.com/tynany/frr_exporter	[no test files]
FAIL	github.com/tynany/frr_exporter/collector [build failed]
FAIL

I am working on a fix.

Hello,

Following this commit, it seems the metric frr_up isn't updated anymore.

As this metric is the result of the statuses union of frr_collector_up, it could be completely removed

Could you please add peer description to the metric labels like this:
frr_bgp_peer_up{address_family="ipv4unicast",peer_descr="some_neighbor",local_as="65550",peer="10.1.2.3",peer_as="58888",vrf="internet"} 1

You can usually get the description by running:
# vtysh -c " show run " | grep description

I know that you are using the json format and there is no description in the json output. I am not sure how this could be implemented.

For us this is important as we need to see the neighbour name in the alerts.

FRR removed prefixReceivedCount from show ip bgp vrf all summary json output (alternative is pfxRcd)
FRRouting/frr#6143

so, frr_exporter can't collect frr_bgp_peer_prefixes_received_count_total metrics...

• FRR7.3 example

# show bgp vrf VRF000 summary  json
...<snip>

    "swp54":{
      "hostname":"spine000b",
      "remoteAs":4200065280,
      "version":4,
      "msgRcvd":9347,
      "msgSent":9368,
      "tableVersion":0,
      "outq":0,
      "inq":0,
      "peerUptime":"07:45:58",
      "peerUptimeMsec":27958000,
      "peerUptimeEstablishedEpoch":1599789074,
      "prefixReceivedCount":230,
      "pfxRcd":230,
      "pfxSnt":341,
      "state":"Established",
      "idType":"interface"
    }
 

• FRR7.4 example

# show ip bgp vrf VRF000 summary json
...<snip>

    "swp54":{
      "hostname":"spine000b",
      "remoteAs":4200065280,
      "version":4,
      "msgRcvd":3838,
      "msgSent":3847,
      "tableVersion":0,
      "outq":0,
      "inq":0,
      "peerUptime":"03:10:48",
      "peerUptimeMsec":11448000,
      "peerUptimeEstablishedEpoch":1599805590,
      "pfxRcd":231,
      "pfxSnt":341,
      "state":"Established",
      "connectionsEstablished":1,
      "connectionsDropped":0,
      "idType":"interface"
    }

Hi, do you have a grafana dashboard for this?

When running tests on 32-bit machines, tests essentially fail due to what would be integer overflows.

=== RUN   TestProcessBFDPeers
    bfd_test.go:85: error calling processBFDPeers ipv4unicast: json: cannot unmarshal number 2809641312 into Go struct field bfdPeer.id of type int
    bfd_test.go:138: missing metric: frr_bfd_peer_state{local=10.10.141.81,peer=10.10.141.63} value 0
    bfd_test.go:138: missing metric: frr_bfd_peer_count{} value 3
    bfd_test.go:138: missing metric: frr_bfd_peer_uptime{local=10.10.141.81,peer=10.10.141.61} value 847716
    bfd_test.go:138: missing metric: frr_bfd_peer_state{local=10.10.141.81,peer=10.10.141.61} value 1
    bfd_test.go:138: missing metric: frr_bfd_peer_uptime{local=10.10.141.81,peer=10.10.141.62} value 847595
    bfd_test.go:138: missing metric: frr_bfd_peer_state{local=10.10.141.81,peer=10.10.141.62} value 1
    bfd_test.go:138: missing metric: frr_bfd_peer_uptime{local=10.10.141.81,peer=10.10.141.63} value 847888
--- FAIL: TestProcessBFDPeers (0.00s)

The ID fields in the bfdPeer struct are signed ints, which will have a range of -2147483648 to +2147483647 on 32-bit platforms.

type bfdPeer struct {
    Multihop               bool   `json:"multihop"`
    Peer                   string `json:"peer"`
    Local                  string `json:"local"`
    Vrf                    string `json:"vrf"`
    ID                     int    `json:"id"`
    RemoteID               int    `json:"remote-id"`
    Status                 string `json:"status"`
    Uptime                 int    `json:"uptime"`
    Diagnostic             string `json:"diagnostic"`
    RemoteDiagnostic       string `json:"remote-diagnostic"`
    ReceiveInterval        int    `json:"receive-interval"`
    TransmitInterval       int    `json:"transmit-interval"`
    EchoInterval           int    `json:"echo-interval"`
    RemoteReceiveInterval  int    `json:"remote-receive-interval"`
    RemoteTransmitInterval int    `json:"remote-transmit-interval"`
    RemoteEchoInterval     int    `json:"remote-echo-interval"`
}

Given that the BGP RFCs define the router ID to be a "4-octet, unsigned, non-zero integer", the ID and RemoteID fields really ought to be explicit uint32 type.

On a side note, some of the other numeric fields should probably also be checked, since I doubt that negative values would be legal, and it may be expected that they can use the full range of an unsigned 32-bit integer.

I am already trying out the new feature, the flag --collector.bgp.peer-descriptions.plain-text and it is not working for me. I have tried the exporter on 3 different hosts and none of them are showing the peer_descr label.
I run the exporter like this:
# ./frr_exporter --collector.bgp.peer-descriptions.plain-text --no-collector.ospf

Output of vtysh -c "show run bgp:

router bgp 64512 vrf internet
 bgp router-id 192.168.0.180
 neighbor 192.168.0.1 remote-as 64555
 neighbor 192.168.0.1 description importantpeer
 neighbor 192.168.0.2 remote-as 64555
 neighbor 192.168.0.2 description importantpeer1
 neighbor 192.168.0.3 remote-as 64512
 neighbor 192.168.0.3 description importantpeer2
 neighbor 192.168.0.3 bfd

These are the metrics:

frr_bgp_peer_state{afi="ipv4",local_as="64512",peer="192.168.0.1",peer_as="64555",safi="unicast",vrf="internet"} 1
frr_bgp_peer_state{afi="ipv4",local_as="64512",peer="192.168.0.2",peer_as="64555",safi="unicast",vrf="internet"} 1
frr_bgp_peer_state{afi="ipv4",local_as="64512",peer="192.168.0.3",peer_as="64512",safi="unicast",vrf="internet"} 1

Whilst investigating #45, it suddenly became rather obvious that none of the collectors in frr_exporter is safe in the event of concurrent scrapes by multiple Prometheus instances (such as is recommended for fault tolerant setups).

Each collector uses a global errors slice, which is initialized to an empty slice in the collector's Collect() method, e.g.

var (
    bgpErrors           = []error{}
)

// Collect implemented as per the prometheus.Collector interface.
func (c *BGPCollector) Collect(ch chan<- prometheus.Metric) {
    bgpErrors = []error{}
    collectBGP(ch, "ipv4")
}

If another scrape is still in progress, that global bgpErrors variable is racy. This is likely what is causing the intermittent segfaults and unexplained nil pointers in our environment, where we have two Prometheus instances configure to scrape identical targets.

The docs for the prometheus.Collector interface type are clear about concurrency:

type Collector interface {
	...
	// Collect is called by the Prometheus registry when collecting
	// metrics. ...
	//
	// This method may be called concurrently and must therefore be
	// implemented in a concurrency safe way. Blocking occurs at the expense
	// of total performance of rendering all registered metrics. Ideally,
	// Collector implementations support concurrent readers.
	Collect(chan<- Metric)
}

I suspect that fixing this is going to require some non-trivial changes to the code.

Hi @tynany,

first of all, thanks for providing this exporter, it is very useful to us!

Would it be possible to update the used dependencies to their respective versions?

I built and tested the container sucessfully with the changes in 5dcdd911 (just ran go get -u && go mod tidy). Please let me know if I should open a PR :)

There is an issue with FRR exporter after FRR service is restarted, it reports that OSPF collector is down, FRR exporter restart resolves this problem:

# curl -s localhost:9342/metrics | grep frr_collector_up
# HELP frr_collector_up Whether the collector's last scrape was successful (1 = successful, 0 = unsuccessful).
# TYPE frr_collector_up gauge
frr_collector_up{collector="bgp"} 1
frr_collector_up{collector="ospf"} 1

# systemctl stop frr

# curl -s localhost:9342/metrics | grep frr_collector_up
# HELP frr_collector_up Whether the collector's last scrape was successful (1 = successful, 0 = unsuccessful).
# TYPE frr_collector_up gauge
frr_collector_up{collector="bgp"} 0
frr_collector_up{collector="ospf"} 0

# systemctl start frr

# curl -s localhost:9342/metrics | grep frr_collector_up
# HELP frr_collector_up Whether the collector's last scrape was successful (1 = successful, 0 = unsuccessful).
# TYPE frr_collector_up gauge
frr_collector_up{collector="bgp"} 1
frr_collector_up{collector="ospf"} 0

# systemctl restart frr_exporter

# curl -s localhost:9342/metrics | grep frr_collector_up
# HELP frr_collector_up Whether the collector's last scrape was successful (1 = successful, 0 = unsuccessful).
# TYPE frr_collector_up gauge
frr_collector_up{collector="bgp"} 1
frr_collector_up{collector="ospf"} 1

FRR exporter is started with following flags: frr_exporter --collector.bgp.peer-descriptions --collector.bgp.peer-descriptions.plain-text --no-collector.bfd

Log output during these queries is following:

$ frr_exporter --collector.bgp.peer-descriptions --collector.bgp.peer-descriptions.plain-text --no-collector.bfd
INFO[0000] Starting frr_exporter (version=0.2.11, branch=HEAD, revision=7a774985ce8463144f534417d1761ed7b3ff4e19) on :9342  source="frr_exporter.go:118"
ERRO[0063] collector "ospf" scrape failed: cannot get ospf interface summary: exit status 1  source="collector.go:138"
ERRO[0063] collector "bgp" scrape failed: cannot get bgp ipv4 unicast summary: exit status 1  source="collector.go:138"
ERRO[0073] collector "ospf" scrape failed: cannot get ospf interface summary: exit status 1  source="collector.go:138"
ERRO[0079] collector "ospf" scrape failed: cannot get ospf interface summary: exit status 1  source="collector.go:138"
^C

$ frr_exporter --collector.bgp.peer-descriptions --collector.bgp.peer-descriptions.plain-text --no-collector.bfd
INFO[0000] Starting frr_exporter (version=0.2.11, branch=HEAD, revision=7a774985ce8463144f534417d1761ed7b3ff4e19) on :9342  source="frr_exporter.go:118"

Given the recent dockerhub announcement of removing free team orgs, I'm wondering if the current org will be affected? And if so perhaps this could have a high priority? There are other options to use like GHCR or Quay.

docker/hub-feedback#2314

Hello,

We are having an issue with the rr_bgp_rib_count_total counter. We are peering with an uplink provider and in the received routes we are seeing that the received routes in our vrf is not matching with the rib routes.
See screenshot below:

What query is being used to calculate the rib routes? I have checked the code but I am not completely understanding it unfortunately.

Hello,

We notice that not all descriptions in our exporter are complete.

for example I have the result:
frr_bgp_peer_message_received_total{afi="ipv4",local_as="65264",peer="10.189.0.178",peer_as="64822",peer_desc="",safi="unicast",vrf="nni"} 0

While if I run the following command the description is there:

$ sudo vtysh -c "show bgp vrf all neighbors 10.189.0.178 json" | grep Desc
    "nbrDesc":"\"PR-KMDA\"",

Is this expected behaviour and can this be resolved?

frr version:

show version
FRRouting 7.5+cl4.4.0u4 (DC-IX-CORESW02).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
configured with:
    '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--enable-exampledir=/usr/share/doc/frr/examples/' '--localstatedir=/var/run/frr' '--sbindir=/usr/lib/frr' '--sysconfdir=/etc/frr' '--with-vtysh-pager=/usr/bin/pager' '--libdir=/usr/lib/x86_64-linux-gnu/frr' '--with-moduledir=/usr/lib/x86_64-linux-gnu/frr/modules' '--disable-dependency-tracking' '--disable-dev-build' '--enable-systemd=yes' '--enable-rpki' '--with-libpam' '--enable-doc' '--enable-doc-html' '--enable-snmp' '--enable-fpm' '--disable-zeromq' '--enable-ospfapi' '--disable-bgp-vnc' '--enable-multipath=128' '--enable-user=frr' '--enable-group=frr' '--enable-vty-group=frrvty' '--enable-configfile-mask=0640' '--enable-logfile-mask=0640' '--disable-address-sanitizer' '--enable-protobuf' '--enable-cumulus=yes' '--enable-csmgr=yes' '--enable-datacenter=yes' '--enable-bfdd=no' '--enable-sharpd=yes' '--enable-grpc=yes' 'build_alias=x86_64-linux-gnu' 'PYTHON=python3'

In OSPF multi instance deployments we get this error:

level=error ts=2021-12-16T07:57:21.550Z caller=collector.go:122 msg="collector scrape failed" name=ospf duration_seconds=5.1461e-05 err="dial unix /var/run/frr/ospfd.vty: connect: no such file or directory"

But actually ospfd processes up and run

[root@tomsk ~]# ps ax| grep ospf
    438 ?        S<s  504:53 /usr/bin/ospfd -A 127.0.0.1 -d -f /etc/frr/ospfd.conf -F traditional -n 1
    443 ?        S<s  559:10 /usr/bin/ospfd -A 127.0.0.1 -d -f /etc/frr/ospfd.conf -F traditional -n 2
    474 ?        S<s   63:07 /usr/bin/watchfrr -d -r /usr/bin/frr restart %s -s /usr/bin/frr start %s -k /usr/bin/frr stop %s zebra ospfd-1 ospfd-2 pbrd bfdd vrrpd

The sockets:

[root@tomsk ~]# ls -lahta /var/run/frr/
total 32K
drwxr-xr-x 29 root root   860 Dec  8 15:06 ..
drwxr-x---  2 frr  frr    400 Aug  4 20:11 .
-rw-r--r--  1 root root     4 Aug  4 20:11 watchfrr.pid
srwxrwx---  1 root frrvty   0 Aug  4 20:11 watchfrr.vty
-rw-r--r--  1 frr  frr      4 Aug  4 20:11 vrrpd.pid
srwxrwx---  1 frr  frrvty   0 Aug  4 20:11 vrrpd.vty
-rw-r--r--  1 frr  frr      4 Aug  4 20:11 bfdd.pid
srwxrwx---  1 frr  frrvty   0 Aug  4 20:11 bfdd.vty
srwxrwxrwx  1 frr  frr      0 Aug  4 20:11 bfdd.sock
-rw-r--r--  1 frr  frr      4 Aug  4 20:11 pbrd.pid
srwxrwx---  1 frr  frrvty   0 Aug  4 20:11 pbrd.vty
-rw-r--r--  1 frr  frr      4 Aug  4 20:11 ospfd-2.pid
srwxrwx---  1 frr  frrvty   0 Aug  4 20:11 ospfd-2.vty
-rw-r--r--  1 frr  frr      4 Aug  4 20:11 ospfd-1.pid
srwxrwx---  1 frr  frrvty   0 Aug  4 20:11 ospfd-1.vty
-rw-r--r--  1 frr  frr      4 Aug  4 20:11 staticd.pid
srwxrwx---  1 frr  frrvty   0 Aug  4 20:11 staticd.vty
-rw-r--r--  1 frr  frr      4 Aug  4 20:11 zebra.pid
srwxrwx---  1 frr  frrvty   0 Aug  4 20:11 zebra.vty
srwx------  1 frr  frr      0 Aug  4 20:11 zserv.api

The frr configuration is:

## frr.conf
# Ansible managed: frr.j2 modified on 2021-01-26 16:07:21 by k0ste on MacBook-Pro.local
# Do not edit manually

!
hostname tomsk.opentech.local
log monitor informational
log stdout informational
log syslog informational
service integrated-vtysh-config
service advanced-vty
service password-encryption
!
!
ip route 0.0.0.0/0 82.200.72.185 5
ip route 0.0.0.0/0 78.140.13.1 10
ip route 178.49.129.91/32 78.140.13.1
ip route 95.156.85.194/32 82.200.72.185
!
interface lo
 description Loopback0
 ip address 172.16.255.24/32 label Router_ospf
!
interface vlan444
 description vrrp5 neighbor
 vrrp 5
 vrrp 5 priority 254
 vrrp 5 ip 172.16.222.254
!
interface tap0
 description Opentech openvpn to area 0.0.0.2
 ip ospf cost 10
 ip ospf 1 area 0.0.0.2
!
interface tap1
 description Opentech openvpn to area 0.0.0.3
 ip ospf cost 100
 ip ospf 2 area 0.0.0.3
!
router ospf 1
 ospf router-id 172.16.255.24
 log-adjacency-changes detail
 redistribute connected route-map CONNECTED_TO_OSPF
!
router ospf 2
 ospf router-id 172.16.255.24
 log-adjacency-changes detail
 redistribute connected route-map CONNECTED_TO_OSPF
!
access-list vty remark Disable connections to vtysh from non localhost
access-list vty seq 5 permit 127.0.0.1/8
access-list vty seq 10 deny any
!
ip prefix-list OSPF_OPENTECH description Opentech IGP
ip prefix-list OSPF_OPENTECH seq 5 permit 192.168.0.0/16 le 32
ip prefix-list OSPF_OPENTECH seq 10 permit 198.18.0.0/16 le 32
ip prefix-list OSPF_OPENTECH seq 15 permit 198.19.0.0/16 le 32
ip prefix-list OSPF_OPENTECH seq 20 permit 10.100.0.0/16 le 32
ip prefix-list OSPF_OPENTECH seq 25 permit 10.101.0.0/16 le 32
ip prefix-list OSPF_OPENTECH seq 30 permit 10.102.0.0/16 le 32
ip prefix-list OSPF_OPENTECH seq 35 permit 10.110.0.0/16 le 32
ip prefix-list OSPF_OPENTECH seq 40 deny any
!
route-map CONNECTED_TO_OSPF permit 10
 match ip address prefix-list OSPF_OPENTECH
!
route-map CONNECTED_TO_OSPF deny 100
!
line vty
 access-class vty
!

Hi,

We plan to use this exporter in production to monitor our BGP infrastructure, but we need to use it as a docker container. With current architecture this is not possible because of exporter using local vtysh binary with hard-coded options.

My proposal is pack vtysh together with frr_exporter binary in docker image and allow to set some vtysh options as a exporter argument.
In my case additional arguments are vtysh --config_dir / tmp --vty_socket / run / frr and option may looks like --frr.vtysh.options = "- config_dir / tmp --vty_socket / run / frr". This will allow use host-machine's vty socket and frr configs inside a docker container.

What do you think about it @tynany?

I was testing frr_exporter 0.2.20 plus cherry-picked commits from #46 and #48 on our stack and these collectors failed:

ts=2021-12-08T13:26:08.494Z caller=collector.go:115 level=error msg="collector scrape failed" name=bgpl2vpn duration_seconds=0.137072109 err="invalid character 'B' looking for beginning of value"
ts=2021-12-08T13:26:08.495Z caller=collector.go:115 level=error msg="collector scrape failed" name=bgp duration_seconds=0.137116631 err="invalid character 'B' looking for beginning of value"
ts=2021-12-08T13:26:08.495Z caller=collector.go:115 level=error msg="collector scrape failed" name=bgp6 duration_seconds=0.137320957 err="invalid character 'B' looking for beginning of value"

Used arguments:

--collector.bgp.peer-descriptions --collector.bgp.peer-descriptions.plain-text --collector.bgp6 --collector.bgpl2vpn --no-collector.ospf

This error message is not very helpful since it is not clear what data the collector tried to parse.

# ./frr_exporter --collector.bfd=disabled
frr_exporter: error: unexpected disabled, try --help
# ./frr_exporter --nocollector.bfd
frr_exporter: error: unknown long flag '--nocollector.bfd', try --help

Without collector disablement we will receive on each prometheus query something like

level=error ts=2021-12-16T07:53:54.230Z caller=collector.go:122 msg="collector scrape failed" name=bgp duration_seconds=0.00049952 err="dial unix /var/run/frr/bgpd.vty: connect: no such file or directory"

Using vtysh to interact with FRR is slow and can be dangerous if not properly maintained (e.g. lead to a fork bomb).

frr_exporter should move to interface with FRR via the UNIX daemons that are usually exposed under /var/run/frr.

We are running frr_exporter using the tynany/frr_exporter:v1.1.4 docker image with the arguments

--web.listen-address=<removed>:9342
--frr.socket.dir-path=/frr_sockets
--no-collector.ospf
--collector.bgp.peer-descriptions
--collector.bgp.peer-descriptions.plain-text

and a /var/run/frr:/frr_sockets:rw volume, exposing all daemons through /frr_sockets.

Running the container, we repeatedly get the following error:

ts=2023-04-17T10:41:00.837Z caller=collector.go:126 level=error msg="collector scrape failed" name=bfd duration_seconds=0.133992136 err="command /usr/bin/vtysh -c show bfd peers json failed: exit status 1: stderr: % Can't open configuration file /etc/frr/vtysh.conf due to 'No such file or directory'. Exiting: failed to connect to any daemons. : stdout: "

It seems as if the exporter is trying to gather BFD metrics by parsing /usr/bin/vtysh output, instead of interfacing with bfdd.sock in /frr_sockets. Since vtysh cannot access /etc/frr/vtysh.conf within the container, it throws an error.
According to the documentation, I would expect the exporter not to use vtysh for BFD metrics with our configuration but to interface with the respective daemon directly, as it does with BGP.

Hello. Is it possible for you to implement a function so that we can check what routes are being advertised for a prefix with frr_exporter? Example output with vtysh:
vtysh -c 'sh ip bgp nei <prefix> advertised-routes'

Hello and thanks for developing this exporter!

bgpl2vpn collector causes panic to the exporter like:

ubuntu@removeme2:~$ sudo ./frr_exporter --log.level=debug --no-collector.ospf --no-collector.bfd --collector.bgpl2vpn --co
llector.bgp                                                  
level=info ts=2021-12-13T11:29:56.653Z caller=frr_exporter.go:65 msg="Starting frr_exporter" version="(version=, branch=master, revision=88e396e1a2c57820970ab7b09a76e218f54a9f4a)"
level=info ts=2021-12-13T11:29:56.653Z caller=frr_exporter.go:66 msg="Build context" build_context="(go=go1.16.10, user=, date=)"
level=info ts=2021-12-13T11:29:56.653Z caller=frr_exporter.go:67 msg="Listening on address" address=:9342
level=info ts=2021-12-13T11:29:56.653Z caller=tls_config.go:191 msg="TLS is disabled." http2=false
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x60 pc=0x7f0b46]

goroutine 30 [running]:
github.com/prometheus/client_golang/prometheus.NewConstMetric(0x0, 0x2, 0x0, 0xc0000d78c0, 0x4, 0x4, 0xc000103860, 0x1, 0xc0001815f0, 0x93c760)
        /go/pkg/mod/github.com/prometheus/[email protected]/prometheus/value.go:88 +0x26
github.com/prometheus/client_golang/prometheus.MustNewConstMetric(...)
        /go/pkg/mod/github.com/prometheus/[email protected]/prometheus/value.go:105
github.com/tynany/frr_exporter/collector.newGauge(0xc0000206c0, 0x0, 0x0, 0xc0000d78c0, 0x4, 0x4)
        /app/collector/collector.go:146 +0x76
github.com/tynany/frr_exporter/collector.processBGPSummary(0xc0000206c0, 0xc0001c4000, 0x2d3, 0x2d3, 0x9f9160, 0x5, 0x9f86ae, 0x4, 0xa9eae0, 0xc000081220, ...)
        /app/collector/bgp.go:194 +0x43a
github.com/tynany/frr_exporter/collector.collectBGP(0xc0000206c0, 0x9f9160, 0x5, 0xa9eae0, 0xc000081220, 0xc00017da40, 0x0, 0x0)
        /app/collector/bgp.go:164 +0x1fb
github.com/tynany/frr_exporter/collector.(*bgpL2VPNCollector).Update(0xc0000a3470, 0xc0000206c0, 0xdd6360, 0x0)
        /app/collector/bgp.go:103 +0x77
github.com/tynany/frr_exporter/collector.runCollector(0xc0000206c0, 0xc0000ad3f0, 0x8, 0xa9ece0, 0xc0000a3470, 0xc000024624, 0xa9eae0, 0xc000080fa0)
        /app/collector/collector.go:115 +0xb8
created by github.com/tynany/frr_exporter/collector.(*Exporter).Collect
        /app/collector/collector.go:106 +0x1a5

The FRR configuration merely enables l2vpn and looks like this:

root@removeme2:~# cat /etc/frr/frr.conf 
# default to using syslog. /etc/rsyslog.d/45-frr.conf places the log
# in /var/log/frr/frr.log
log syslog debug
router bgp 65199
  no bgp default ipv4-unicast
  bgp router-id 1.1.1.1
  neighbor fabric peer-group
  neighbor fabric remote-as 65199
  neighbor fabric capability extended-nexthop
  neighbor 1.2.3.4 peer-group fabric
  !
  address-family l2vpn evpn
   neighbor fabric activate
   advertise-all-vni
  exit-address-family
  !
!

The frr_exporter in use has been built out of 88e396e commit.

To my understanding, the cause of the panic is that bgpDesc["ribCount"] (and the rest of bgpDesc prometheus metrics descriptor here) is null. The regression is probably related to changes of 120ff2a.

Perhaps, processBGPSummary shouldn't be used at all for l2vpn address family? And use processBgpL2vpnEvpnSummary instead?

I'll be happy to assist in any way I can.

Hello,

I'm trying to get neighbour descriptions into metric labels, but it appears to not be working:

[root@router]# vtysh -c "show run" | grep "^ neighbor"
 neighbor iBGP peer-group
 neighbor iBGP remote-as 64999
 neighbor 10.10.10.9 peer-group iBGP
 neighbor 10.10.10.9 description fw1
 neighbor 10.10.10.10 peer-group iBGP
 neighbor 10.10.10.10 description fw2

[root@router]# ps aux | grep frr_exporter
frr       458344  0.0  0.8 113892 15984 ?        Ssl  08:17   0:00 /usr/bin/frr_exporter --collector.bgp.peer-descriptions.plain-text

[root@router]# frr_exporter --version
frr_exporter, version 0.2.9 (branch: HEAD, revision: b4ffae4535ef670aa0b9522ade2186ea601dbd7c)
  build user:       root@91ce865070a8
  build date:       20200914-10:09:15
  go version:       go1.13.15

Despite the fact that descriptions are set and --collector.bgp.peer-descriptions.plain-text flag is set, neighbour descriptions do not appear in metrics:

[root@zh4labklb1a ~]# curl -s localhost:9342/metrics | grep _bgp_
# HELP frr_bgp_peer_groups_count_total Number of peer groups configured.
# TYPE frr_bgp_peer_groups_count_total gauge
frr_bgp_peer_groups_count_total{afi="ipv4",local_as="64999",safi="unicast",vrf="default"} 1
# HELP frr_bgp_peer_groups_memory_bytes Memory consumed by peer groups.
# TYPE frr_bgp_peer_groups_memory_bytes gauge
frr_bgp_peer_groups_memory_bytes{afi="ipv4",local_as="64999",safi="unicast",vrf="default"} 64
# HELP frr_bgp_peer_message_received_total Number of received messages.
# TYPE frr_bgp_peer_message_received_total counter
frr_bgp_peer_message_received_total{afi="ipv4",local_as="64999",peer="10.10.10.10",peer_as="64999",safi="unicast",vrf="default"} 67627
frr_bgp_peer_message_received_total{afi="ipv4",local_as="64999",peer="10.10.10.9",peer_as="64999",safi="unicast",vrf="default"} 66087
# HELP frr_bgp_peer_message_sent_total Number of sent messages.
# TYPE frr_bgp_peer_message_sent_total counter
frr_bgp_peer_message_sent_total{afi="ipv4",local_as="64999",peer="10.10.10.10",peer_as="64999",safi="unicast",vrf="default"} 65145
frr_bgp_peer_message_sent_total{afi="ipv4",local_as="64999",peer="10.10.10.9",peer_as="64999",safi="unicast",vrf="default"} 65138
# HELP frr_bgp_peer_prefixes_received_count_total Number of prefixes received.
# TYPE frr_bgp_peer_prefixes_received_count_total gauge
frr_bgp_peer_prefixes_received_count_total{afi="ipv4",local_as="64999",peer="10.10.10.10",peer_as="64999",safi="unicast",vrf="default"} 0
frr_bgp_peer_prefixes_received_count_total{afi="ipv4",local_as="64999",peer="10.10.10.9",peer_as="64999",safi="unicast",vrf="default"} 0
# HELP frr_bgp_peer_state State of the peer (1 = Established, 0 = Down).
# TYPE frr_bgp_peer_state gauge
frr_bgp_peer_state{afi="ipv4",local_as="64999",peer="10.10.10.10",peer_as="64999",safi="unicast",vrf="default"} 1
frr_bgp_peer_state{afi="ipv4",local_as="64999",peer="10.10.10.9",peer_as="64999",safi="unicast",vrf="default"} 1
# HELP frr_bgp_peer_uptime_seconds How long has the peer been up.
# TYPE frr_bgp_peer_uptime_seconds gauge
frr_bgp_peer_uptime_seconds{afi="ipv4",local_as="64999",peer="10.10.10.10",peer_as="64999",safi="unicast",vrf="default"} 1.891938e+06
frr_bgp_peer_uptime_seconds{afi="ipv4",local_as="64999",peer="10.10.10.9",peer_as="64999",safi="unicast",vrf="default"} 1.891697e+06
# HELP frr_bgp_peers_count_total Number peers configured.
# TYPE frr_bgp_peers_count_total gauge
frr_bgp_peers_count_total{afi="ipv4",local_as="64999",safi="unicast",vrf="default"} 2
# HELP frr_bgp_peers_memory_bytes Memory consumed by peers.
# TYPE frr_bgp_peers_memory_bytes gauge
frr_bgp_peers_memory_bytes{afi="ipv4",local_as="64999",safi="unicast",vrf="default"} 43616
# HELP frr_bgp_rib_count_total Number of routes in the RIB.
# TYPE frr_bgp_rib_count_total gauge
frr_bgp_rib_count_total{afi="ipv4",local_as="64999",safi="unicast",vrf="default"} 547
# HELP frr_bgp_rib_memory_bytes Memory consumbed by the RIB.
# TYPE frr_bgp_rib_memory_bytes gauge
frr_bgp_rib_memory_bytes{afi="ipv4",local_as="64999",safi="unicast",vrf="default"} 105024

Can you please help me with this issue?

Hello,

I have a FRR server (v7.5.1) running in Route Server mode.
Some of the neighbors advertise prefixes over the l2vpn evpn AFI/SAFI, so I've enabled the bgp l2vpn collector with the flag --collector.bgpl2vpn

However, I encounter this error at each scrape:
ERRO[0004] collector "bgpl2vpn" scrape failed: cannot unmarshal outputs of 'show evpn vni json': unexpected end of JSON input source="collector.go:138"

Indeed, if I run this command show evpn vni json in vtysh on my route server, I do not have any output (that's expected as I don't have any VRF/VXLAN/VNI configured locally).

I'll propose a PR to fix this.

Hi @tynany,

I would love to be able to run your prometheus exporter without root privileges when vtysh command is needed.

This PR #27 implement the described logic.

When running without root privileges, sudo is invoked and we need this kind of sudo stanza to make it work:

username ALL=(ALL) NOPASSWD: /usr/bin/vtysh -c show *

Regards,
gunhu.

Hello,

I am trying out the FRR Exporter on a lab environment, and I am running into issues when I try to obtain data from FRR Exporter. This is the error message:

err="cannot process output of show bgp vrf all ipv4 unicast summary json: json: cannot unmarshal number 8465643000 into Go struct field bgpPeerSession.Peers.PeerUptimeMsec of type uint32

Full output:

level=info ts=2022-05-17T17:46:34.056Z caller=frr_exporter.go:65 msg="Starting frr_exporter" version="(version=1.1.1, branch=HEAD, revision=d0d5ec547513a0995543e1da6f44d18491d0e44f)"
level=info ts=2022-05-17T17:46:34.056Z caller=frr_exporter.go:66 msg="Build context" build_context="(go=go1.17.9, user=root@e633ce4eab46, date=20220423-00:54:13)"
level=info ts=2022-05-17T17:46:34.056Z caller=frr_exporter.go:67 msg="Listening on address" address=[fc00::115b]:9342
level=info ts=2022-05-17T17:46:34.057Z caller=tls_config.go:191 msg="TLS is disabled." http2=false


level=error ts=2022-05-17T17:46:40.374Z caller=collector.go:126 msg="collector scrape failed" name=bgp duration_seconds=0.002062469 err="cannot process output of show bgp vrf all ipv4 unicast summary json: json: cannot unmarshal number 8465643000 into Go struct field bgpPeerSession.Peers.PeerUptimeMsec of type uint32: command output: {\n\"default\":{\n  \"routerId\":\"10.1.24.16\",\n  \"as\":4200020115,\n  \"vrfId\":0,\n  \"vrfName\":\"default\",\n  \"tableVersion\":66,\n  \"ribCount\":9,\n  \"ribMemory\":1728,\n  \"peerCount\":2,\n  \"peerMemory\":43616,\n  \"peerGroupCount\":1,\n  \"peerGroupMemory\":64,\n  \"peers\":{\n    \"swp10\":{\n      \"hostname\":\"ENGSW14L\",\n      \"remoteAs\":4200010114,\n      \"version\":4,\n      \"msgRcvd\":2823776,\n      \"msgSent\":2824093,\n      \"tableVersion\":0,\n      \"outq\":0,\n      \"inq\":0,\n      \"peerUptime\":\"13w6d23h\",\n      \"peerUptimeMsec\":8465643000,\n      \"peerUptimeEstablishedEpoch\":1644343957,\n      \"pfxRcd\":4,\n      \"pfxSnt\":5,\n      \"state\":\"Established\",\n      \"connectionsEstablished\":7,\n      \"connectionsDropped\":6,\n      \"idType\":\"interface\"\n    },\n    \"172.20.24.5\":{\n      \"hostname\":\"engsw18\",\n      \"remoteAs\":4200000118,\n      \"version\":4,\n      \"msgRcvd\":2823769,\n      \"msgSent\":2824066,\n      \"tableVersion\":0,\n      \"outq\":0,\n      \"inq\":0,\n      \"peerUptime\":\"09w0d16h\",\n      \"peerUptimeMsec\":5500966000,\n      \"peerUptimeEstablishedEpoch\":1647308634,\n      \"pfxRcd\":4,\n      \"pfxSnt\":5,\n      \"state\":\"Established\",\n      \"connectionsEstablished\":5,\n      \"connectionsDropped\":4,\n      \"idType\":\"ipv4\"\n    }\n  },\n  \"failedPeers\":0,\n  \"totalPeers\":2,\n  \"dynamicPeers\":0,\n  \"bestPath\":{\n    \"multiPathRelax\":\"true\"\n  }\n}\n}\n"

Arguments passed:
ARGS=" --collector.bgp.peer-descriptions --collector.bgp.peer-descriptions.plain-text --collector.bgp6 --collector.bgpl2vpn --no-collector.ospf "

Code is looking for a JSON response to a plain-text value:

Error Log:

Dec  1 11:14:44 gwxx prometheus-frr-exporter[29010]: time="2021-12-01T11:14:44Z" level=error msg="collector \"bgp\" scrape failed: cannot unmarshall bgp description cr2-txl for peer y.y.y.y : invalid character 'c' looking for beginning of value" source="collector.go:144"
Dec  1 11:14:44 gwxx prometheus-frr-exporter[29010]: time="2021-12-01T11:14:44Z" level=error msg="collector \"bgp\" scrape failed: cannot unmarshall bgp description cr1-txl for peer x.x.x.x : invalid character 'c' looking for beginning of value" source="collector.go:144"
Dec  1 11:14:44 gwxx prometheus-frr-exporter[29010]: time="2021-12-01T11:14:44Z" level=error msg="collector \"bgp\" scrape failed: cannot unmarshall bgp description cr2-txl for peer x.x.x.x : invalid character 'c' looking for beginning of value" source="collector.go:144" 

Configuration:

frr defaults traditional
hostname gwxx
log file /var/log/frr/frr-debug.log
service integrated-vtysh-config
!
router-id x.x.x.x
!
router bgp 65521
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 bgp bestpath as-path multipath-relax
 neighbor pservers peer-group
 neighbor pservers remote-as 65522
 neighbor pservers bfd
 neighbor pservers capability extended-nexthop
 neighbor x.x.x.x remote-as 0000
 neighbor x.x.x.x description cr1-txl
 neighbor x.x.x.x bfd
 neighbor x.x.x.x update-source x.x.x.x
 neighbor x.x.x.x capability extended-nexthop
 neighbor x.x.x.x remote-as 0000
 neighbor x.x.x.x description cr2-txl
 neighbor x.x.x.x bfd
 neighbor x.x.x.x update-source x.x.x.x
 neighbor x.x.x.x capability extended-nexthop
 neighbor x:x:x:x:x::x remote-as 0000
 neighbor x:x:x:x:x::x description cr1-txl
 neighbor x:x:x:x:x::x bfd
 neighbor x:x:x:x:x::x update-source x:x:x:x:x::x
 neighbor x:x:x:x:x::x capability extended-nexthop
 neighbor x:x:x:x:x::x remote-as 0000
 neighbor x:x:x:x:x::x description cr2-txl
 neighbor x:x:x:x:x::x bfd
 neighbor x:x:x:x:x::x update-source x:x:x:x:x::x
 neighbor x:x:x:x:x::x capability extended-nexthop
 bgp listen limit 4096
 bgp listen range y.y.y.y/20 peer-group pservers
 !
 address-family ipv4 unicast
  neighbor pservers activate
  neighbor pservers next-hop-self
  neighbor pservers prefix-list from_pserver in
  neighbor pservers prefix-list to_pserver out
  neighbor x.x.x.x activate
  neighbor x.x.x.x next-hop-self
  neighbor x.x.x.x prefix-list from_core_router in
  neighbor x.x.x.x prefix-list to_core_router out
  neighbor x.x.x.x activate
  neighbor x.x.x.x next-hop-self
  neighbor x.x.x.x prefix-list from_core_router in
  neighbor x.x.x.x prefix-list to_core_router out
 exit-address-family
 !
 address-family ipv6 unicast
  neighbor pservers activate
  neighbor pservers next-hop-self
  neighbor pservers prefix-list from_pserver_v6 in
  neighbor pservers prefix-list to_pserver_v6 out
  neighbor x:x:x:x:x::x activate
  neighbor x:x:x:x:x::x next-hop-self
  neighbor x:x:x:x:x::x activate
  neighbor x:x:x:x:x::x next-hop-self
 exit-address-family
!
ip prefix-list from_core_router seq 5 permit 0.0.0.0/0
ip prefix-list from_pserver seq 5 permit x.x.x.x/21 le 32
ip prefix-list to_core_router seq 5 permit x.x.x.x/21 le 32
ip prefix-list to_pserver seq 5 permit x.x.x.x/21 le 32
!
line vty
!
bfd
!
end

To add the scrape is successful with peer names however, these errors cause panic

The BFD collector and BGP description functions in the BGP collector were never moved to the new execVtyshCommand helper function, so the --frr.vtysh.sudo & --frr.vtysh.options flags are not used.

Running into the following issue:

cumulus@leaf01:~/frr_exporter$ sudo /usr/local/go/bin/go run frr_exporter.go

command-line-arguments

./frr_exporter.go:58:19: cannot use ne (type *collector.Exporters) as type "github.com/prometheus/client_golang/prometheus".Collector in argument to registry.Register:
*collector.Exporters does not implement "github.com/prometheus/client_golang/prometheus".Collector (wrong type for Collect method)
have Collect(chan<- "github.com/tynany/frr_exporter/vendor/github.com/prometheus/client_golang/prometheus".Metric)
want Collect(chan<- "github.com/prometheus/client_golang/prometheus".Metric)

Hello,

There appears to be a new release of frr_exporter, 1.1.1 which fixes the resource leak mentioned in #63. That release does not have a corresponding docker image. Any chance for an official build with tag 1.1.1?

Thank you!

Pawel

• v0.2.8 from https://github.com/tynany/frr_exporter/releases/download/v0.2.8/frr_exporter_0.2.8_linux_x86_64.tar.gz

$ ./frr_exporter --version
frr_exporter, version  (branch: , revision: )
  build user:
  build date:
  go version:       go1.13.14

• v0.28 & self build

$ go version
go version go1.14.3 linux/amd64

$ go build
go: downloading github.com/prometheus/common v0.10.0
go: downloading github.com/prometheus/client_golang v1.7.1
go: downloading github.com/alecthomas/units v0.0.0-20190924025748-f65c72e2690d
go: downloading github.com/sirupsen/logrus v1.6.0
go: downloading github.com/golang/protobuf v1.4.2
go: downloading github.com/prometheus/procfs v0.1.3
go: downloading golang.org/x/sys v0.0.0-20200625212154-ddb9806d33ae
go: downloading google.golang.org/protobuf v1.25.0

$ ./frr_exporter --version
frr_exporter, version  (branch: , revision: )
  build user:
  build date:
  go version:       go1.14.3

• expected output format (node_exporter's output)

$ node_exporter --version
node_exporter, version 1.0.1 (branch: HEAD, revision: 3715be6ae899f2a9b9dbfd9c39f3e09a7bd4559f)
  build user:       root@1f76dbbcfa55
  build date:       20200616-12:44:12
  go version:       go1.14.4

Hello,

We upgraded towards version 1.1.2 but we are seeing the following issue below:
msg="collector scrape failed" name=bgp duration_seconds=0.058906413 err="cannot process output of show bgp vrf all ipv4 unicast summary json: unexpected end of JSON input: command output: {\n\"default\":{\n \"routerId\":\"10.11.193.2\",\n \"as\":65237,\n \"vrfId\":0,\n \"vrfName\":\"default\",\n \"tableVersion\":2013,\n \"ribCount\":113,\n \"ribMemory\":22600,\n \"peerCount\":10,\n \"peerMemory\":233760,\n \"peerGroupCount\":4,\n \"peerGroupMemory\":256,\n \"peers\":{\n \"10.11.192.45\":{\n \"hostname\":\"borax\",\n \"remoteAs\":65224,\n \"version\":4,\n \"msgRcvd\":15495697,\n \"msgSent\":16552925,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"04:14:21\",\n \"peerUptimeMsec\":15261000,\n \"peerUptimeEstablishedEpoch\":1661762601,\n \"pfxRcd\":2,\n \"pfxSnt\":10,\n \"state\":\"Established\",\n \"connectionsEstablished\":3,\n \"connectionsDropped\":2,\n \"idType\":\"ipv4\"\n },\n \"10.11.192.53\":{\n \"hostname\":\"bruno\",\n \"remoteAs\":65225,\n \"version\":4,\n \"msgRcvd\":146401702,\n \"msgSent\":128100078,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"14w6d15h\",\n \"peerUptimeMsec\":9043150000,\n \"peerUptimeEstablishedEpoch\":1652734712,\n \"pfxRcd\":5,\n \"pfxSnt\":10,\n \"state\":\"Established\",\n \"connectionsEstablished\":1,\n \"connectionsDropped\":0,\n \"idType\":\"ipv4\"\n },\n \"10.11.192.61\":{\n \"hostname\":\"julius\",\n \"remoteAs\":65226,\n \"version\":4,\n \"msgRcvd\":168398736,\n \"msgSent\":128074402,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"14w0d00h\",\n \"peerUptimeMsec\":8468008000,\n \"peerUptimeEstablishedEpoch\":1653309854,\n \"pfxRcd\":5,\n \"pfxSnt\":10,\n \"state\":\"Established\",\n \"connectionsEstablished\":2,\n \"connectionsDropped\":1,\n \"idType\":\"ipv4\"\n },\n \"10.11.192.69\":{\n \"remoteAs\":65242,\n \"version\":4,\n \"msgRcvd\":3444661,\n \"msgSent\":3015008,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"14w6d16h\",\n \"peerUptimeMsec\":9043336000,\n \"peerUptimeEstablishedEpoch\":1652734526,\n \"pfxRcd\":1,\n \"pfxSnt\":5,\n \"state\":\"Established\",\n \"connectionsEstablished\":1,\n \"connectionsDropped\":0,\n \"idType\":\"ipv4\"\n },\n \"10.11.192.5\":{\n \"hostname\":\"mewtwo\",\n \"remoteAs\":65001,\n \"version\":4,\n \"msgRcvd\":3013708,\n \"msgSent\":3013717,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"05:29:23\",\n \"peerUptimeMsec\":19763000,\n \"peerUptimeEstablishedEpoch\":1661758099,\n \"pfxRcd\":5,\n \"pfxSnt\":7,\n \"state\":\"Established\",\n \"connectionsEstablished\":48,\n \"connectionsDropped\":47,\n \"idType\":\"ipv4\"\n },\n \"10.11.192.21\":{\n \"remoteAs\":65506,\n \"version\":4,\n \"msgRcvd\":0,\n \"msgSent\":0,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"never\",\n \"peerUptimeMsec\":0,\n \"pfxRcd\":0,\n \"state\":\"Idle (Admin)\",\n \"connectionsEstablished\":0,\n \"connectionsDropped\":0,\n \"idType\":\"ipv4\"\n },\n \"swp48\":{\n \"hostname\":\"DC-IX-CORESW01\",\n \"remoteAs\":65234,\n \"version\":4,\n \"msgRcvd\":131145939,\n \"msgSent\":128100948,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"01w4d15h\",\n \"peerUptimeMsec\":1007473000,\n \"peerUptimeEstablishedEpoch\":1660770389,\n \"pfxRcd\":49,\n \"pfxSnt\":56,\n \"state\":\"Established\",\n \"connectionsEstablished\":2,\n \"connectionsDropped\":1,\n \"idType\":\"interface\"\n },\n \"swp53\":{\n \"hostname\":\"DC-LCL-CORESW01\",\n \"remoteAs\":65236,\n \"version\":4,\n \"msgRcvd\":155333619,\n \"msgSent\":128104743,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"04w0d03h\",\n \"peerUptimeMsec\":2432273000,\n \"peerUptimeEstablishedEpoch\":1659345589,\n \"pfxRcd\":43,\n \"pfxSnt\":56,\n \"state\":\"Established\",\n \"connectionsEstablished\":3,\n \"connectionsDropped\":2,\n \"idType\":\"interface\"\n },\n \"swp54\":{\n \"hostname\":\"DC-LCL-CORESW01\",\n \"remoteAs\":65236,\n \"version\":4,\n \"msgRcvd\":155333620,\n \"msgSent\":128105060,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"04w0d03h\",\n \"peerUptimeMsec\":2432274000,\n \"peerUptimeEstablishedEpoch\":1659345588,\n \"pfxRcd\":43,\n \"pfxSnt\":56,\n \"state\":\"Established\",\n \"connectionsEstablished\":3,\n \"connectionsDropped\":2,\n \"idType\":\"interface\"\n },\n \"swp56\":{\n \"hostname\":\"DC-IX-CORESW02\",\n \"remoteAs\":65235,\n \"version\":4,\n \"msgRcvd\":17468827,\n \"msgSent\":16416336,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"01w4d16h\",\n \"peerUptimeMsec\":1008055000,\n \"peerUptimeEstablishedEpoch\":1660769807,\n \"pfxRcd\":41,\n \"pfxSnt\":56,\n \"state\":\"Established\",\n \"connectionsEstablished\":1,\n \"connectionsDropped\":0,\n \"idType\":\"interface\"\n }\n },\n \"failedPeers\":1,\n \"totalPeers\":10,\n \"dynamicPeers\":0,\n \"bestPath\":{\n \"multiPathRelax\":\"false\"\n }\n}\n,\n\"nni\":{\n \"routerId\":\"10.11.194.2\",\n \"as\":65267,\n \"vrfId\":194,\n \"vrfName\":\"nni\",\n \"tableVersion\":143706,\n \"ribCount\":541,\n \"ribMemory\":108200,\n \"peerCount\":34,\n \"peerMemory\":794784,\n \"peerGroupCount\":4,\n \"peerGroupMemory\":256,\n \"peers\":{\n \"172.31.255.213\":{\n \"remoteAs\":65100,\n \"version\":4,\n \"msgRcvd\":83516,\n \"msgSent\":80581,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"03w6d23h\",\n \"peerUptimeMsec\":2416363000,\n \"peerUptimeEstablishedEpoch\":1659361499,\n \"pfxRcd\":2,\n \"pfxSnt\":1,\n \"state\":\"Established\",\n \"connectionsEstablished\":1,\n \"connectionsDropped\":0,\n \"idType\":\"ipv4\"\n },\n \"10.11.192.13\":{\n \"hostname\":\"mewtwo\",\n \"remoteAs\":65002,\n \"version\":4,\n \"msgRcvd\":3029477,\n \"msgSent\":3053105,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"05:29:21\",\n \"peerUptimeMsec\":19761000,\n \"peerUptimeEstablishedEpoch\":1661758101,\n \"pfxRcd\":39,\n \"pfxSnt\":272,\n \"state\":\"Established\",\n \"connectionsEstablished\":254,\n \"connectionsDropped\":253,\n \"idType\":\"ipv4\"\n },\n \"10.11.192.29\":{\n \"remoteAs\":65506,\n \"version\":4,\n \"msgRcvd\":0,\n \"msgSent\":0,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"never\",\n \"peerUptimeMsec\":0,\n \"pfxRcd\":0,\n \"state\":\"Idle (Admin)\",\n \"connectionsEstablished\":0,\n \"connectionsDropped\":0,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.3\":{\n \"remoteAs\":64831,\n \"version\":4,\n \"msgRcvd\":0,\n \"msgSent\":0,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"never\",\n \"peerUptimeMsec\":0,\n \"pfxRcd\":0,\n \"state\":\"Idle (Admin)\",\n \"connectionsEstablished\":0,\n \"connectionsDropped\":0,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.11\":{\n \"remoteAs\":64832,\n \"version\":4,\n \"msgRcvd\":0,\n \"msgSent\":0,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"never\",\n \"peerUptimeMsec\":0,\n \"pfxRcd\":0,\n \"state\":\"Idle (Admin)\",\n \"connectionsEstablished\":0,\n \"connectionsDropped\":0,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.18\":{\n \"remoteAs\":64835,\n \"version\":4,\n \"msgRcvd\":0,\n \"msgSent\":0,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"never\",\n \"peerUptimeMsec\":0,\n \"pfxRcd\":0,\n \"state\":\"Idle (Admin)\",\n \"connectionsEstablished\":0,\n \"connectionsDropped\":0,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.26\":{\n \"remoteAs\":64836,\n \"version\":4,\n \"msgRcvd\":0,\n \"msgSent\":0,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"never\",\n \"peerUptimeMsec\":0,\n \"pfxRcd\":0,\n \"state\":\"Idle (Admin)\",\n \"connectionsEstablished\":0,\n \"connectionsDropped\":0,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.34\":{\n \"remoteAs\":64833,\n \"version\":4,\n \"msgRcvd\":0,\n \"msgSent\":0,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"never\",\n \"peerUptimeMsec\":0,\n \"pfxRcd\":0,\n \"state\":\"Idle (Admin)\",\n \"connectionsEstablished\":0,\n \"connectionsDropped\":0,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.42\":{\n \"remoteAs\":64834,\n \"version\":4,\n \"msgRcvd\":0,\n \"msgSent\":0,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"never\",\n \"peerUptimeMsec\":0,\n \"pfxRcd\":0,\n \"state\":\"Idle (Admin)\",\n \"connectionsEstablished\":0,\n \"connectionsDropped\":0,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.50\":{\n \"remoteAs\":64801,\n \"version\":4,\n \"msgRcvd\":10257749,\n \"msgSent\":8978507,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"17:59:20\",\n \"peerUptimeMsec\":64760000,\n \"peerUptimeEstablishedEpoch\":1661713102,\n \"pfxRcd\":0,\n \"state\":\"Connect\",\n \"connectionsEstablished\":7,\n \"connectionsDropped\":7,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.58\":{\n \"remoteAs\":64803,\n \"version\":4,\n \"msgRcvd\":10330891,\n \"msgSent\":9043125,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"3d15h44m\",\n \"peerUptimeMsec\":315851000,\n \"peerUptimeEstablishedEpoch\":1661462011,\n \"pfxRcd\":9,\n \"pfxSnt\":1,\n \"state\":\"Established\",\n \"connectionsEstablished\":18,\n \"connectionsDropped\":17,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.66\":{\n \"remoteAs\":64805,\n \"version\":4,\n \"msgRcvd\":10197271,\n \"msgSent\":8925883,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"1d21h33m\",\n \"peerUptimeMsec\":163995000,\n \"peerUptimeEstablishedEpoch\":1661613867,\n \"pfxRcd\":1,\n \"pfxSnt\":1,\n \"state\":\"Established\",\n \"connectionsEstablished\":30,\n \"connectionsDropped\":29,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.74\":{\n \"remoteAs\":64807,\n \"version\":4,\n \"msgRcvd\":10332021,\n \"msgSent\":9043276,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"3d15h44m\",\n \"peerUptimeMsec\":315851000,\n \"peerUptimeEstablishedEpoch\":1661462011,\n \"pfxRcd\":7,\n \"pfxSnt\":1,\n \"state\":\"Established\",\n \"connectionsEstablished\":17,\n \"connectionsDropped\":16,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.82\":{\n \"remoteAs\":64809,\n \"version\":4,\n \"msgRcvd\":10329557,\n \"msgSent\":9041493,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"3d06h51m\",\n \"peerUptimeMsec\":283912000,\n \"peerUptimeEstablishedEpoch\":1661493950,\n \"pfxRcd\":4,\n \"pfxSnt\":1,\n \"state\":\"Established\",\n \"connectionsEstablished\":9,\n \"connectionsDropped\":8,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.90\":{\n \"remoteAs\":64811,\n \"version\":4,\n \"msgRcvd\":10320810,\n \"msgSent\":9032954,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"1d21h33m\",\n \"peerUptimeMsec\":163991000,\n \"peerUptimeEstablishedEpoch\":1661613871,\n \"pfxRcd\":1,\n \"pfxSnt\":1,\n \"state\":\"Established\",\n \"connectionsEstablished\":82,\n \"connectionsDropped\":81,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.98\":{\n \"remoteAs\":64812,\n \"version\":4,\n \"msgRcvd\":3441595,\n \"msgSent\":3012163,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"4d03h35m\",\n \"peerUptimeMsec\":358535000,\n \"peerUptimeEstablishedEpoch\":1661419327,\n \"pfxRcd\":3,\n \"pfxSnt\":1,\n \"state\":\"Established\",\n \"connectionsEstablished\":12,\n \"connectionsDropped\":11,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.106\":{\n \"remoteAs\":64813,\n \"version\":4,\n \"msgRcvd\":3443567,\n \"msgSent\":3013639,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"06w4d06h\",\n \"peerUptimeMsec\":3997488000,\n \"peerUptimeEstablishedEpoch\":1657780374,\n \"pfxRcd\":3,\n \"pfxSnt\":1,\n \"state\":\"Established\",\n \"connectionsEstablished\":4,\n \"connectionsDropped\":3,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.114\":{\n \"remoteAs\":64814,\n \"version\":4,\n \"msgRcvd\":10297446,\n \"msgSent\":9013735,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"4d15h28m\",\n \"peerUptimeMsec\":401290000,\n \"peerUptimeEstablishedEpoch\":1661376572,\n \"pfxRcd\":4,\n \"pfxSnt\":1,\n \"state\":\"Established\",\n \"connectionsEstablished\":12,\n \"connectionsDropped\":11,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.122\":{\n \"remoteAs\":64815,\n \"version\":4,\n \"msgRcvd\":10331908,\n \"msgSent\":9043123,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"03w6d14h\",\n \"peerUptimeMsec\":2385921000,\n \"peerUptimeEstablishedEpoch\":1659391941,\n \"pfxRcd\":2,\n \"pfxSnt\":1,\n \"state\":\"Established\",\n \"connectionsEstablished\":5,\n \"connectionsDropped\":4,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.130\":{\n \"remoteAs\":64816,\n \"version\":4,\n \"msgRcvd\":10332045,\n \"msgSent\":9042964,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"02w6d06h\",\n \"peerUptimeMsec\":1749628000,\n \"peerUptimeEstablishedEpoch\":1660028234,\n \"pfxRcd\":3,\n \"pfxSnt\":1,\n \"state\":\"Established\",\n \"connectionsEstablished\":9,\n \"connectionsDropped\":8,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.138\":{\n \"remoteAs\":64817,\n \"version\":4,\n \"msgRcvd\":10330314,\n \"msgSent\":9042215,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"02w0d00h\",\n \"peerUptimeMsec\":1210740000,\n \"peerUptimeEstablishedEpoch\":1660567122,\n \"pfxRcd\":8,\n \"pfxSnt\":1,\n \"state\":\"Established\",\n \"connectionsEstablished\":43,\n \"connectionsDropped\":42,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.146\":{\n \"remoteAs\":64818,\n \"version\":4,\n \"msgRcvd\":3247973,\n \"msgSent\":3014469,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"3d15h44m\",\n \"peerUptimeMsec\":315855000,\n \"peerUptimeEstablishedEpoch\":1661462007,\n \"pfxRcd\":14,\n \"pfxSnt\":1,\n \"state\":\"Established\",\n \"connectionsEstablished\":5,\n \"connectionsDropped\":4,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.154\":{\n \"remoteAs\":64819,\n \"version\":4,\n \"msgRcvd\":0,\n \"msgSent\":0,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"never\",\n \"peerUptimeMsec\":0,\n \"pfxRcd\":0,\n \"state\":\"Idle (Admin)\",\n \"connectionsEstablished\":0,\n \"connectionsDropped\":0,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.162\":{\n \"remoteAs\":64820,\n \"version\":4,\n \"msgRcvd\":0,\n \"msgSent\":0,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"never\",\n \"peerUptimeMsec\":0,\n \"pfxRcd\":0,\n \"state\":\"Idle (Admin)\",\n \"connectionsEstablished\":0,\n \"connectionsDropped\":0,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.170\":{\n \"remoteAs\":64821,\n \"version\":4,\n \"msgRcvd\":0,\n \"msgSent\":0,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"never\",\n \"peerUptimeMsec\":0,\n \"pfxRcd\":0,\n \"state\":\"Idle (Admin)\",\n \"connectionsEstablished\":0,\n \"connectionsDropped\":0,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.178\":{\n \"remoteAs\":64822,\n \"version\":4,\n \"msgRcvd\":3444111,\n \"msgSent\":3014256,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"02w0d00h\",\n \"peerUptimeMsec\":1210740000,\n \"peerUptimeEstablishedEpoch\":1660567122,\n \"pfxRcd\":2,\n \"pfxSnt\":1,\n \"state\":\"Established\",\n \"connectionsEstablished\":39,\n \"connectionsDropped\":38,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.186\":{\n \"remoteAs\":64837,\n \"version\":4,\n \"msgRcvd\":10332039,\n \"msgSent\":9043230,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"02w4d22h\",\n \"peerUptimeMsec\":1636077000,\n \"peerUptimeEstablishedEpoch\":1660141785,\n \"pfxRcd\":2,\n \"pfxSnt\":1,\n \"state\":\"Established\",\n \"connectionsEstablished\":29,\n \"connectionsDropped\":28,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.194\":{\n \"remoteAs\":64802,\n \"version\":4,\n \"msgRcvd\":0,\n \"msgSent\":0,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"never\",\n \"peerUptimeMsec\":0,\n \"pfxRcd\":0,\n \"state\":\"Idle (Admin)\",\n \"connectionsEstablished\":0,\n \"connectionsDropped\":0,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.202\":{\n \"remoteAs\":64804,\n \"version\":4,\n \"msgRcvd\":3390967,\n \"msgSent\":3014463,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"5d00h53m\",\n \"peerUptimeMsec\":435197000,\n \"peerUptimeEstablishedEpoch\":1661342665,\n \"pfxRcd\":2,\n \"pfxSnt\":1,\n \"state\":\"Established\",\n \"connectionsEstablished\":5,\n \"connectionsDropped\":4,\n \"idType\":\"ipv4\"\n },\n \"10.189.100.218\":{\n \"remoteAs\":65041,\n \"version\":4,\n \"msgRcvd\":1973897,\n \"msgSent\":1816990,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"09w0d02h\",\n \"peerUptimeMsec\":5450717000,\n \"peerUptimeEstablishedEpoch\":1656327145,\n \"pfxRcd\":113,\n \"pfxSnt\":1,\n \"state\":\"Established\",\n \"connectionsEstablished\":1,\n \"connectionsDropped\":0,\n \"idType\":\"ipv4\"\n },\n \"swp48.1999\":{\n \"hostname\":\"DC-IX-CORESW01\",\n \"remoteAs\":65264,\n \"version\":4,\n \"msgRcvd\":3038670,\n \"msgSent\":3051910,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"01w4d15h\",\n \"peerUptimeMsec\":1007042000,\n \"peerUptimeEstablishedEpoch\":1660770820,\n \"pfxRcd\":197,\n \"pfxSnt\":273,\n \"state\":\"Established\",\n \"connectionsEstablished\":2,\n \"connectionsDropped\":1,\n \"idType\":\"interface\"\n },\n \"swp53.1999\":{\n \"hostname\":\"DC-LCL-CORESW01\",\n \"remoteAs\":65266,\n \"version\":4,\n \"msgRcvd\":3054316,\n \"msgSent\":3052182,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"04w0d03h\",\n \"peerUptimeMsec\":2432273000,\n \"peerUptimeEstablishedEpoch\":1659345589,\n \"pfxRcd\":51,\n \"pfxSnt\":273,\n \"state\":\"Established\",\n \"connectionsEstablished\":3,\n \"connectionsDropped\":2,\n \"idType\":\"interface\"\n },\n \"swp54.1999\":{\n \"hostname\":\"DC-LCL-CORESW01\",\n \"remoteAs\":65266,\n \"version\":4,\n \"msgRcvd\":3054356,\n \"msgSent\":3052187,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"04w0d03h\",\n \"peerUptimeMsec\":2432274000,\n \"peerUptimeEstablishedEpoch\":1659345588,\n \"pfxRcd\":51,\n \"pfxSnt\":273,\n \"state\":\"Established\",\n \"connectionsEstablished\":3,\n \"connectionsDropped\":2,\n \"idType\":\"interface\"\n },\n \"swp56.1999\":{\n \"hostname\":\"DC-IX-CORESW02\",\n \"remoteAs\":65265,\n \"version\":4,\n \"msgRcvd\":338775,\n \"msgSent\":339646,\n \"tableVersion\":0,\n \"outq\":0,\n \"inq\":0,\n \"peerUptime\":\"01w4d16h\",\n \"peerUptimeMsec\":1008054000,\n \"peerUptimeEstablishedEpoch\":1660769808,\n \"pfxRcd\":219,\n \"pfxSnt\":273,\n \"state\":\"Established\",\n \"connectionsEstablished\":1,\n \"connectionsDropped\":0,\n \"idType\":\"interface\"\n }\n },\n \"failedPeers\":12,\n \"totalPeers\":34,\n \"dynamicPeers\":0,\n \"bestPath\":{\n \"multiPathRelax\":\"false\"\n }\n}\n}\n"

frr_exporter service file:

cat /etc/systemd/system/[email protected] 
[Unit]
Description=Prometheus FRR Exporter
After=network-online.target

[Service]
Type=simple
User=root
Group=root
#ExecStart=/usr/local/bin/frr_exporter
ExecStart=/usr/local/bin/frr_exporter --frr.socket.dir-path="/var/run/frr" --no-collector.ospf --no-collector.bfd --collector.bgp6 --collector.bgpl2vpn --collector.bgp.peer-descriptions --collector.bgp.peer-descriptions.plain-text
SyslogIdentifier=frr_exporter
Restart=always
RestartSec=1
StartLimitInterval=0

[Install]
WantedBy=multi-user.target

FRR Version (cumulus linux 4.4.4)

FRRouting 7.5+cl4.4.0u4 (DC-LCL-CORESW02).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
configured with:
    '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--enable-exampledir=/usr/share/doc/frr/examples/' '--localstatedir=/var/run/frr' '--sbindir=/usr/lib/frr' '--sysconfdir=/etc/frr' '--with-vtysh-pager=/usr/bin/pager' '--libdir=/usr/lib/x86_64-linux-gnu/frr' '--with-moduledir=/usr/lib/x86_64-linux-gnu/frr/modules' '--disable-dependency-tracking' '--disable-dev-build' '--enable-systemd=yes' '--enable-rpki' '--with-libpam' '--enable-doc' '--enable-doc-html' '--enable-snmp' '--enable-fpm' '--disable-zeromq' '--enable-ospfapi' '--disable-bgp-vnc' '--enable-multipath=128' '--enable-user=frr' '--enable-group=frr' '--enable-vty-group=frrvty' '--enable-configfile-mask=0640' '--enable-logfile-mask=0640' '--disable-address-sanitizer' '--enable-protobuf' '--enable-cumulus=yes' '--enable-csmgr=yes' '--enable-datacenter=yes' '--enable-bfdd=no' '--enable-sharpd=yes' '--enable-grpc=yes' 'build_alias=x86_64-linux-gnu' 'PYTHON=python3'

For collectors that are enabled by default, the option to disable them is not listed in the help text.

For users who are not familiar with kingpin it might be hard for them to figure out the correct option.

I think this is related to alecthomas/kingpin#243

I'm running frr_exporter 0.2.11 on Cumulus Linux 4.2.0.

This is the command to run the exporter:

frr_exporter --collector.bgp6 --collector.bgpl2vpn --no-collector.ospf --web.listen-address=:9199

On every poll I'm seeing this error in the logs:

ERRO[0003] collector "bgpl2vpn" scrape failed: cannot unmarshal outputs of 'show evpn vni json': json: cannot unmarshal string into Go struct field vxLanStats.NumRemoteVteps of type float64  source="collector.go:138"

And the scrape for bgpl2vpn fails:

frr_collector_up{collector="bgpl2vpn"} 0
frr_scrape_errors_total{collector="bgpl2vpn"} 24255

If I run the show command by hand I get this output:

myswitch# show evpn vni json
{
  "101104":{
    "vni":101104,
    "type":"L2",
    "vxlanIf":"vxlan1104",
    "numMacs":7,
    "numArpNd":0,
    "numRemoteVteps":2,
    "tenantVrf":"default",
    "remoteVteps":[
      "10.99.1.224",
      "10.99.1.121"
    ]
  },
  "101195":{
    "vni":101195,
    "type":"L2",
    "vxlanIf":"vxlan1195",
    "numMacs":3,
    "numArpNd":0,
    "numRemoteVteps":1,
    "tenantVrf":"default",
    "remoteVteps":[
      "10.99.1.224"
    ]
  },
  "100042":{
    "vni":100042,
    "type":"L2",
    "vxlanIf":"vxlan42",
    "numMacs":4,
    "numArpNd":0,
    "numRemoteVteps":2,
    "tenantVrf":"default",
    "remoteVteps":[
      "10.99.1.224",
      "10.99.1.121"
    ]
  },
  "101108":{
    "vni":101108,
    "type":"L2",
    "vxlanIf":"vxlan1108",
    "numMacs":0,
    "numArpNd":0,
    "numRemoteVteps":2,
    "tenantVrf":"default",
    "remoteVteps":[
      "10.99.1.224",
      "10.99.1.121"
    ]
  },
  "101103":{
    "vni":101103,
    "type":"L2",
    "vxlanIf":"vxlan1103",
    "numMacs":15,
    "numArpNd":0,
    "numRemoteVteps":2,
    "tenantVrf":"default",
    "remoteVteps":[
      "10.99.1.224",
      "10.99.1.121"
    ]
  },
  "100041":{
    "vni":100041,
    "type":"L2",
    "vxlanIf":"vxlan41",
    "numMacs":6,
    "numArpNd":0,
    "numRemoteVteps":2,
    "tenantVrf":"default",
    "remoteVteps":[
      "10.99.1.224",
      "10.99.1.121"
    ]
  },
  "101115":{
    "vni":101115,
    "type":"L2",
    "vxlanIf":"vxlan1115",
    "numMacs":12,
    "numArpNd":0,
    "numRemoteVteps":2,
    "tenantVrf":"default",
    "remoteVteps":[
      "10.99.1.224",
      "10.99.1.121"
    ]
  },
  "101109":{
    "vni":101109,
    "type":"L2",
    "vxlanIf":"vxlan1109",
    "numMacs":0,
    "numArpNd":0,
    "numRemoteVteps":2,
    "tenantVrf":"default",
    "remoteVteps":[
      "10.99.1.224",
      "10.99.1.121"
    ]
  },
  "101106":{
    "vni":101106,
    "type":"L2",
    "vxlanIf":"vxlan1106",
    "numMacs":12,
    "numArpNd":0,
    "numRemoteVteps":2,
    "tenantVrf":"default",
    "remoteVteps":[
      "10.99.1.224",
      "10.99.1.121"
    ]
  },
  "101100":{
    "vni":101100,
    "type":"L2",
    "vxlanIf":"vxlan1100",
    "numMacs":11,
    "numArpNd":0,
    "numRemoteVteps":2,
    "tenantVrf":"default",
    "remoteVteps":[
      "10.99.1.224",
      "10.99.1.121"
    ]
  },
  "100049":{
    "vni":100049,
    "type":"L2",
    "vxlanIf":"vxlan49",
    "numMacs":0,
    "numArpNd":0,
    "numRemoteVteps":2,
    "tenantVrf":"default",
    "remoteVteps":[
      "10.99.1.224",
      "10.99.1.121"
    ]
  },
  "100045":{
    "vni":100045,
    "type":"L2",
    "vxlanIf":"vxlan45",
    "numMacs":0,
    "numArpNd":0,
    "numRemoteVteps":2,
    "tenantVrf":"default",
    "remoteVteps":[
      "10.99.1.224",
      "10.99.1.121"
    ]
  },
  "104005":{
    "vni":104005,
    "vxlanIf":"vxlan4005",
    "numMacs":2,
    "numArpNd":3,
    "numRemoteVteps":"n\/a",
    "type":"L3",
    "tenantVrf":"fwlan-2"
  },
  "104004":{
    "vni":104004,
    "vxlanIf":"vxlan4004",
    "numMacs":1,
    "numArpNd":1,
    "numRemoteVteps":"n\/a",
    "type":"L3",
    "tenantVrf":"fwlan-1"
  },
  "104001":{
    "vni":104001,
    "vxlanIf":"vxlan4001",
    "numMacs":4,
    "numArpNd":9,
    "numRemoteVteps":"n\/a",
    "type":"L3",
    "tenantVrf":"internet"
  },
  "104002":{
    "vni":104002,
    "vxlanIf":"vxlan4002",
    "numMacs":1,
    "numArpNd":2,
    "numRemoteVteps":"n\/a",
    "type":"L3",
    "tenantVrf":"internet-2"
  }
}

I suspect the n/a values are problematic.

Hi Tynany,

I found the exporter is still try to get bgp information when I disabled bgp collectors.

It leaves lots of spam in the frr log as the following.
ERRO[0013] collector "bgp6" scrape failed: cannot unmarshal bgp summary json: unexpected end of JSON input source="collector.go:132"
ERRO[0013] collector "bgp" scrape failed: cannot unmarshal bgp summary json: unexpected end of JSON input source="collector.go:132

Could you possible fix it?

Thanks a lot!
Shujie

I think if an OSPF interface is configured as passive, frr_exporter should not report neighbors and adjacencies metrics for that interface.

A passive interface means OSPF protocoll will not run on that interface, but the router will still generate network LSAs for address configured on interface.

If an interface is configured as passive it will have the key "timerPassiveIface":true:

    "peerlink.4094":{
      "ifUp":true,
      "ifIndex":62,
      "mtuBytes":9000,
      "bandwidthMbit":2000,
      "ifFlags":"<UP,BROADCAST,RUNNING,MULTICAST>",
      "ospfEnabled":true,
      "ipAddress":"169.254.1.1",
      "ipAddressPrefixlen":30,
      "ospfIfType":"Broadcast",
      "localIfUsed":"169.254.1.3",
      "area":"0.0.0.75 [Stub]",
      "routerId":"10.200.1.222",
      "networkType":"BROADCAST",
      "cost":50,
      "transmitDelaySecs":1,
      "state":"DR",
      "priority":1,
      "timerMsecs":10000,
      "timerDeadSecs":40,
      "timerWaitSecs":40,
      "timerRetransmitSecs":5,
      "timerPassiveIface":true,
      "nbrCount":0,
      "nbrAdjacentCount":0
    }

If an interface is not passive, that key does not exist:

    "peerlink.4094":{
      "ifUp":true,
      "ifIndex":62,
      "mtuBytes":9000,
      "bandwidthMbit":2000,
      "ifFlags":"<UP,BROADCAST,RUNNING,MULTICAST>",
      "ospfEnabled":true,
      "ipAddress":"169.254.1.1",
      "ipAddressPrefixlen":30,
      "ospfIfType":"Broadcast",
      "localIfUsed":"169.254.1.3",
      "area":"0.0.0.75 [Stub]",
      "routerId":"88.200.1.222",
      "networkType":"BROADCAST",
      "cost":50,
      "transmitDelaySecs":1,
      "state":"DR",
      "priority":1,
      "mcastMemberOspfAllRouters":true,
      "mcastMemberOspfDesignatedRouters":true,
      "timerMsecs":10000,
      "timerDeadSecs":40,
      "timerWaitSecs":40,
      "timerRetransmitSecs":5,
      "timerHelloInMsecs":6182,
      "nbrCount":0,
      "nbrAdjacentCount":0
    }

As it stands now, in both cases, frr_exporter generates metrics like:

frr_ospf_neighbor_adjacencies{area="0.0.0.75 [Stub]",iface="peerlink.4094",vrf="default"} 0
frr_ospf_neighbors{area="0.0.0.75 [Stub]",iface="peerlink.4094",vrf="default"} 0

This makes very difficult to properly alert on an OSPF interface that lost its neighbor, for example.

Current:

frr_bgp_peer_state{afi="ipv4", ..., vrf="default"}

Suggested:

frr_bgp_peer_state{afi="ipv4", ..., vrf="default", identity="SomeCoolNewNode"}

Having and identity field will help identifying dynamic components in a DMVPN with hundreds of nodes on a grafana dashboard.

And example frr command which links BGP IP, NMBA, Claimed NMBA, and Identity
show ip nhrp cache

Hi,

We are planning to use Frr and run it inside a container. Metrics are crucial for us. How can I access the metrics when frr is running in a container and this exporter also.

After an upgrade to 0.2.13 FRR exporter is crashing when BGP peer descriptions collector is enabled:

# frr_exporter --collector.bgp.peer-descriptions --collector.bgp.peer-descriptions.plain-text --no-collector.bfd
INFO[0000] Starting frr_exporter (version=0.2.13, branch=HEAD, revision=c83b7d0c4750ad9f0c02e2d85c2d5480361d029d) on :9342  source="frr_exporter.go:118"
panic: inconsistent label cardinality: expected 7 label values but got 6 in []string{"default", "ipv4", "unicast", "64999", "10.XXX.YYY.9", "64999"}

goroutine 20 [running]:
github.com/prometheus/client_golang/prometheus.MustNewConstMetric(...)
	/go/pkg/mod/github.com/prometheus/[email protected]/prometheus/value.go:107
github.com/tynany/frr_exporter/collector.newGauge(0xc0000595c0, 0xc00010bc00, 0x4000000000000000, 0xc0001c0120, 0x6, 0x6)
	/app/collector/collector.go:155 +0xdc
github.com/tynany/frr_exporter/collector.processBGPSummary(0xc0000595c0, 0xc0001b4000, 0x4d2, 0xe00, 0xa24ee2, 0x4, 0xa25da6, 0x7, 0x0, 0xc000041da0)
	/app/collector/bgp.go:366 +0x1460
github.com/tynany/frr_exporter/collector.collectBGP(0xc0000595c0, 0xa24ee2, 0x4)
	/app/collector/bgp.go:297 +0x3f9
github.com/tynany/frr_exporter/collector.(*BGPCollector).Collect(0xedff00, 0xc0000595c0)
	/app/collector/bgp.go:71 +0x40
github.com/tynany/frr_exporter/collector.runCollector(0xc0000595c0, 0xc000012500, 0xc000082a00, 0xc0000278c0)
	/app/collector/collector.go:129 +0xc7
created by github.com/tynany/frr_exporter/collector.(*Exporters).Collect
	/app/collector/collector.go:98 +0x1db

It is working properly if I downgrade to 0.2.12.

# cat /etc/frr/frr.conf | grep description
 neighbor 10.XXX.YYY.9 description fw1
 neighbor 10.XXX.YYY.10 description fw2

Hi, I'm interested in adding AS number as a label in bgp metrics.
It would be more convenient for organizations that has hundreds of BGP sessions.

I already tested to adding few lines into the code and now it shows asn correct.
frr_bgp_message_input_total{address_family="ipv4unicast",asn="****",peer="33.34.45.67",vrf="default"} 23

Another way is that makiing AS number a metrics since it's integer.

Which way do you think is more effective?

If it's ok to add this feature, I can make a pull request for it.

The default bgp/bgp6* collectors are hardcoded to the SAFI "unicast". I need information about the SAFI "vpn". My preference would be to collect all information for sessions with all SAFIs and expose the SAFI as a label. However, it looks like the existing approach (looking at l2vpn/evpn) is to add a separate collector that is also hardcoded.

My only potential concern with the former approach is that someone blindly upgrading to the latest version may have some SAFI vpn sessions currently not being collected, and could be surprised that they suddenly appear. But that seems like a minor issue that's easily solved.

The reason I'm making this issue is because I plan to implement this and contribute it as a PR, and I don't want that PR to get rejected 😅 So let me know what you think.

*"bgp6" is a weird/confusing way of saying "BGP sessions with AFI IPv6", btw, since the actual protocol name is BGP4 regardless of the transport protocol or AFI used. IMO this would at least benefit from some more descriptive documentation.

Release 0.2.15 dies when scraping metrics:

$ frr_exporter-0.2.15.linux-amd64/frr_exporter --no-collector.ospf
INFO[0000] Starting frr_exporter (version=, branch=, revision=) on :9342  source="frr_exporter.go:126"
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x8f13ab]

goroutine 21 [running]:
github.com/tynany/frr_exporter/collector.execVtyshCommand(0xc000050d00, 0x2, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0)
        /root/frr_exporter/collector/command.go:26 +0x11b
github.com/tynany/frr_exporter/collector.getBGPSummary(0xa2d104, 0x4, 0xa2dfc8, 0x7, 0x0, 0x0, 0x0, 0x0, 0x0)
        /root/frr_exporter/collector/bgp.go:314 +0x12b
github.com/tynany/frr_exporter/collector.collectBGP(0xc000065800, 0xa2d104, 0x4)
        /root/frr_exporter/collector/bgp.go:281 +0x86
github.com/tynany/frr_exporter/collector.(*BGPCollector).Collect(0xeee1a0, 0xc000065800)
        /root/frr_exporter/collector/bgp.go:71 +0x40
github.com/tynany/frr_exporter/collector.runCollector(0xc000065800, 0xc000014500, 0xc00008ea00, 0xc0000279d0)
        /root/frr_exporter/collector/collector.go:140 +0xc7
created by github.com/tynany/frr_exporter/collector.(*Exporters).Collect
        /root/frr_exporter/collector/collector.go:109 +0x1db

0.2.14 does not, but complains about BFD:

frr_exporter-0.2.14.linux-amd64/frr_exporter --no-collector.ospf
INFO[0000] Starting frr_exporter (version=0.2.14, branch=HEAD, revision=33efb682dcedee2b8e22d9b5b43c5335a770831b) on :9342  source="frr_exporter.go:121"
ERRO[0002] collector "bfd" scrape failed: cannot unmarshal bfd peers json: unexpected end of JSON input  source="collector.go:144"

On latest main we are seeing an index out of range error. This is happening where we have 32 peers and the output exceeds the buffer size of 4096.

Command buffer handling was recently changed in #81. The buf[n] check overflows when the command returns more than 4096 bytes of data.

kubectl logs frr-switch-1 -c frr-exporter

{"caller":"frr_exporter.go:65","level":"info","msg":"Starting frr_exporter","ts":"2022-09-19T16:02:30.213Z","version":"(version=75d66c9, branch=master, revision=75d66c92eefe96cd3943d5ee2a456b992e022fee)"}
{"build_context":"(go=go1.17.13, user=root@buildkitsandbox, date=20220918-21:59:18)","caller":"frr_exporter.go:66","level":"info","msg":"Build context","ts":"2022-09-19T16:02:30.213Z"}
{"address":":9342","caller":"frr_exporter.go:67","level":"info","msg":"Listening on address","ts":"2022-09-19T16:02:30.213Z"}
{"caller":"tls_config.go:191","http2":false,"level":"info","msg":"TLS is disabled.","ts":"2022-09-19T16:02:30.214Z"}
panic: runtime error: index out of range [4096] with length 4096
goroutine 27 [running]:
github.com/tynany/frr_exporter/internal/frrsockets.executeCmd({0xc0000b82a0, 0x15}, {0xc000029200, 0x2a}, 0x4a817c800)
/go/src/github.com/tynany/frr_exporter/internal/frrsockets/frrsockets.go:73 +0x52f
github.com/tynany/frr_exporter/internal/frrsockets.Connection.ExecBGPCmd({{0x948f51, 0x40a927}, 0x2a}, {0xc000029200, 0x2a})
/go/src/github.com/tynany/frr_exporter/internal/frrsockets/frrsockets.go:21 +0x87
github.com/tynany/frr_exporter/collector.executeBGPCommand({0xc000029200, 0x23})
/go/src/github.com/tynany/frr_exporter/collector/command.go:25 +0x57
github.com/tynany/frr_exporter/collector.collectBGP(0x4665d3, {0x9432e0, 0x4}, {0x9ea380, 0xc000212730}, 0x4b5cb7)
/go/src/github.com/tynany/frr_exporter/collector/bgp.go:161 +0x168
github.com/tynany/frr_exporter/collector.(*bgpCollector).Update(0x0, 0x0)
/go/src/github.com/tynany/frr_exporter/collector/bgp.go:72 +0x32
github.com/tynany/frr_exporter/collector.runCollector(0x0, {0xc00002c69c, 0x4}, {0x9ea560, 0xc000248240}, 0x0, {0x9ea380, 0xc000212460})
/go/src/github.com/tynany/frr_exporter/collector/collector.go:119 +0xdf
created by github.com/tynany/frr_exporter/collector.(*Exporter).Collect
/go/src/github.com/tynany/frr_exporter/collector/collector.go:110 +0x111

I will submit a PR shortly.

Hi @tynany

In the following commit the github.com/prometheus/common/log was removed so updating the dependencies is currently not possible. The logging system needs love :)
prometheus/common@a184d5b

Hi. We are seeing much slower queries than before in the latest version, see comparison below.

version v0.2.4:
`~# time curl localhost:9342/metrics > /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 10850 100 10850 0 0 27473 0 --:--:-- --:--:-- --:--:-- 27538

real 0m0.407s
user 0m0.004s
sys 0m0.008s
`

version v0.1.2:
`~# time curl localhost:9342/metrics > /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 21155 100 21155 0 0 132k 0 --:--:-- --:--:-- --:--:-- 133k

real 0m0.170s
user 0m0.008s
sys 0m0.004s
`

Hi,
It would be nice, if frr_exporter can be able to export advertised-routes as metric from the show ip bgp neighbor x.x.x.x advertised-routes command.
It will be useful for monitoring advertising which may be admin-down or wrongly configured.
What do you think @tynany ?