gNMI Streaming Telemetry on Cisco IOS XE

SNMP polling tells you what a device looked like when you asked; streaming telemetry tells you what it is doing now. On IOS XE that means model-driven telemetry - configured subscriptions that push YANG-modelled data to a collector over gRPC, or dynamic gNMI subscriptions created by the collector over HTTP/2. This guide explains the two architectures, gives working configuration for both, covers encoding choices and the periodic-versus-on-change decision, and lists the verification commands that confirm a subscription is live rather than merely configured.

Dial-out: the device pushes

configure terminal
 telemetry ietf subscription 1
  encoding encode-kvgpb
  filter xpath /process-cpu-ios-xe-oper:cpu-usage/cpu-utilization
  stream yang-push
  update-policy periodic 60000
  receiver ip address 10.1.1.3 57500 protocol grpc-tcp
 !

Dial-out subscriptions live in the running configuration, which has two practical consequences: they survive a reload and reconnect automatically after a stateful switchover, and they are tunable by configuration management rather than by an application. The update-policy periodic value is in centiseconds, so 60000 means every ten minutes; the minimum supported interval is one second.

Dial-in: the collector subscribes

gnxi
gnxi server            ! lab only: no TLS
! or secure mode:
gnxi secure-init
gnxi secure-password-auth
service internal
gnxi secure-allow-self-signed-trustpoint

gNMI listens on 9339 by default and supports GET, SET, SUBSCRIBE and Capabilities. A subscription request names a path, a mode and an encoding:

{
  "subscribe": {
    "subscription": [
      { "path": { "elem": [
          { "name": "Cisco-IOS-XE-interfaces-oper:interfaces" },
          { "name": "interface" } ] },
        "mode": "SAMPLE",
        "sampleInterval": "30000000000" }
    ],
    "encoding": "JSON_IETF"
  }
}

sampleInterval is in nanoseconds - 30000000000 is 30 seconds. SAMPLE polls within the device and streams; ON_CHANGE publishes only when the value moves, which is what you want for interface state, transceiver faults and configuration events. Recent IOS XE releases give xpath parity for on-change across NETCONF, gRPC and gNMI; older ones support only a limited on-change model set, so check capability output before designing around it. The device sends a sync_response once the initial dataset has been delivered, which is your signal that subsequent messages are deltas.

Choosing an encoding

• kvGPB - compact and fast to produce on the device; requires a collector that understands key-value protobuf. The usual dial-out choice.
• JSON_IETF - human-readable, aggregates a subtree into a single payload, ideal while you are still building the pipeline.
• PROTO - binary path and value, more granular messages and lower bandwidth. Best when the collector is already strongly typed and you are streaming at scale.

Verification

show telemetry ietf subscription 1
show platform software yang-management process
show telemetry model-driven subscription
show telemetry model-driven stream statistics

pubd is the telemetry publication process: if it is not running, no telemetry leaves the box regardless of configuration. For configured dial-out subscriptions, the stream statistics show the destination connection state, samples sent and bytes sent - a flat sample count with connection down almost always means the collector is unreachable rather than the path being wrong.

Operational guidance

Start with a handful of high-value paths - interface counters, CPU and memory, transceiver diagnostics, BGP peer state - and expand only when the collector can handle the volume. Where a device cannot export directly, or NAT and firewalls block inbound connections, a tunnel-based dial-out model keeps the flexibility of dial-in with the outbound-only connectivity of dial-out. Pair telemetry with flow data in Cisco Flexible NetFlow configuration, and with device-driven remediation in Cisco IOS XE EEM applets.

原文链接：https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/prog/configuration/1717/b_1717_programmability_cg/model-driven-telemetry.html