By the SNMP Monitoring team · Reviewed July 2026
Every few years something is announced as "the SNMP killer," and the current candidate is streaming telemetry via gNMI. It's a real generational shift — push instead of pull, model-driven instead of OID-based, sub-second instead of minute-level. But the obituaries are premature. gNMI is a young standard with incomplete model coverage, it runs only on newer gear, and it doesn't yet expose everything SNMP can. Meanwhile, SNMP's pull model has properties that genuinely suit monitoring. This page compares them straight, and makes the case for why polling still earns its place.
Parent: comparisons. Related: traps vs polling, monitoring frequency.
SNMP: pull/poll, OID-based
SNMP is pull-based: your manager asks a device for specific OIDs, on your schedule, and the device answers. It's mature, standardised, and supported by essentially every network and hardware device made in the last few decades. Crucially, polling is a good fit for monitoring, not merely a legacy holdover:
- On-demand and deterministic — you query exactly what you want, exactly when you want it.
- Stateless and simple — each poll is independent; a missed poll just retries, with no stream to corrupt or resync.
- Easy to troubleshoot — one request, one response, trivial to reason about and reproduce.
- Resilient — a dropped poll doesn't cascade; the next one simply succeeds.
- Bandwidth-predictable — you know how much traffic N devices at interval T will generate.
- Universal tooling —
snmpwalk,snmpget, and every NMS speak it.
The honest limitation: resolution is bounded by the polling interval. If you poll every 60 seconds, you can't see a 5-second spike. For health and availability, that's usually fine; for high-speed performance telemetry, it isn't.
snmpwalk -v2c -c public 10.0.0.20 sysUpTime.0
SNMPv2-MIB::sysUpTime.0 = Timeticks: (45678901) 5 days, 6:53:09.01
gNMI/streaming: push, model-driven
gNMI (gRPC Network Management Interface) flips the model. Instead of you polling, the device streams data to a collector via subscriptions over gRPC, pushing updates as values change or at high frequency. Its data is model-driven — described by YANG models, often the vendor-neutral OpenConfig set — rather than a flat OID tree. The payoff is high resolution: sub-second telemetry without the overhead of hammering a device with polls, because the device sends only what changed. For large, fast-moving networks where you need fine-grained performance data, that's a real advantage SNMP's polling can't match.
Comparison table
The two models, side by side:
| Dimension | SNMP | gNMI / streaming |
|---|---|---|
| Model | Pull (poll) | Push (subscribe/stream) |
| Transport | UDP | gRPC (HTTP/2) |
| Data model | MIB / OID | YANG / OpenConfig |
| Resolution | Polling-interval limited | Sub-second |
| Device support | Vast installed base | Newer gear only |
| Maturity | Decades, stable | Young, still evolving |
Neither column is strictly "better" — they trade resolution and modernity against support breadth and maturity. The transport row hints at an operational difference that's easy to overlook: gNMI's use of gRPC over HTTP/2 means it needs a TCP session, certificates, and a more involved setup on both device and collector, whereas an SNMP poll is a single stateless UDP exchange with nothing to keep alive. That makes gNMI more capable but also heavier to stand up and operate, which is part of why it lands first on the high-value modern gear where the resolution gain justifies the effort, and why SNMP remains the path of least resistance for broad, simple health coverage.
Resolution & scale
This is where streaming genuinely wins. Because the device pushes on change (or at high frequency), gNMI can deliver sub-second visibility and scale to very large, fast-moving networks without the poll-storm problem — you're not sending thousands of requests every interval, you're receiving a continuous stream. SNMP, by contrast, ties resolution to how often you poll, and polling every device every second doesn't scale gracefully. For capacity planning, microbursts, and high-cardinality performance analysis on modern platforms, streaming is the right tool. For "is this device up and healthy," the difference rarely matters.
Support reality: gNMI's coverage gap
Here's the part the hype skips. gNMI is still a young, evolving standard, and its YANG/OpenConfig model coverage is incomplete — so not everything available over SNMP is yet exposed via gNMI. In practice, SNMP still reaches data and devices that streaming can't:
- Legacy and mixed-vendor gear — anything without a gNMI/gRPC stack, which is most of the installed base.
- Non-network devices — UPSes, PDUs, printers, environmental sensors that ship SNMP, not gNMI.
- Metrics with no model coverage yet — objects present in a MIB but not in the device's YANG models.
- Simple health checks — where SNMP's lightweight universality beats standing up a streaming pipeline.
So gNMI is promising but not a complete replacement today. Declaring SNMP "dead" ignores the enormous set of things it still monitors that gNMI simply doesn't cover.
Migration & coexistence
The pragmatic path is both. Run gNMI streaming where you have modern gear and need high-resolution performance telemetry, and keep SNMP for the installed base, non-network devices, and health monitoring. Many networks operate them side by side for years — streaming the new fabric, polling everything else — and there's no urgency to rip out SNMP, because it still covers ground gNMI can't. Treat the shift as additive, not a forced cutover.
Frequently asked questions
Is gNMI replacing SNMP?
Gradually and partially, on newer gear — not wholesale. gNMI offers push-based, high-resolution telemetry that's superior for performance monitoring on modern platforms, but it's a young standard with incomplete model coverage and no presence on the vast legacy and non-network installed base. SNMP remains essential for everything gNMI doesn't yet reach, so most networks run both.
What is streaming telemetry?
Streaming telemetry is a push model where a device continuously sends data to a collector — via subscriptions over gRPC in gNMI's case — rather than waiting to be polled. Data is described by YANG models (often OpenConfig) and pushed as it changes or at high frequency, enabling sub-second resolution without the overhead of constant polling. It suits large, fast-moving networks.
Should I use SNMP or gNMI?
Choose by device support and resolution needs. For modern gear where you need sub-second performance telemetry, gNMI wins. For the broad installed base, non-network devices, mixed vendors, and routine health monitoring, SNMP wins — and its polling model is deterministic, stateless, and simple. Many environments use gNMI on new fabric and SNMP everywhere else.
Does gNMI support everything SNMP does?
No. gNMI is a young, still-evolving standard, and its YANG/OpenConfig model coverage is incomplete, so it doesn't yet expose everything reachable via SNMP. Many metrics, device classes, and legacy or non-network devices remain accessible only through SNMP. That coverage gap is a key reason SNMP stays in use alongside streaming telemetry.
Key takeaways
- gNMI is a generational shift — push/streaming, model-driven — but not an SNMP replacement today.
- SNMP polling is on-demand, deterministic, stateless, simple, resilient, and universally supported.
- SNMP's limit is polling-interval resolution; streaming delivers sub-second data.
- gNMI is young with incomplete model coverage — it doesn't yet expose everything SNMP can.
- SNMP still reaches legacy, mixed-vendor, and non-network devices gNMI can't.
- Run both — streaming for modern high-resolution needs, SNMP for the installed base and health checks.