Google PCNE: Netwerkobservability, Betrouwbaarheid en Probleemoplossing — Studiegids

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

Onderdeel van de Google Professional Cloud Network Engineer — Studiegids. Oefen met geverifieerde antwoorden in het Google-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Netwerkobservability op Google Cloud is het gedisciplineerd verzamelen, correleren en analyseren van netwerksignalen die de bereikbaarheid, prestaties en correctheid beschrijven over VPC’s, load balancers, hybride verbindingen en services. Betrouwbaarheid volgt uit een ontwerp dat gericht is op foutdetectie en veilige herstelmaatregelen: instrumenteer eersteklas telemetrie, valideer het control plane voordat je het data plane aanraakt, zoom alleen in met pakketgegevens wanneer dat nodig is, en automatiseer rollbacks. Dit gedeelte legt uit hoe je Google Cloud-tools en -patronen kunt gebruiken om problemen te detecteren, diagnosticeren en voorkomen, terwijl je de risico’s tijdens wijzigingen minimaliseert.

Flow Logs, Logging, Monitoring, Metrics en SLO’s

VPC Flow Logs leveren gesamplede, geaggregeerde telemetrie op de VM-NIC na evaluatie door de VPC-firewall. Het zijn geen volledige ‘packet captures’ en ze vervangen geen logging van firewallregels voor expliciet bewijs van ‘allow’/‘deny’. Belangrijkste controles:

• Sampling: 0.0–1.0. Een hogere sampling verbetert de nauwkeurigheid ten koste van logvolume en mogelijke kosten.
• Aggregatie-interval: 5s–30m. Kortere intervallen verkorten de detectietijd maar verhogen het aantal entries.
• Metadata: voeg instance- en VPC-metadata toe of sluit deze uit. Voeg toe voor rijkere analyses, sluit uit om gevoelige attributen te beperken.

Typische activering op een subnet:

• gcloud compute networks subnets update SUBNET –region=REGION –enable-flow-logs –logging-flow-sampling=0.5 –logging-aggregation-interval=interval-5-min –logging-metadata=INCLUDE_ALL_METADATA

Exporteren met ’log sinks’ voor duurzame analyse en het delen tussen projecten:

• BigQuery voor SQL-analyses en langetermijntrendanalyse.
• Pub/Sub voor near-real-time pipelines naar SIEM/IDS.
• Cloud Storage voor archivering.
• Voorbeeld van een sink naar BigQuery:
  • gcloud logging sinks create flowlogs-to-bq bigquery.googleapis.com/projects/PROJECT/datasets/DATASET –log-filter=‘resource.type=“gce_subnetwork”’

Logging van firewallregels vult flow logs aan door allow/deny-beslissingen en gematchte regels vast te leggen. Om geblokkeerd verkeer te observeren, voeg je een deny-all-regel met logging toe onderaan je regelset:

• gcloud compute firewall-rules create deny-all –network=VPC –priority=65500 –direction=INGRESS –action=DENY –rules=all –enable-logging

Cloud Logging maakt het mogelijk om gestructureerde query’s uit te voeren en correlaties te leggen met request-logs, health-check-logs, NAT-logs en load-balancer-logs. Maak op logs gebaseerde metrics voor signalen zoals:

• Plotselinge toenames van geweigerde verbindingen met backend-tags (mogelijk verkeerd geconfigureerde allowlists).
• Hoge volumes van SYN-retransmits naar een poort (mogelijke verzadiging of ‘blackholing’).
• NAT-events van het type “no available ports” (uitputting van Cloud NAT).

Cloud Monitoring aggregeert metrics en biedt dashboards, alerts en SLO’s:

