Google PCNE: Osservabilità della rete, affidabilità e risoluzione dei problemi — Guida allo studio

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Fa parte della Google Professional Cloud Network Engineer — Guida allo studio. Esercitati con risposte verificate nel centro esami Google, oppure fai test cronometrati su ExamRoll.io.

Panoramica

L’osservabilità della rete su Google Cloud è la raccolta, la correlazione e l’analisi disciplinata dei segnali di rete che descrivono la raggiungibilità, le prestazioni e la correttezza attraverso VPC, bilanciatori di carico, connessioni ibride e servizi. L’affidabilità deriva dalla progettazione orientata al rilevamento dei guasti e a una risoluzione sicura: strumentare una telemetria di prima classe, validare il control plane prima di intervenire sul data plane, approfondire con l’analisi dei pacchetti solo quando necessario e automatizzare il rollback. Questa sezione spiega come utilizzare gli strumenti e i pattern di Google Cloud per rilevare, diagnosticare e prevenire problemi, minimizzando al contempo il rischio durante le modifiche.

Flow Logs, Logging, Monitoring, Metriche e SLO

I VPC Flow Logs forniscono una telemetria campionata e aggregata a livello della NIC della VM, dopo la valutazione del firewall VPC. Non sono catture complete dei pacchetti e non sostituiscono il logging delle regole firewall per una prova esplicita di autorizzazione/negazione (allow/deny). Controlli chiave:

• Campionamento: 0.0–1.0. Un campionamento più elevato migliora la fedeltà a scapito del volume dei log e dei costi potenziali.
• Intervallo di aggregazione: 5s–30m. Intervalli più brevi riducono il tempo di rilevamento ma aumentano il numero di voci.
• Metadati: includere o escludere i metadati dell’istanza e del VPC. Includerli per analisi più ricche, escluderli per limitare attributi sensibili.

Abilitazione tipica su una subnet:

undefined

Esportazione con i log sink per analisi durevoli e condivisione tra progetti:

• BigQuery per analisi SQL e analisi dei trend a lungo termine.
• Pub/Sub per pipeline quasi in tempo reale verso SIEM/IDS.
• Cloud Storage per l’archiviazione.

• Esempio di sink verso BigQuery:

undefined

Il logging delle regole firewall integra i flow log registrando le decisioni di autorizzazione/negazione (allow/deny) e le regole che hanno prodotto una corrispondenza. Per osservare il traffico bloccato, aggiungere una regola di negazione totale (deny-all) con logging abilitato verso la fine del set di regole:

undefined

Cloud Logging permette query strutturate, la correlazione con i log delle richieste, i log degli health check, i log NAT e i log dei bilanciatori di carico. Creare metriche basate su log per segnali come:

• Aumenti improvvisi di connessioni negate verso i tag dei backend (possibili allowlist configurate in modo errato).
• Volumi elevati di ritrasmissioni SYN verso una porta (possibile saturazione o blackholing).
• Eventi NAT di tipo “nessuna porta disponibile” (esaurimento di Cloud NAT).

Cloud Monitoring aggrega le metriche e fornisce dashboard, avvisi e SLO:

• Metriche da monitorare: tasso di errori 5xx del bilanciatore di carico, latenza dei backend, byte/pacchetti sulla NIC dell’istanza, porte allocate/utilizzate/in overflow di Cloud NAT, stato della sessione BGP di Cloud Router, caduta di pacchetti nel tunnel VPN, utilizzo del link di Interconnect, perdita di pacchetti e latenza.
• Dashboard: costruire dashboard per servizio e per connettività con template condivisi tra i progetti per operazioni coerenti.
• Avvisi: privilegiare gli avvisi basati sui sintomi (tasso di errore, latenza, contatori di pacchetti persi) con feedback rapido, e gli avvisi basati sulla causa (instabilità BGP, link non attivo) con notifica (paging) quando è probabile un impatto sull’utente.
• SLO: definire SLO incentrati sull’utente (ad es. successo e latenza HTTP globali) e avvisi sul burn-rate per identificare consumi rapidi e lenti del budget di errore. Utilizzare i log delle richieste come numeratore/denominatore tramite metriche basate su log per una valutazione precisa degli SLO.

Compromessi e modalità di guasto:

• Un campionamento basso o un’aggregazione lunga nascondono i microburst e i guasti di breve durata.
• I flow log non hanno visibilità sulle cadute di pacchetti che avvengono prima del firewall; affidarsi al logging delle regole firewall per avere prova delle negazioni.
• Un logging eccessivo senza filtri aumenta i costi e può rallentare le indagini; esportare e partizionare i dati in modo intelligente.

Network Intelligence Center e Diagnostica Avanzata

