Telemetry

SNMP, gNMI, NETCONF or CLI: choosing how to collect telemetry

No single collection method fits every device. The right choice depends on what the platform supports, what data you need and how much access you are willing to grant.

Network monitoring is only as good as the data behind it. Modern estates mix new platforms with streaming support and older devices that only speak SNMP or the command line. Understanding what each method does well helps you plan coverage honestly.

SNMP

SNMP is nearly universal and well understood. It supports periodic polling of interface counters, CPU, memory and other MIB objects, and traps for event notification. Use SNMPv3 where possible for authentication and encryption. Watch for 32-bit counters that wrap on fast links; 64-bit high-capacity counters are more appropriate for high-speed interfaces. Its weakness is limited structure and modest freshness because data arrives at the polling interval.

gNMI and streaming telemetry

gNMI runs over gRPC and uses YANG-modeled paths. Subscriptions can stream values at a sample interval or on change, which reduces polling load and improves timeliness. Support depends on the vendor, platform and software version, and paths differ between OpenConfig and native models. It needs a properly secured channel and careful subscription design so a large estate does not overwhelm collectors.

NETCONF

NETCONF uses XML over SSH and works with YANG models. Its “get” operations can retrieve operational state, and it also supports configuration transactions with candidate datastores and commits on capable devices. For monitoring, restrict the account to read operations so the transport’s write capability is never used.

Vendor APIs

Some platforms expose JSON APIs over HTTPS that return structured state and are easier to parse than screen output. Their schemas are vendor-specific and change across versions, so treat each as its own integration.

CLI over SSH

The command line works on almost anything, which makes it a valuable fallback. Its cost is fragility: output formats vary by platform and release, so parsers need careful maintenance and testing against real samples. Keep the command set limited to non-configuration “show” commands and enforce that at the account level.

How to choose per device

  • Prefer structured, streaming or model-driven interfaces where a platform and version support them
  • Use SNMP for broad, low-friction baseline visibility
  • Fall back to show-command-only CLI when nothing else is available, and test parsers against real output
  • Match the method to the data: counters, BGP state, LLDP neighbors and hardware health may each come from different sources
  • Record the collection method for each device so operators can judge freshness

Failure modes to plan for

  • Stale data that looks current: show last successful collection time
  • Credentials that work for one command set and not another
  • Version changes that quietly break a parser or a YANG path
  • Polling intervals too slow to catch short flaps
Coverage honesty: a transport being available does not mean every signal on every model has been verified. AssureMesh collects its own telemetry from Cisco IOS-XE, Arista EOS, Juniper Junos, SNMP devices and AWS, Azure and Google Cloud.

Read next: what safe access should mean in practice.

Related guides