LibreNMS Streaming Telemetry Export

[tristanbob]

Note: This was originally requested 9 years ago, so I thought it would be best to start a new topic. Streaming telemetry is useful before it can provide very high level of detail (~10 seconds) without a large impact on the network devices. – Tristan

Support IETF Streaming Telemetry and OpenConfig gNMI for performance monitoring

Modern network devices OS versions support other methods than SNMP for performance monitoring like: IETF Streaming Telemetry [1] and OpenConfig gNMI [2]. Both of them use Google Protocol Buffers [3] as container for data models but different transport, device with Streaming Telemetry pushes monitoring statistics to NMS itself without any requests but only using configured RPC on device itself [4] and gNMI uses request-response model there NMS request specific OpenConfig gRPC from device and net…

Feature idea: Streaming Telemetry Export

TL;DR — LibreNMS already knows which devices exist, what they are, and how they’re grouped. This feature would let it publish that as target config for an external streaming-telemetry collector (gNMIc first), the same way we hand device inventory to Oxidized. LibreNMS never touches the telemetry stream itself.

I’ve built a working reference implementation and validated it end to end with gNMIc against a Nokia SR Linux node, with SNMP and gNMI running side by side on the same device. Looking for feedback before proposing it seriously.

The idea

LibreNMS discovery → profile/policy resolution → desired-state API → gNMIc → your TSDB

Today, if you want gNMI streaming telemetry, you have to rebuild LibreNMS’s inventory by hand in gNMIc / Telegraf / OTel / scripts, and keep it in sync. LibreNMS already has the management address, OS, hardware, type, location, groups, and monitoring state. This replaces static target files and cron-driven API scripts with a first-class source of telemetry desired state.

Important: this is not metric storage. No telemetry passes through LibreNMS pollers. LibreNMS publishes target configuration only; the collector connects to devices, holds subscriptions, resolves credentials, and forwards data wherever the operator points it (Prometheus remote-write, VictoriaMetrics, Influx, Kafka, etc.).

Key principles

• LibreNMS exports desired state; it does not run collectors.

• SNMP stays the primary discovery/inventory mechanism.

• Discovery and polling never block on gNMI, collectors, or telemetry backends.

• Exports carry credential references, never device secrets.

• Devices are candidates by default — enabling telemetry is explicit (per device or via device-group policy).

• Internal model is collector-neutral; gNMIc is just the first renderer.

How it works

1. LibreNMS discovers a device over SNMP.

2. Local profile resolution (OS + hardware + version + groups) marks it a telemetry candidate — no network calls.

3. An admin or group policy enables it and assigns platform / subscription / transport / credential / collector-group profiles.

4. LibreNMS exposes the target over an API (plus optional CLI/file export).

5. gNMIc polls the endpoint, resolves credentials locally, and subscribes.

Version-controlled profiles ship in-tree (e.g. a Cisco IOS-XE OpenConfig profile with match rules, default port, recommended subscriptions, expected models), with local overrides. Subscription defaults are conservative: narrow OpenConfig paths, moderate intervals, no root-container subscriptions.

What the export looks like

Collector-neutral canonical API:

GET /api/v0/telemetry/v1/targets

gNMIc-native HTTP loader endpoint:

GET /api/v0/telemetry/v1/export/gnmic?collector_group=campus-main

{
  "core-sw1": {
    "address": "10.10.1.11:9339",
    "subscriptions": ["openconfig-interfaces-30s", "openconfig-system-60s"],
    "tags": ["librenms_device_id=123", "site=main-campus", "role=core"]
  }
}

Credentials are resolved collector-side (env / Vault / K8s secrets / etc.). Collector groups keep every collector from subscribing to every device, and targets stay exported through outages — they’re removed only when telemetry is disabled or the device is decommissioned.

Rough scope for a V1

Feature flag (off by default) · candidate detection + explicit enable · device-group policy · versioned platform/subscription profiles · collector groups + credential references · canonical JSON API · gNMIc endpoint · CLI/file export · revisions/hashes + conditional requests · preview & validation.

Explicitly out of scope: running/restarting collectors, config changes, credentials in responses, arbitrary server-side templates, streaming through pollers, storing telemetry, or picking a metrics backend.

Questions for the community

• Does the Oxidized-style split (LibreNMS = inventory/policy, collector = runtime) feel right here?

• Is gNMIc the right first target, or should another collector come first?

• Where should the enable/disable UI live? device Settings/Edit, alongside Modules and SNMP?

• Interest in in-tree platform/subscription profiles vs. leaving those to operators?

Happy to share the full design doc and the reference implementation if there’s interest.

[tristanbob]

Ok, I’ve got the basics of streaming telemetry working.

LibreNMS discovery (a Nokia SR Linux device)
↓
LibreNMS telemetry config API
↓
gNMIc (polls the LibreNMS API, subscribes to the devices, devices start sending metrics to gnmic)
↓
VictoriaMetrics (accepts remote-write from gNMIc)
↓
Grafana (pulls data from the VictoriaMetrics datasource)

[murrant]

I’m working on a PR for credentials and polling methods. So don’t go too far down this path yet. Definitely a high priority feature

[tristanbob]

Sounds good! My code was mostly for me to learn the terminology, how streaming telemetry works, and to understand the decisions we need to make.

For instance:

1. Dial-in vs Dial out?

Dial-in: Matches SNMP paradigm and can be automated by Librenms

Dial-out: More secure, but requires lots of config on network devices (collector + subscriptions) that user must manage, and we still need SNMP inbound for device discovery and non-streamable metrics

2. How to normalize streaming metrics from different vendors?

We need to store metrics in a TSDB with normalized names so we can reliably use that data to draw graphs. We can do this with a processor on gnmic or a tool like vmagent.

3. Which collectors should we support?

gnmic is the most common and purpose built for this. It can gather target info dynamically via an API polling mechanism that we could provide. However, in order to provide subscription details, we would probably need to write the config for gnmic to use (or give users a way to copy/paste it).

telegraf has a module that could work but is part of a larger tool and doesn’t have the dynamic target from API feature.

[zombah]

pmtelemetryd from pmacct support all various kinds of telemetry inputs, check here