Three Techniques That Work
Since standard polling misses micro-bursts by design, you need different instrumentation strategies.
1. Interface Drop Counters (The Cheapest Signal)
Even if you only poll every 60 seconds, the switch hardware maintains a running counter of dropped packets — typically exposed as ifOutDiscards (SNMP OID) or "Output Drops" in CLI output. This counter increments every time the output buffer overflows, regardless of how brief the burst was.
The diagnostic pattern: If average bandwidth utilization is low (say, 15%) but the drop counter is increasing, you have micro-bursts. The only reason a healthy switch drops packets on a functioning link is buffer overflow from momentary congestion. Low average + rising drops = micro-burst signature — this is exactly what checking a Cisco device's interface counters, or a Linux host's ip -s link / /proc/net/dev drop fields, will reveal: a low average bit rate sitting alongside a nonzero and climbing drop count.
2. High-Frequency Streaming Telemetry
Modern switches and routers support gRPC-based Streaming Telemetry (defined in OpenConfig standards). Instead of waiting to be polled, the device pushes metrics at configurable intervals — as frequently as every 100ms or even on threshold-crossing events (e.g., "push data whenever buffer utilization exceeds 70%").
This is a fundamental shift from the pull model (SNMP polling) to a push model. The device becomes an active participant in observability rather than a passive responder. Platforms like Telegraf + InfluxDB or Prometheus with a gNMI exporter can ingest this high-frequency telemetry and store it at sub-second resolution — a Telegraf gNMI input pointed at a switch, subscribed to its interface counters at a 100ms sample interval, is enough to catch bursts that a minute-level poll would completely miss.
3. TCP Retransmission Analysis (Passive NPM)
If you are capturing packet data, TCP retransmissions are a reliable downstream indicator of micro-bursts. When a burst drops packets, the TCP sender doesn't receive acknowledgements (ACKs) for those segments. After a timeout (initially ~200ms, doubling with each retry), it retransmits. A spike in retransmissions at a specific time correlates directly with a burst event — extracting retransmission timestamps from a capture with tshark and finding a cluster of them all within the same 100ms window is the micro-burst signature.
Combining signals: The most reliable micro-burst diagnosis combines all three: rising drop counters (confirms the switch dropped packets), high-frequency telemetry showing a buffer spike (confirms when and how severe), and TCP retransmissions in packet captures (confirms which flows were affected).
A common SRE interview question: "Your monitoring shows 20% average WAN utilization, but users report intermittent packet loss. How do you investigate?" Walk through the three-layer approach: (1) check interface drop counters — if they're rising, you have micro-bursts despite low average utilization; (2) enable high-frequency telemetry or reduce polling interval to catch the spike; (3) correlate with TCP retransmission data from passive captures to identify which applications are affected. This demonstrates you understand why averages are insufficient and how to get sub-second visibility.