Il Network Intelligence Center (NIC) fornisce una diagnostica proattiva e strutturata:

Test di connettività:

• Valida la raggiungibilità a livello di control plane attraverso route, regole firewall (incluse le policy gerarchiche), service account/tag, bilanciatori di carico, Cloud NAT e connettività ibrida.
• La diagnostica delle route calcola il next hop selezionato e segnala configurazioni errate come route mancanti o percorsi asimmetrici.
• Utilizzare prima e dopo ogni modifica di rete per rilevare un blast radius involontario. Modella il control plane e non garantisce la qualità del data plane; abbinarlo a prove basate su pacchetti/metriche.

Dashboard delle prestazioni:

• Una vista gestita da Google della perdita di pacchetti e della latenza tra le region e verso punti di osservazione su Internet. Utile per rilevare eventi su macro-scala (congestione a livello di region o di percorso) rispetto a problemi locali del servizio.

Topologia di rete:

• Visualizza le connessioni tra progetti, tra VPC e ibride, nonché i volumi di traffico (sfruttando i log) per identificare hot spot, percorsi di peering inattesi e comportamenti transitivi che potrebbero non essere intenzionali.

Firewall Insights:

• Rileva regole oscurate (shadowed), regole di autorizzazione (allow) non utilizzate, sorgenti eccessivamente permissive e regole prive di tag/service account di destinazione. Raccomanda regole più restrittive per ridurre la superficie di attacco senza interrompere i flussi noti.

Network Analyzer:

• Controlli di configurazione statici e dinamici su più progetti per far emergere condizioni quali:
  • Health check bloccati dal firewall (ricordarsi di autorizzare gli intervalli IP di origine degli health check di Google).
  • Backend dei bilanciatori di carico in region errate o con porte nominate mancanti.
  • Subnet con Accesso Privato Google disabilitato che bloccano l’accesso alle API per le istanze senza IP esterni.
  • Route che causano il blackholing di prefissi importanti o routing asimmetrico attraverso VPN/Interconnect.

Guida operativa:

• Integrare i controlli del NIC nel CI/CD per le modifiche di rete ed eseguirli a cadenza programmata. Trattare i risultati come debito di affidabilità e dare priorità alle correzioni con un impatto sulla riduzione del rischio.

Packet Mirroring, Load Balancer e Telemetria Ibrida

Packet Mirroring:

• Esegue il mirroring del traffico delle VM verso un collettore (appliance o IDS gestito) per un’ispezione approfondita. Definisci l’ambito per subnet, tag di rete o service account; limita ai protocolli necessari per controllare i costi.
• Overhead e compromessi: il traffico di egress sottoposto a mirroring comporta dei costi; un mirroring eccessivo può mettere sotto stress i collettori; non eseguire il mirroring indiscriminatamente in produzione. Utilizza sessioni con limiti di tempo e ambito ristretto per la gestione degli incidenti.
• Integrazione con IDS:
  • Cloud IDS fornisce un rilevamento delle minacce gestito e out-of-band che sfrutta Packet Mirroring. Preferiscilo per un’attivazione rapida e una riduzione della manutenzione.
  • Le appliance IDS di terze parti rimangono una soluzione valida laddove sono richieste firme specifiche o ecosistemi di fornitori particolari.

Log dei load balancer e prove degli health check:

• I log delle richieste del load balancer HTTP(S) includono metodo, URL, backend, codice di risposta, latenza e IP del client tramite X-Forwarded-For. Utilizzali per l’analisi del percorso del client, poiché traceroute si ferma ai Google Front End (GFE).
• Abilita il logging sui servizi di backend e configura il campionamento per bilanciare costi e visibilità. Attiva il logging degli health check per visualizzare i risultati dei probe e le cause dei fallimenti.
• Restrizione dell’accesso client: applicala a livello dei backend taggando le istanze e creando regole firewall che consentano solo gli intervalli di IP client approvati e gli IP degli health check di Google. Per la mitigazione delle minacce a livello L7 e un rollout graduale, utilizza le regole di Cloud Armor in modalità di anteprima (preview) prima di renderle effettive.

Telemetria di VPN e Interconnect:

• Metriche di Cloud VPN (HA VPN): byte, pacchetti persi (drop), errori di crittografia, uptime del tunnel e stato della sessione BGP. Imposta alert su perdite di pacchetti, eventi DPD frequenti e instabilità (flap) delle sessioni BGP.
• Scalabilità del throughput: aggiungi tunnel verso IP peer distinti e distribuisci il traffico; monitora il margine di capacità (headroom). Se necessiti di una configurazione attivo/standby tra i Cloud Router, preferisci l’attributo MED on-premise per influenzare la selezione del percorso.
• Metriche di Interconnect: utilizzo per singolo link, errori CRC e disponibilità; monitora un utilizzo sostenuto >60–70% e picchi di errori. Mantieni capacità di riserva e circuiti diversificati. Indaga sugli aumenti di latenza tramite le ritrasmissioni e gli indicatori di accodamento (queueing).
• Segnali di saturazione sugli edge: aumento delle ritrasmissioni TCP, aumento della latenza al 99° percentile senza modifiche al codice, eventi di esaurimento delle porte NAT e alert di occupazione delle code sono avvisi precoci di un impatto imminente.

