Operations, Monitoring, and Troubleshooting
What this domain covers
Operations, Monitoring, and Troubleshooting tests whether you can read the orchestrator's health and flow data, isolate a fault to underlay, overlay, policy, or application, and use diagnostics without guessing.
Core rules
- Health hierarchy: tenant to site to edge to WAN link to tunnel to application flow. Check each layer before changing configuration.
- Metrics: link utilization, latency, jitter, loss, tunnel status, device CPU/memory, and application performance (including MOS for voice). Use flow analytics to confirm which policy matched.
- Events and alarms: distinguish informational events from alarms that indicate service impact. Audit logs show configuration changes and who made them.
- Diagnostics: ping, traceroute, speed test, packet capture, and device logs. Capture on both ends when you suspect asymmetry or NAT.
- Method: define scope (one site, one link, one app, all users), verify orchestrator reachability and edge online state, check underlay and tunnel, then routing, policy match, QoS, and application or DNS.
Worked example
Users at one site report poor voice quality, but the edge is online and both tunnels are up. Flow analytics show voice is using broadband with 8% loss and 90 ms jitter; the SLA threshold is 2% loss, so Dynamic WAN Selection should have moved it to MPLS. The policy is below a broad any workflow that sends all traffic to broadband, so the voice rule never matches. Move the voice workflow above the broad rule, confirm the QoS class is real-time, and verify the MPLS path meets the threshold. Then recheck MOS and loss.
Traps
Stopping at tunnel up; changing several variables at once; ignoring the underlay because the overlay looks healthy; assuming an alarm is the root cause; and forgetting that DNS or application-side latency can look like WAN latency. Also check policy hit counts before rewriting a policy.