Telemetry, Monitoring, and Event-Driven Automation
Modern operations move from polling to streaming and from reactive to event-driven. Know streaming telemetry: the device pushes data continuously (vs. SNMP polling), typically using gNMI/gRPC or Junos telemetry with sensors, subscriptions, and a collector. Understand the advantages - higher frequency, lower overhead, near-real-time - and the tradeoffs - collector infrastructure, data volume, and timestamp/clock accuracy.
Know the monitoring stack concepts: SNMP (polling, traps) as the legacy model; syslog for events; NETCONF notifications (<notification>) for subscribed events; and gNMI Subscribe (stream/once/poll modes). Understand sensors (what to collect, e.g., interface counters, CPU) and subscriptions (how often and to where).
Event-driven automation means reacting to a trigger (syslog message, telemetry threshold, alarm, webhook) with an automated action (open a ticket, remediate, roll back). Know the pattern: event → detection → decision → action → verification, and the importance of guardrails (rate limiting, approval, rollback) to avoid automation loops or flapping remediation. Traps: confusing polling with streaming; assuming telemetry replaces syslog (they complement); and forgetting that event-driven actions must be idempotent and safe to re-run. Also expect questions on alert fatigue, thresholds vs. anomaly detection, and time synchronization (NTP) for correlating events.
Rule of thumb: poll for slow-changing state, stream for high-frequency metrics, and trigger automation only on well-understood, low-ambiguity events with a defined rollback.
Worked example: A syslog pattern for an interface-down event triggers a playbook that collects diagnostics, opens a ticket, and (if approved) applies a remediation - with a rate limit so a flapping link does not spawn hundreds of runs.