• Te monitoren metrics: 5xx-rate van de load balancer, backend-latency, bytes/pakketten van de instance-NIC, toegewezen/gebruikte/overflow-poorten van Cloud NAT, status van de Cloud Router BGP-sessie, packet drops in de VPN-tunnel, gebruik van de Interconnect-link, pakketverlies en latency.
• Dashboards: bouw dashboards per service en per connectiviteitstype met gedeelde templates voor verschillende projecten om een consistente operatie te waarborgen.
• Alerts: geef de voorkeur aan symptoom-alerts (foutenpercentage, latency, drop-tellers) met snelle feedback, en oorzaak-alerts (BGP-flap, link down) met paging wanneer impact op de gebruiker waarschijnlijk is.
• SLO’s: definieer gebruikersgerichte SLO’s (bijv. wereldwijd HTTP-succes en -latency) en burn-rate-alerts om snelle en langzame ‘burns’ te identificeren. Gebruik request-logs als teller/noemer via op logs gebaseerde metrics voor een precieze SLO-evaluatie.

Afwegingen en faalscenario’s:

• Lage sampling of lange aggregatie verbergt microbursts en kortstondige storingen.
• Flow logs bieden geen inzicht in drops die vóór de firewall plaatsvinden; gebruik logging van firewallregels voor bewijs van ‘deny’.
• Overmatig loggen zonder filtering verhoogt de kosten en kan onderzoeken vertragen; exporteer en partitioneer data slim.

Network Intelligence Center en Geavanceerde Diagnostiek

Network Intelligence Center (NIC) biedt proactieve en gestructureerde diagnostiek:

Connectivity Tests:

• Valideert de bereikbaarheid van het control plane over routes, firewallregels (inclusief hiërarchische policies), service accounts/tags, load balancers, Cloud NAT en hybride connectiviteit.
• Route-diagnostiek berekent de geselecteerde ’next hop’ en rapporteert misconfiguraties zoals ontbrekende routes of asymmetrische paden.
• Gebruik dit voor en na elke netwerkwijziging om een onbedoelde ‘blast radius’ te detecteren. Het modelleert het control plane en garandeert niet de kwaliteit van het data plane; combineer het met pakket-/metric-bewijs.

Performance Dashboard:

• Een door Google beheerd overzicht van pakketverlies en latency tussen regio’s en naar ‘internet vantage points’. Nuttig om macro-gebeurtenissen (regionale congestie of congestie over het hele pad) te onderscheiden van lokale serviceproblemen.

Network Topology:

• Visualiseert verbindingen tussen projecten, tussen VPC’s en hybride verbindingen, evenals verkeersvolumes (op basis van logs) om hotspots, onverwachte peering-paden en transitief gedrag dat je mogelijk niet bedoelt te identificeren.

Firewall Insights:

• Detecteert ‘shadowed’ regels (regels die door andere worden overschaduwd), ongebruikte ‘allow’-regels, te permissieve bronnen en regels zonder target-tags/service-accounts. Het adviseert strakkere regels om het aanvalsoppervlak te verkleinen zonder bekende flows te verstoren.

Network Analyzer:

• Statische en dynamische configuratiecontroles over projecten heen om omstandigheden aan het licht te brengen zoals:
  • Health checks die door de firewall worden geblokkeerd (vergeet niet de IP-ranges van de Google health-check-bronnen toe te staan).
  • Load balancer-backends in de verkeerde regio’s of zonder de vereiste ’named ports’.
  • Subnetten met uitgeschakelde Private Google Access die API-toegang blokkeren voor instances zonder externe IP’s.
  • Routes die belangrijke prefixes ‘blackholen’ of asymmetrische routing over VPN’s/Interconnects.

Operationele richtlijnen:

• Integreer NIC-controles in CI/CD voor netwerkwijzigingen en voer ze op een vast schema uit. Behandel bevindingen als ‘reliability debt’ en geef prioriteit aan oplossingen die het risico verminderen.

Packet Mirroring, Loadbalancers en Hybride Telemetrie

Packet Mirroring:

