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.
[Example: "802.1q VLAN interfaces are widely used for traffic separation in switched networks and for "router on a stick" scenarios. Most router vendors support them.]
**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.