Metodologia di Troubleshooting, Gestione degli Incidenti e Affidabilità Proattiva

Troubleshooting strutturato dal DNS all’applicazione:

1. Identificare il percorso utente che presenta errori e la finestra temporale; circoscrivere l’analisi alla region e al percorso (pubblico tramite LB, privato tramite VPC o ibrido).
2. DNS:

• Validare la risoluzione con i log di Cloud DNS, l’output di dig e il comportamento delle policy. Verificare conflitti di split-horizon e assicurarsi che le policy di forwarding siano attive.
• Confermare i TTL e le modifiche recenti; le cache obsolete possono simulare delle interruzioni.

3. Load balancer e edge:

• Esaminare i log delle richieste e degli health-check. Correlare i picchi di errori 5xx con lo stato di salute dei backend e gli eventi di deployment. Per il L7, fidarsi dei log delle richieste più che di traceroute.
• Verificare le allowlist dei client e gli IP degli health-check di Google nelle regole firewall quando l’accesso è limitato.

4. Routing e firewall:

• Usare Connectivity Tests per una valutazione deterministica del piano di controllo. Ispezionare le rotte effettive e le policy firewall gerarchiche. Cercare routing asimmetrico e regole mascherate (shadowed).
• Per i pacchetti negati, fare affidamento sul logging delle regole firewall; considerare l’aggiunta di una regola deny-all con logging attivo verso il fondo dello stack di priorità durante le indagini.

5. Egress verso le API di Google:

• Se le istanze non hanno IP esterni, confermare la presenza di Private Google Access e/o Cloud NAT. La mancanza di uno dei due causa fallimenti intermittenti e timeout difficili da interpretare.

6. Ibrido:

• Esaminare le metriche di Cloud Router e VPN/Interconnect. Se BGP è attivo ma le rotte non sono installate, ciò può riflettere preferenze di attributi; verificare MED/local-pref e ASN. Monitorare la perdita di pacchetti e problemi di MTU del percorso.

7. Evidenza a livello di pacchetto:

• Se il piano di controllo sembra corretto ma i sintomi persistono, usare Packet Mirroring in modo mirato per raccogliere PCAP vicino alla VM o al tier interessato; controllare i tempi di SYN/SYN-ACK, le ritrasmissioni e i bit MSS/DF per individuare blackhole di MTU.

Gestione degli incidenti:

• Sicurezza nelle modifiche: implementare le modifiche in modo graduale definendone l’ambito per tag/service account, con precedenza più bassa e regole disabilitate; abilitare il logging e testare con canary. Usare la modalità di anteprima (preview) di Cloud Armor per le modifiche alle policy L7.
• Rollback: predefinire le modifiche inverse, mantenere le configurazioni precedenti nel controllo di versione e usare feature flag di breve durata all’edge dell’applicazione, dove applicabile.
• Analisi post-incidente: costruire una timeline a partire da log e metriche, classificare i fattori contribuenti (es. regola permissiva mascherata da una di deny, esaurimento di NAT), registrare le lacune nel rilevamento e aggiungere misure di salvaguardia: alert, controlli sulle NIC e rafforzamento delle policy.

Pianificazione della capacità e affidabilità proattiva:

• Monitorare gli obiettivi di margine (headroom): 30–50% sui link VPN/Interconnect, utilizzo delle porte NAT al di sotto del 60% sostenuto, CPU e QPS dei backend del LB ben al di sotto dei trigger di autoscaling.
• Creare metriche basate su log per i rischi chiave: picchi di deny, overflow di NAT, conteggio dei flap di BGP, tassi di errori 5xx ed errori di connessione dei backend del LB. Usare alert di burn-rate multi-finestra per cogliere sia gli incidenti rapidi che quelli lenti.
• Monitoraggio sintetico: usare Uptime Checks da più region per gli endpoint pubblici e probe privati da VM di test per i servizi interni.
• Miglioramenti preventivi: affinare le regole firewall usando Firewall Insights, risolvere i risultati di Network Analyzer, abbreviare l’aggregazione dei Flow Log durante gli eventi di picco ed esportare i log in BigQuery per il rilevamento ricorrente di anomalie.

Scenario Pratico di un Problema

