SDWSCS Part 9: ThousandEyes — Monitoring Cloud Services

Everything since Part 6 has moved user traffic onto infrastructure you don’t operate: Umbrella PoPs, Microsoft’s front door, the Internet middle mile between them. When that traffic degrades, show sdwan app-route statistics can only testify about the overlay — BFD measures edge-to-edge, and none of the interesting path is edge-to-edge any more. ThousandEyes is Cisco’s answer: active synthetic monitoring from agents you place, across networks you don’t own.

Agents, and where they run

The unit of ThousandEyes is the agent. Three kinds matter here:

• Cloud agents — ThousandEyes-operated, in hundreds of cities and inside major providers. Zero deployment; they give you the outside-in view.
• Enterprise agents — yours, deployed where your users are. The SD-WAN-relevant fact: Catalyst 8000-series edges host enterprise agents natively in app hosting (IOx) — the same container infrastructure the UTD engine uses, with the same resource arithmetic (DRAM/flash/vCPU set aside, check platform support before promising a site). vManage 20.6+ has a built-in provisioning workflow: paste the account group token, pick the VPN and IP for the agent, and vManage pushes the agent to selected edges as a day-0 operation.
• Endpoint agents — on user laptops; out of scope for the course but the natural extension for the roaming users Part 6 discussed.

Edge# show app-hosting list
App id      State
thousandeyes_enterprise_agent  RUNNING
Edge# show app-hosting detail appid thousandeyes_enterprise_agent

An agent on the branch edge tests from the branch’s true vantage point — through the same DIA breakout, the same SIG tunnel, the same NAT. That’s the whole value: it experiences what the users experience, continuously, without a laptop in the loop.

Tests, and what each one proves

Test type	What it measures	Use it for
Network (agent-to-server)	Loss, latency, jitter + path visualization hop-by-hop	The transport underneath anything
HTTP server	Availability, response time, phase breakdown (DNS/TCP/TLS/receive)	“Is the service up and where is the time going”
Page load / transaction	Full browser render, scripted user journeys	The apps where login flow matters
Agent-to-agent	Both directions between two of your agents	Branch↔DC, branch↔branch underlay truth
DNS/BGP tests	Resolution correctness; route visibility & hijack/leak detection	The failure modes everyone forgets

The path visualization is the feature that changes conversations: a hop-by-hop map, per test round, from the branch agent through the ISP, the middle mile, into Microsoft’s or Umbrella’s edge — with the lossy hop highlighted. “Teams is slow” becomes “loss begins at the ISP’s peering with provider X, here’s the graph”, which is the difference between an argument with a carrier and a ticket they act on.

The M365 lab, condensed

The syllabus builds Microsoft 365 monitoring specifically, and the built-in M365 test templates make it mostly assembly:

1. Provision enterprise agents on the edges of your three most M365-dependent site profiles (not every site — license units are consumed per test frequency and count; spend them where the traffic profile differs).
2. From the template, instantiate tests against Teams, SharePoint/OneDrive, Exchange Online, and the Entra ID login endpoint — HTTP tests for the service front doors, network tests underneath them for the path view.
3. Set alert rules on deviation (dynamic baselines beat static thresholds for SaaS — Microsoft’s own edge shifts latency by design).
4. Wire alerts into whatever is actually watched; an unwatched synthetic is a synthetic wasted.

The payoff pattern to internalise: HTTP test green + network test degraded = path problem (yours/ISP’s/middle mile — read the path viz). Both degraded at multiple sites simultaneously = service-side (check Microsoft’s health dashboard, stand down the network bridge). One site degraded, others fine = that site’s breakout, SIG tunnel, or local loop. That triage tree, run against evidence instead of vibes, is the operational point of the whole module.

Where it plugs into the fabric story

Two integrations close the loop. The vManage integration surfaces ThousandEyes test results inside vManage’s monitoring pages, so the NOC sees overlay health and application-path health in one place. And the agent placement question interacts with Part 10: Cloud OnRamp for SaaS makes its own path decisions from its own probes — ThousandEyes doesn’t drive that steering, but it tells you whether OnRamp’s chosen path is actually delivering, and it’s the tool you’ll use to sanity-check OnRamp’s vQoE scores when a user disputes them.

Next up, Part 10: Cloud OnRamp for SaaS itself — vQoE scoring, DIA versus gateway exits, the Microsoft telemetry integration, and making the fabric choose the best door to Office.