• Spiegelt VM-verkeer naar een collector (appliance of beheerde IDS) voor diepgaande inspectie. Scope op basis van subnet, netwerktags of serviceaccounts; beperk tot de vereiste protocollen om de kosten te beheersen.
• Overheads en afwegingen: uitgaand gespiegeld verkeer brengt kosten met zich mee; overmatig spiegelen kan collectors overbelasten; spiegel niet willekeurig in productie. Gebruik voor incidenten sessies die in tijd beperkt zijn en een nauwe scope hebben.
• IDS-integratie:
  • Cloud IDS biedt beheerde, out-of-band dreigingsdetectie die gebruikmaakt van Packet Mirroring. Geef hier de voorkeur aan voor snelle activering en minder onderhoud.
  • IDS-appliances van derden blijven een haalbare optie waar specifieke signatures of leveranciersecosystemen vereist zijn.

Logs van loadbalancers en bewijs van health-checks:

• Request-logs van HTTP(S)-loadbalancers bevatten de methode, URL, backend, responscode, latency en client-IP’s via X-Forwarded-For. Gebruik deze voor client-pad-analyse, omdat traceroute stopt bij de Google Front Ends (GFE’s).
• Schakel logging in op backend services en configureer sampling om een balans te vinden tussen kosten en zichtbaarheid. Schakel logging van health-checks in om de resultaten van probes en de redenen voor storingen te zien.
• Clienttoegang beperken: dwing dit af op de backends door instances te taggen en firewallregels aan te maken die alleen goedgekeurde client-ranges en de IP-adressen van Google-health-checks toestaan. Voor L7-dreigingsmitigatie en een geleidelijke uitrol, gebruik je Cloud Armor-regels in preview-modus voordat je ze afdwingt.

Telemetrie van VPN en Interconnect:

• Metrics van Cloud VPN (HA VPN): bytes, drops, encryptiefouten, tunnel-uptime en de status van de BGP-sessie. Stel alerts in voor packet drops, frequente DPD-events en BGP-flaps.
• Doorvoersnelheid schalen: voeg tunnels toe naar afzonderlijke peer-IP’s en verdeel het verkeer; monitor de overgebleven capaciteit (headroom). Als je een active/standby-configuratie over Cloud Routers nodig hebt, geef dan de voorkeur aan het on-prem MED-attribuut om de padselectie te beïnvloeden.
• Metrics van Interconnect: gebruik per link, CRC-fouten en beschikbaarheid; let op aanhoudend gebruik >60–70% en pieken in fouten. Zorg voor reservecapaciteit en diverse circuits. Onderzoek toenames in latency aan de hand van hertransmissies en wachtrij-indicatoren.
• Signalen van verzadiging aan de netwerkranden: stijgende TCP-hertransmissies, verhoogde 99e-percentiel latency zonder codewijzigingen, NAT-poort-overflow-events en alerts voor wachtrijbezetting zijn vroege waarschuwingen voor naderende impact.

Methodologie voor Probleemoplossing, Incidentafhandeling en Proactieve Betrouwbaarheid

Gestructureerde probleemoplossing van DNS tot applicatie:

1. Identificeer het falende gebruikerstraject en het tijdsvenster; bepaal de regio en het pad (publiek via LB, privaat via VPC, of hybride).
2. DNS:

• Valideer de resolutie met Cloud DNS-logs, dig-output en het gedrag van beleidsregels. Controleer op split-horizon-conflicten en zorg ervoor dat forwarding-beleidsregels van kracht zijn.
• Bevestig TTL’s en recente wijzigingen; verouderde caches kunnen storingen nabootsen.

3. Load balancer en edge:

• Bekijk de request- en healthcheck-logs. Correleer pieken in 5xx-fouten met de status van de backend en deployment-gebeurtenissen. Vertrouw voor L7 op request-logs in plaats van traceroute.
• Verifieer client-allowlists en Google healthcheck-IP’s in firewallregels wanneer de toegang beperkt is.

4. Routering en firewall:

