La visibilità verso il cloud finisce, di solito, al bordo del proprio perimetro. Superato il primo hop di transito verso Internet o verso un provider IaaS, i contatori interni non vedono più nulla: il traffico attraversa reti di terzi (ISP, peering, backbone cloud) dove non esistono SNMP né NetFlow a disposizione. Cisco ThousandEyes nasce per colmare esattamente questo punto cieco, offrendo visibilità end-to-end sull’esperienza applicativa e sui percorsi di rete che portano ai servizi cloud e SaaS.
Architettura: agenti e test
ThousandEyes è una piattaforma di monitoraggio attivo: genera traffico sintetico da punti di osservazione (agenti) e ne misura il comportamento lungo il cammino.
| Tipo di agente | Dove risiede | Uso tipico |
|---|---|---|
| Cloud Agent | PoP gestiti da ThousandEyes in tutto il mondo | Vista “da Internet” verso servizi pubblici, benchmark esterni |
| Enterprise Agent | Nel proprio data center, filiale, VPC/VNet cloud | Vista dalla prospettiva reale dell’utente/azienda |
| Endpoint Agent | Sui dispositivi degli utenti finali | Esperienza end-user (Wi-Fi, ISP domestico, VPN) |
Un aspetto rilevante per ENCC: gli Enterprise Agent possono girare come applicazione container integrata su piattaforme Cisco IOS-XE (Catalyst 8000, router SD-WAN) tramite application hosting, portando l’agente direttamente sul dispositivo di edge che governa la connettività cloud.
I test definiscono cosa misurare. I più usati:
- Agent-to-Server (network layer): misura loss, latency e jitter verso un target (IP/hostname:porta) e produce la path visualization.
- HTTP Server / Page Load / Transaction (application layer): tempi di risposta, codici di stato, disponibilità di un endpoint web o di un flusso applicativo.
- BGP (routing layer): monitora reachability e variazioni di path a livello di prefissi, utile per intercettare route leak o hijack.
- DNS / Voice: risoluzione dei nomi e qualità RTP.
Path visualization salto-per-salto
Il valore distintivo è la path visualization: ThousandEyes ricostruisce il percorso hop-by-hop (tecnica affine a traceroute, ma con misurazione continua e correlazione temporale) dall’agente fino al target. Ogni nodo mostra latency e loss, e i nodi vengono raggruppati per Autonomous System, così da capire dentro quale rete (proprio ISP, un peering intermedio, il backbone del cloud provider) si genera il problema.
Questo permette di rispondere alla domanda che i tool interni non sanno affrontare: “il degrado è colpa mia, del mio ISP o del provider cloud?”. Se il loss compare solo dopo aver lasciato l’AS dell’ISP, la responsabilità è a monte e l’azione corretta è aprire un ticket con il provider, non riconfigurare i propri router.
Dalle metriche alla qualità percepita
Le tre metriche di rete si traducono direttamente in esperienza utente:
- Latency (RTT): incide su reattività e throughput TCP; alta latenza degrada applicazioni interattive e transazionali.
- Packet loss: il killer principale: causa retrasmissioni TCP e riduce drasticamente il throughput effettivo (una loss anche dell’1-2% può dimezzare le prestazioni).
- Jitter: variabilità del delay, critico per traffico real-time (voce, video); alto jitter significa audio spezzato anche con latenza media accettabile.
Correlando l’HTTP/Transaction test (esperienza applicativa) con l’Agent-to-Server test (salute della rete), si distingue un problema applicativo (server lento, TLS) da un problema di trasporto (loss su un peering).
ThousandEyes vs. SNMP/flow interni
È la distinzione più importante da padroneggiare.
| ThousandEyes (attivo) | SNMP / NetFlow (passivo) | |
|---|---|---|
| Cosa fa | Genera traffico sintetico e misura il percorso | Legge contatori/flussi del traffico reale già esistente |
| Copertura | Anche fuori dal proprio dominio (ISP, cloud) | Solo dispositivi che possiedi/gestisci |
| Prospettiva | Esperienza end-to-end verso il servizio | Utilizzo di interfacce, code, volumi per applicazione |
SNMP e flow restano insostituibili per capacity planning e utilizzo interno, ma si fermano al proprio ultimo router. ThousandEyes non li sostituisce: li completa proprio là dove finisce la visibilità gestita.
Trappole tipiche d’esame
- Scenario: un utente lamenta lentezza verso un SaaS ma i grafici SNMP interni sono tutti verdi → la risposta giusta è ThousandEyes (monitoraggio attivo end-to-end), perché il problema è fuori dal dominio monitorabile via SNMP/flow.
- Scenario: servono metriche di loss, latency e jitter hop-by-hop verso il cloud con identificazione dell’AS responsabile → Agent-to-Server test + path visualization, non un HTTP test (che vede solo il layer applicativo).
- Scenario: bisogna misurare l’esperienza dalla sede aziendale/VPC, non da Internet generico → Enterprise Agent (eventualmente hostato su IOS-XE), non un Cloud Agent.
- Scenario: si vuole rilevare un route leak / hijack o cambi di percorso a livello di prefisso → BGP test, non un test di rete o applicativo.
- Scenario: la domanda contrappone monitoraggio “attivo” e “passivo” → ThousandEyes = attivo/sintetico; SNMP e NetFlow = passivo sul traffico reale interno.