Contoso Games gestisce un’API di gioco globale con load balancing HTTP(S) in us-east1 e europe-west1, con una VPN ad alta disponibilità (HA) verso un data center on-premise. Gli utenti in Europa segnalano timeout intermittenti e latenza più alta dopo una recente modifica al firewall. Le istanze non hanno IP esterni e devono raggiungere le API di Google privatamente.

Approccio:

1. Stabilire la finestra temporale e l’impatto sugli SLO

• Motivazione: Individuare la finestra temporale circoscrive le query ai log pertinenti e allinea l’indagine con gli SLO che hanno un impatto sull’utente. Un alert di burn-rate conferma un consumo rapido (burn) dell’SLO in europe-west1.

2. Validare il piano di controllo con Connectivity Tests

• Motivazione: Creare un test dal frontend del load balancer HTTP(S) esterno al backend service di europe-west1 e dalle VM interessate a un VIP di Private Google Access. Il test segnala una policy firewall gerarchica che blocca gli health check verso alcuni backend e la mancanza di Private Google Access per una subnet.

3. Confermare lo stato di salute dell’edge e dei backend tramite i log

• Motivazione: Filtrare i log delle richieste del load balancer per europe-west1 e response_code >= 500 per isolare gli errori dei backend. I log degli health-check mostrano fallimenti dei probe provenienti da indirizzi IP sorgente noti degli health-check di Google. Ciò evidenzia un’instabilità (flapping) dei backend indotta dal firewall piuttosto che regressioni dell’applicazione.

4. Ripristinare lo stato di salute e garantire la sicurezza con modifiche mirate

• Motivazione: Aggiungere una regola di allow mirata ai tag dei backend che permetta i range sorgente degli health-check. Abilitare il logging su questa regola. Poiché l’accesso è limitato a client noti, verificare che la regola firewall di allowlist includa solo gli specifici range IP dei client e i range degli health-check. Mantenere la nuova regola inizialmente disabilitata, poi abilitarla durante un canary a basso traffico per limitare il raggio d’impatto (blast radius).

5. Ristabilire l’egress privato verso le API di Google

• Motivazione: Abilitare Private Google Access sulla subnet interessata in modo che le istanze senza IP esterni raggiungano i servizi Google senza fare hairpinning attraverso la VPN o firewall di terze parti. Questo riduce la latenza e rimuove un collo di bottiglia.

6. Controllare la saturazione e l’MTU dell’ambiente ibrido

• Motivazione: Esaminare le metriche della HA VPN per la perdita di pacchetti e l’utilizzo. Un tunnel mostra un aumento delle perdite. Aumentare la capacità aggiungendo un secondo tunnel verso un diverso IP peer on-premise e distribuire il traffico. Verificare l’MTU effettivo e l’MSS clamp per prevenire blackhole di PMTU sul percorso VPN.

7. Usare la modalità di anteprima di Cloud Armor per sospetti client abusivi

• Motivazione: Dai log delle richieste, un piccolo insieme di IP client causa picchi di traffico poco prima dei fallimenti dei probe. Aggiungere una regola di deny in Cloud Armor in modalità anteprima (preview) per validare che il blocco ridurrebbe il carico sui backend prima di applicarla, evitando un impatto accidentale sugli utenti.

8. Usare Packet Mirroring in modo mirato per confermare il comportamento del piano dati

• Motivazione: Eseguire il mirror del traffico da una singola VM backend non in salute verso Cloud IDS per 15 minuti. Il PCAP mostra l’esaurimento del backlog SYN durante i picchi di traffico provenienti dagli IP abusivi, corroborando l’utilità della policy Cloud Armor e la necessità di rate limiting.

9. Chiudere l’incidente e rafforzare il sistema (harden)

• Motivazione: Dopo aver abilitato la regola di allow per gli health-check, confermato Private Google Access, scalato la capacità della VPN e applicato la regola Cloud Armor verificata, i tassi di errore tornano ai valori di base. Aggiungere dashboard per il tasso di successo degli health-check, l’utilizzo delle porte NAT, le perdite sulla VPN e gli errori 5xx per region. Creare alert basati su log per i deny del firewall verso i tag dei backend e alert di burn-rate sugli SLO. Registrare l’incidente, le cause principali (root cause: modifica del firewall gerarchico; traffico abusivo; saturazione della VPN) e aggiungere i controlli di NIC Analyzer e Firewall Insights alla checklist pre-modifica.

Questa sequenza dimostra un flusso di lavoro sicuro e basato sull’evidenza: confermare il piano di controllo, osservare il piano dati, applicare modifiche minime e reversibili, e infine istituzionalizzare gli insegnamenti appresi con alert e controlli automatizzati.

← GKE · Tutti i domini · Automazione della rete →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Google →