• Gebruik Connectivity Tests voor een deterministische evaluatie van het control plane. Inspecteer effectieve routes en hiërarchische firewall-beleidsregels. Zoek naar asymmetrische routering en overschaduwde regels.
• Vertrouw voor geweigerde pakketten op logging van firewallregels; overweeg om tijdens onderzoeken een deny-all-regel met logging toe te voegen onderaan de prioriteitsstack.

5. Egress naar Google API’s:

• Als instances geen externe IP’s hebben, bevestig dan de aanwezigheid van Private Google Access en/of Cloud NAT. Het ontbreken van een van beide resulteert in intermitterende fouten en verwarrende time-outs.

6. Hybride:

• Onderzoek de metrics van Cloud Router en VPN/Interconnect. Als BGP up is maar routes niet zijn geïnstalleerd, kan dit duiden op attribuutvoorkeuren; verifieer MED/local-pref en ASN’s. Let op packet drops en path MTU-problemen.

7. Pakketbewijs:

• Als het control plane correct lijkt maar de symptomen aanhouden, gebruik dan Packet Mirroring gericht om PCAP te verzamelen nabij de getroffen VM of tier; controleer SYN/SYN-ACK-timing, hertransmissies en MSS/DF-bits voor MTU-blackholes.

Incidentafhandeling:

• Veiligheid bij wijzigingen: voer wijzigingen gefaseerd door door ze te scopen op tags/service accounts, met een lagere prioriteit en uitgeschakelde regels; schakel logging in en test met canaries. Gebruik Cloud Armor-preview voor wijzigingen in L7-beleid.
• Rollback: definieer vooraf omgekeerde wijzigingen, bewaar eerdere configuraties in versiebeheer en gebruik waar van toepassing kortlevende feature flags aan de rand van de applicatie.
• Analyse na een incident: construeer een tijdlijn op basis van logs en metrics, classificeer bijdragende factoren (bijv. een permissieve regel die wordt overschaduwd door een deny-regel, NAT-uitputting), leg detectiehiaten vast en voeg veiligheidsmaatregelen toe: alerts, NIC-checks en beleidsverharding.

Capaciteitsplanning en proactieve betrouwbaarheid:

• Volg headroom-doelstellingen: 30–50% op VPN/Interconnect-links, NAT-poortgebruik aanhoudend onder de 60%, backend-CPU en QPS van de LB ruim onder de autoscaling-triggers.
• Bouw op logs gebaseerde metrics voor belangrijke risico’s: pieken in weigeringen, NAT-overflow, aantal BGP-flaps, 5xx-percentages en verbindingsfouten van de LB-backend. Gebruik multi-window burn-rate alerts om zowel snelle als langzame incidenten te detecteren.
• Synthetische monitoring: gebruik Uptime Checks vanuit meerdere regio’s voor publieke endpoints en private probes vanaf test-VM’s voor interne services.
• Preventieve verbeteringen: verfijn firewallregels met behulp van Firewall Insights, los bevindingen van Network Analyzer op, verkort de Flow Log-aggregatie tijdens piekgebeurtenissen en exporteer logs naar BigQuery voor terugkerende anomaliedetectie.

Praktisch Probleemscenario

Contoso Games beheert een wereldwijde, via HTTP(S) load-balanced gaming-API in us-east1 en europe-west1, met HA VPN naar een on-prem datacenter. Gebruikers in Europa melden intermitterende time-outs en hogere latency na een recente firewallwijziging. De instances hebben geen externe IP’s en moeten Google API’s privaat bereiken.

Aanpak:

1. Tijdsvenster en SLO-impact vaststellen

• Rationale: Het exact bepalen van het venster beperkt queries tot relevante logs en stemt het onderzoek af op SLO’s die gebruikersimpact hebben. Een burn-rate alert bevestigt een snelle SLO-burn in europe-west1.

2. Control plane valideren met Connectivity Tests

