FRR Routing state is only available via service monitoring prometheus frr-exporter, which is a pull target.
Operators pushing everything else out through Telegraf (InfluxDB / ADX / Loki / Splunk) must run an external Prometheus server and allow inbound access to the router just for routing state. The metrics already exist locally. Telegraf can't currently perform them.
Feature Request
Let Telegraf ingest the local frr_exporter endpoint and emit it through whatever Telegraf outputs are already configured. The exporter still runs; what goes away is the external scrape path and the inbound exposure.
Telegraf 1.28.3-1 as shipped includes inputs.prometheus, so no new package is needed.
Possible CLI options
# existing set service monitoring prometheus frr-exporter listen-address 127.0.0.1 set service monitoring prometheus frr-exporter port 9342 # new set service monitoring telegraf source frr # reuse existing 'source' node # OR set service monitoring telegraf frr-metrics # dedicated node
Here, source frr means either implementing the gating or adding a value that works while the others don't. Hence, the alternative dedicated-node option above.
This should generate:
toml [[inputs.prometheus]] urls = ["http://127.0.0.1:9342/metrics"] metric_version = 2 name_override = "frr"
Some things to consider
- Behavior when frr-exporter isn't configured.
- frr_exporter runs under ip vrf exec when set. Loopback scrape will break if they differ.
- If prometheus-client output is configured, the input metric_version should follow it.