• Rationale: Maak een test van de externe HTTP(S) load balancer-frontend naar de europe-west1 backend-service en van de getroffen VM’s naar een Private Google Access VIP. De test signaleert een hiërarchische firewall-beleidsregel die healthchecks naar sommige backends blokkeert en ontbrekende Private Google Access voor één subnet.

3. Status van edge en backend bevestigen via logs

• Rationale: Filter de request-logs van de load balancer voor europe-west1 en response_code >= 500 om backend-fouten te isoleren. Healthcheck-logs tonen probe-fouten vanaf bekende Google healthcheck-bron-IP’s. Dit duidt op door de firewall veroorzaakte backend-flapping in plaats van applicatieregressies.

4. Status herstellen en veiligheid waarborgen met gerichte wijzigingen

• Rationale: Voeg een allow-regel toe die is gericht op backend-tags en die de healthcheck-bronranges toestaat. Schakel logging in op deze regel. Omdat de toegang beperkt is tot bekende clients, verifieer dat de allowlist-firewallregel alleen de specifieke client-IP-ranges en de healthcheck-ranges bevat. Houd de nieuwe regel aanvankelijk uitgeschakeld en schakel deze vervolgens in tijdens een low-traffic canary om de impact (‘blast radius’) te beperken.

5. Private egress naar Google API’s herstellen

• Rationale: Schakel Private Google Access in op het getroffen subnet zodat instances zonder externe IP’s Google-services kunnen bereiken zonder hairpinning via de VPN of firewalls van derden. Dit vermindert de latency en verwijdert een knelpunt.

6. Hybride saturatie en MTU controleren

• Rationale: Bekijk de HA VPN-metrics voor packet drops en gebruik. Eén tunnel vertoont verhoogde drops. Verhoog de capaciteit door een tweede tunnel toe te voegen naar een ander on-prem peer-IP en verdeel het verkeer. Verifieer de effectieve MTU en MSS-clamp om PMTU-blackholes op het VPN-pad te voorkomen.

7. Cloud Armor-preview gebruiken voor verdachte, misbruik makende clients

• Rationale: Uit de request-logs blijkt dat een kleine set client-IP’s het verkeer laat pieken net voor de probe-fouten. Voeg een deny-regel toe in Cloud Armor met preview-modus om te valideren dat het blokkeren de backend-load zou verminderen vóór de handhaving, om onbedoelde gebruikersimpact te vermijden.

8. Packet Mirroring gericht inzetten om data-plane-gedrag te bevestigen

• Rationale: Mirror verkeer van één ongezonde backend-VM naar Cloud IDS gedurende 15 minuten. PCAP toont uitputting van de SYN-backlog tijdens pieken van de misbruik makende IP’s, wat het nut van de Cloud Armor-beleidsregel en de noodzaak van rate limiting bevestigt.

9. Het incident sluiten en systemen verharden

• Rationale: Na het inschakelen van de healthcheck-allow-regel, het bevestigen van Private Google Access, het schalen van de VPN-capaciteit en het handhaven van de geverifieerde Cloud Armor-regel, keren de foutpercentages terug naar de baseline. Voeg dashboards toe voor het succespercentage van healthchecks, NAT-poortgebruik, VPN-drops en 5xx-fouten per regio. Maak op logs gebaseerde alerts voor firewall-weigeringen naar backend-tags en SLO burn-rate alerts. Documenteer het incident, de hoofdoorzaken (hiërarchische firewallwijziging; misbruik makend verkeer; VPN-saturatie) en voeg NIC Analyzer- en Firewall Insights-checks toe aan de checklist voor wijzigingen.

Deze volgorde demonstreert een veilige, op bewijs gebaseerde workflow: bevestig het control plane, observeer het data plane, pas minimale, omkeerbare wijzigingen toe en institutionaliseer vervolgens de leerpunten met alerts en geautomatiseerde checks.

← GKE · Alle domeinen · Netwerkautomatisering →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →

Blader door Google →