Google PCNE: Netzwerk-Observability, Zuverlässigkeit und Fehlerbehebung — Lernleitfaden

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

Teil des Google Professional Cloud Network Engineer — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Netzwerk-Observability in der Google Cloud ist die disziplinierte Erfassung, Korrelation und Analyse von Netzwerksignalen, die Erreichbarkeit, Leistung und Korrektheit über VPCs, Load Balancer, hybride Verbindungen und Dienste hinweg beschreiben. Zuverlässigkeit ergibt sich aus dem Design für Fehlererkennung und sichere Behebung: Instrumentieren Sie erstklassige Telemetrie, validieren Sie die Steuerungsebene, bevor Sie die Datenebene berühren, führen Sie nur bei Bedarf eine Detailanalyse mit Paketnachweisen durch und automatisieren Sie Rollbacks. Dieser Abschnitt erklärt, wie Sie mit den Tools und Mustern der Google Cloud Probleme erkennen, diagnostizieren und verhindern können, während das Risiko bei Änderungen minimiert wird.

Flow Logs, Logging, Monitoring, Metrics und SLOs

VPC Flow Logs liefern gesampelte, aggregierte Telemetrie an der VM-NIC nach der Auswertung durch die VPC-Firewall. Sie sind keine vollständigen Paketerfassungen und ersetzen nicht das Firewall-Regel-Logging für explizite Nachweise von Zulassungen/Ablehnungen. Wichtige Steuerelemente:

Sampling: 0,0–1,0. Ein höheres Sampling verbessert die Genauigkeit auf Kosten des Log-Volumens und potenzieller Kosten.
Aggregationsintervall: 5s–30m. Kürzere Intervalle reduzieren die Zeit bis zur Erkennung, erhöhen aber die Anzahl der Einträge.
Metadaten: Instanz- und VPC-Metadaten ein- oder ausschließen. Einschließen für umfassendere Analysen, ausschließen, um sensible Attribute zu begrenzen.

Typische Aktivierung in einem Subnetz:

undefined

Export mit Log-Senken für dauerhafte Analysen und projektübergreifende Freigabe:

BigQuery für SQL-Analysen und langfristige Trendanalysen.
Pub/Sub für Nahezu-Echtzeit-Pipelines zu SIEM/IDS.
Cloud Storage für die Archivierung.
Beispiel für eine Senke nach BigQuery:

undefined

Das Firewall-Regel-Logging ergänzt Flow Logs, indem es Zulassungs-/Ablehnungsentscheidungen und übereinstimmende Regeln aufzeichnet. Um blockierten Traffic zu beobachten, fügen Sie eine deny-all-Regel mit Logging am Ende Ihres Regelsatzes hinzu:

undefined

Cloud Logging ermöglicht strukturierte Abfragen, Korrelation mit Anfrage-Logs, Health-Check-Logs, NAT-Logs und Load-Balancer-Logs. Erstellen Sie logbasierte Messwerte für Signale wie:

Plötzlicher Anstieg abgelehnter Verbindungen zu Backend-Tags (möglicherweise falsch konfigurierte Allow-Listen).
Hohes Volumen an SYN-Retransmits an einem Port (mögliche Sättigung oder Blackholing).
NAT-Ereignisse vom Typ „no available ports“ (Erschöpfung von Cloud NAT).

Cloud Monitoring aggregiert Messwerte und stellt Dashboards, Benachrichtigungen und SLOs bereit:

Zu beobachtende Messwerte: 5xx-Rate des Load Balancers, Backend-Latenz, Bytes/Pakete der Instanz-NIC, zugewiesene/genutzte/Überlauf-Ports von Cloud NAT, BGP-Sitzungsstatus von Cloud Router, Paketverluste bei VPN-Tunneln, Auslastung von Interconnect-Links, Paketverlust und Latenz.
Dashboards: Erstellen Sie pro Dienst und pro Konnektivität Dashboards mit gemeinsamen Vorlagen über Projekte hinweg für einen konsistenten Betrieb.
Benachrichtigungen: Bevorzugen Sie Symptom-Benachrichtigungen (Fehlerrate, Latenz, Drop-Zähler) mit schnellem Feedback und Ursachen-Benachrichtigungen (BGP-Flap, Link-Ausfall) mit Paging, wenn eine Auswirkung auf den Nutzer wahrscheinlich ist.
SLOs: Definieren Sie nutzerzentrierte SLOs (z. B. globaler HTTP-Erfolg und Latenz) und Burn-Rate-Benachrichtigungen, um schnelle und langsame „Burns“ zu identifizieren. Verwenden Sie Anfrage-Logs als Zähler/Nenner über logbasierte Messwerte für eine präzise SLO-Auswertung.

Abwägungen und Fehlermodi:

Niedriges Sampling oder lange Aggregation verbergen Microbursts und kurzlebige Ausfälle.
Flow Logs bieten keine Einblicke in Drops vor der Firewall; stützen Sie sich für den Nachweis von Ablehnungen auf das Firewall-Regel-Logging.
Übermäßiges Logging ohne Filterung erhöht die Kosten und kann Untersuchungen verlangsamen; exportieren und partitionieren Sie Daten intelligent.

Network Intelligence Center und erweiterte Diagnosen

Das Network Intelligence Center (NIC) bietet proaktive und strukturierte Diagnosen:

Connectivity Tests:

Validiert die Erreichbarkeit der Steuerungsebene über Routen, Firewall-Regeln (einschließlich hierarchischer Richtlinien), Servicekonten/Tags, Load Balancer, Cloud NAT und hybride Konnektivität.
Routendiagnosen berechnen den ausgewählten nächsten Hop und melden Fehlkonfigurationen wie fehlende Routen oder asymmetrische Pfade.
Verwenden Sie dies vor und nach jeder Netzwerkänderung, um einen unbeabsichtigten „Blast Radius“ (Auswirkungsbereich) zu erkennen. Es modelliert die Steuerungsebene und garantiert nicht die Qualität der Datenebene; kombinieren Sie es mit Paket-/Messwertnachweisen.

Performance Dashboard:

Von Google verwaltete Ansicht von Paketverlust und Latenz zwischen Regionen und zu Internet-Vantage-Points. Nützlich, um Makroereignisse (regionale oder pfadweite Überlastung) von dienstlokalen Problemen zu unterscheiden.

Network Topology:

Visualisiert projekt-, VPC- und hybridübergreifende Verbindungen und Traffic-Volumen (unter Nutzung von Logs), um Hotspots, unerwartete Peering-Pfade und transitive Verhaltensweisen zu identifizieren, die Sie möglicherweise nicht beabsichtigen.

Firewall Insights:

Erkennt verdeckte Regeln („shadowed rules“), ungenutzte Zulassungen, übermäßig freizügige Quellen und Regeln, denen Ziel-Tags/Servicekonten fehlen. Es empfiehlt strengere Regeln, um die Angriffsfläche zu verringern, ohne bekannte Datenflüsse zu unterbrechen.

Network Analyzer:

Statische und dynamische Konfigurationsprüfungen über Projekte hinweg, um Zustände aufzudecken wie:
- Systemdiagnosen (Health Checks), die von der Firewall blockiert werden (denken Sie daran, die Quell-IP-Bereiche der Google-Systemdiagnosen zuzulassen).
- Load-Balancer-Backends in falschen Regionen oder mit fehlenden benannten Ports.
- Subnetze mit deaktiviertem privatem Google-Zugriff, die den API-Zugriff für Instanzen ohne externe IPs blockieren.
- Routen, die wichtige Präfixe per Blackholing verwerfen oder asymmetrisches Routing über VPNs/Interconnects verursachen.

Betriebliche Anleitung:

Integrieren Sie NIC-Prüfungen in CI/CD für Netzwerkänderungen und führen Sie sie nach einem Zeitplan aus. Behandeln Sie die Ergebnisse als Zuverlässigkeitsschulden („reliability debt“) und priorisieren Sie Korrekturen mit auswirkungsreduzierendem Risiko.

Packet Mirroring, Load Balancer und hybride Telemetrie

Packet Mirroring:

Spiegelt den VM-Traffic an einen Collector (Appliance oder verwaltetes IDS) zur tiefgehenden Untersuchung. Der Geltungsbereich kann nach Subnetz, Netzwerk-Tags oder Service Accounts festgelegt werden; beschränken Sie ihn auf erforderliche Protokolle, um die Kosten zu kontrollieren.
Overhead und Kompromisse: Ausgehender gespiegelter Traffic verursacht Kosten; übermäßiges Spiegeln kann Collectors überlasten; in der Produktion nicht wahllos spiegeln. Verwenden Sie für Vorfälle zeitlich begrenzte Sitzungen mit eng gefasstem Geltungsbereich.
IDS-Integration:
- Cloud IDS bietet eine verwaltete Out-of-Band-Bedrohungserkennung, die Packet Mirroring nutzt. Bevorzugen Sie es für eine schnelle Aktivierung und einen geringeren Wartungsaufwand.
- IDS-Appliances von Drittanbietern bleiben eine praktikable Option, wenn spezifische Signaturen oder Hersteller-Ökosysteme erforderlich sind.

Load-Balancer-Logs und Health-Check-Nachweise:

Anfrageprotokolle des HTTP(S)-Load-Balancers enthalten Methode, URL, Backend, Antwortcode, Latenz und Client-IPs über X-Forwarded-For. Verwenden Sie diese für die Analyse des Client-Pfads, da Traceroute an den Google Front Ends (GFEs) endet.
Aktivieren Sie die Protokollierung für Backend-Dienste und konfigurieren Sie das Sampling, um Kosten und Transparenz abzuwägen. Aktivieren Sie die Health-Check-Protokollierung, um die Ergebnisse der Probes und die Fehlerursachen zu sehen.
Beschränkung des Client-Zugriffs: Setzen Sie dies auf den Backends durch, indem Sie Instanzen taggen und Firewall-Regeln erstellen, die nur genehmigte Client-Bereiche und die Google Health-Check-IPs zulassen. Für die L7-Bedrohungsabwehr und eine schrittweise Einführung verwenden Sie Cloud Armor-Regeln im Vorschaumodus, bevor Sie sie erzwingen.

VPN- und Interconnect-Telemetrie:

Metriken für Cloud VPN (HA VPN): Bytes, Drops, Verschlüsselungsfehler, Tunnel-Uptime und BGP-Sitzungsstatus. Bei Paketverlusten, häufigen DPD-Ereignissen und BGP-Flaps alarmieren.
Durchsatzskalierung: Fügen Sie Tunnel zu unterschiedlichen Peer-IPs hinzu und verteilen Sie den Traffic; überwachen Sie die Leistungsreserven. Wenn Sie Aktiv/Standby über Cloud Router hinweg benötigen, bevorzugen Sie das on-prem MED-Attribut, um die Pfadauswahl zu beeinflussen.
Interconnect-Metriken: Auslastung pro Link, CRC-Fehler und Verfügbarkeit; achten Sie auf eine dauerhafte Auslastung von >60–70 % und Fehlerspitzen. Halten Sie Ersatzkapazitäten und diverse Leitungen vor. Untersuchen Sie Latenzanstiege anhand von Retransmissions und Warteschlangenindikatoren.
Sättigungssignale an den Edges: Steigende TCP-Retransmits, erhöhte Latenz im 99. Perzentil ohne Code-Änderungen, NAT-Port-Überlaufereignisse und Warnungen zur Warteschlangenauslastung sind Frühwarnzeichen für bevorstehende Auswirkungen.

Fehlerbehebungsmethodik, Incident-Management und proaktive Zuverlässigkeit

Strukturierte Fehlerbehebung von DNS bis zur Anwendung:

Identifizieren Sie die fehlerhafte User Journey und das Zeitfenster; grenzen Sie dies auf eine Region und einen Pfad ein (öffentlich über LB, privat über VPC oder hybrid).
DNS:

Validieren Sie die Namensauflösung mit Cloud DNS-Logs, der Ausgabe von dig und dem Verhalten von Richtlinien. Prüfen Sie auf Split-Horizon-Konflikte und stellen Sie sicher, dass Weiterleitungsrichtlinien wirksam sind.
Bestätigen Sie TTLs und kürzliche Änderungen; veraltete Caches können Ausfälle imitieren.

Load Balancer und Edge:

Überprüfen Sie Anfrage- und Health-Check-Logs. Korrelieren Sie 5xx-Spitzen mit dem Zustand des Backends und Deployment-Ereignissen. Bei L7 sollten Sie den Anfrage-Logs mehr vertrauen als traceroute.
Überprüfen Sie Client-Allowlists und die IPs der Google Health-Checks in den Firewall-Regeln, wenn der Zugriff eingeschränkt ist.

Routing und Firewall:

Verwenden Sie Connectivity Tests für eine deterministische Evaluierung der Control Plane. Inspizieren Sie effektive Routen und hierarchische Firewall-Richtlinien. Achten Sie auf asymmetrisches Routing und verdeckte (shadowed) Regeln.
Verlassen Sie sich bei verweigerten Paketen auf das Logging von Firewall-Regeln; erwägen Sie, während der Untersuchung eine protokollierte Deny-All-Regel mit niedriger Priorität hinzuzufügen.

Egress zu Google APIs:

Wenn Instanzen keine externen IPs haben, bestätigen Sie Private Google Access und/oder Cloud NAT. Das Fehlen von einem der beiden führt zu intermittierenden Fehlern und verwirrenden Timeouts.

Hybrid:

Untersuchen Sie die Metriken von Cloud Router und VPN/Interconnect. Wenn BGP aktiv ist, aber Routen nicht installiert werden, kann dies auf Attributpräferenzen hindeuten; überprüfen Sie MED/local-pref und ASNs. Achten Sie auf verworfene Pakete und Probleme mit der Path MTU.

Paket-Beweise:

Wenn die Control Plane korrekt aussieht, die Symptome aber weiterhin bestehen, verwenden Sie Packet Mirroring gezielt, um PCAP in der Nähe der betroffenen VM oder Schicht zu sammeln; überprüfen Sie das Timing von SYN/SYN-ACK, Retransmissions und die MSS/DF-Bits auf MTU-Blackholes.

Incident-Management:

Änderungssicherheit: Führen Sie Änderungen schrittweise ein, indem Sie den Geltungsbereich auf Tags/Service-Konten, eine niedrigere Priorität und deaktivierte Regeln beschränken; aktivieren Sie das Logging und testen Sie mit Canaries. Verwenden Sie die Vorschau von Cloud Armor für Änderungen an L7-Richtlinien.
Rollback: Definieren Sie inverse Änderungen vorab, halten Sie frühere Konfigurationen in der Versionskontrolle und verwenden Sie gegebenenfalls kurzlebige Feature-Flags am App-Edge.
Post-Incident-Analyse: Erstellen Sie eine Zeitachse aus Logs und Metriken, klassifizieren Sie die beitragenden Faktoren (z. B. eine permissive Regel, die von einer Deny-Regel verdeckt wird, NAT-Erschöpfung), dokumentieren Sie Lücken bei der Erkennung und fügen Sie Schutzmaßnahmen hinzu: Alerts, NIC-Prüfungen und Härtung von Richtlinien.

Kapazitätsplanung und proaktive Zuverlässigkeit:

Verfolgen Sie Headroom-Ziele: 30–50 % bei VPN/Interconnect-Verbindungen, NAT-Port-Nutzung nachhaltig unter 60 %, CPU und QPS der LB-Backends deutlich unter den Autoscaling-Triggern.
Erstellen Sie logbasierte Metriken für Schlüsselrisiken: Deny-Spitzen, NAT-Überlauf, Anzahl der BGP-Flaps, 5xx-Raten und Verbindungsfehler bei LB-Backends. Verwenden Sie Multi-Window-Burn-Rate-Alerts, um sowohl schnelle als auch langsame Incidents zu erkennen.
Synthetisches Monitoring: Verwenden Sie Uptime Checks aus mehreren Regionen für öffentliche Endpunkte und private Probes von Test-VMs für interne Dienste.
Präventive Verbesserungen: Verfeinern Sie Firewall-Regeln mithilfe von Firewall Insights, beheben Sie die Ergebnisse von Network Analyzer, verkürzen Sie die Aggregation von Flow Logs während Spitzenlastzeiten und exportieren Sie Logs nach BigQuery zur wiederkehrenden Anomalieerkennung.

Praktisches Problemszenario

Contoso Games betreibt eine globale, über HTTP(S)-Load-Balancing bereitgestellte Gaming-API in us-east1 und europe-west1, mit HA VPN zu einem On-Prem-Rechenzentrum. Benutzer in Europa melden intermittierende Timeouts und höhere Latenz nach einer kürzlichen Firewall-Änderung. Die Instanzen haben keine externen IPs und müssen Google APIs privat erreichen.

Vorgehensweise:

Zeitfenster und SLO-Auswirkungen feststellen

Begründung: Die Eingrenzung des Zeitfensters beschränkt Abfragen auf relevante Logs und richtet die Untersuchung an den für den Benutzer spürbaren SLOs aus. Ein Burn-Rate-Alert bestätigt einen schnellen SLO-Burn in europe-west1.

Control Plane mit Connectivity Tests validieren

Begründung: Erstellen Sie einen Test vom Frontend des externen HTTP(S)-Load-Balancers zum Backend-Dienst in europe-west1 und von den betroffenen VMs zu einer VIP für Private Google Access. Der Test meldet eine hierarchische Firewall-Richtlinie, die Health-Checks zu einigen Backends blockiert, sowie fehlenden Private Google Access für ein Subnetz.

Edge- und Backend-Zustand über Logs bestätigen

Begründung: Filtern Sie die Anfrage-Logs des Load Balancers für europe-west1 und response_code >= 500, um Backend-Fehler zu isolieren. Die Health-Check-Logs zeigen fehlgeschlagene Probes von bekannten Google Health-Check-Quell-IPs. Dies belegt ein durch die Firewall verursachtes Flapping der Backends anstelle von Anwendungsregressionen.

Zustand wiederherstellen und Sicherheit durch gezielte Änderungen gewährleisten

Begründung: Fügen Sie eine Allow-Regel hinzu, die auf Backend-Tags abzielt und die Quellbereiche der Health-Checks zulässt. Aktivieren Sie das Logging für diese Regel. Da der Zugriff auf bekannte Clients beschränkt ist, überprüfen Sie, ob die Allowlist-Firewall-Regel nur die spezifischen Client-IP-Bereiche und die Health-Check-Bereiche enthält. Lassen Sie die neue Regel zunächst deaktiviert und aktivieren Sie sie dann während eines Canary-Tests mit geringem Traffic, um den Blast Radius zu begrenzen.

Privaten Egress zu Google APIs wiederherstellen

Begründung: Aktivieren Sie Private Google Access auf dem betroffenen Subnetz, damit Instanzen ohne externe IPs Google-Dienste erreichen, ohne über VPN oder Firewalls von Drittanbietern zu hairpinning. Dies reduziert die Latenz und beseitigt einen Engpass.

Hybride Sättigung und MTU prüfen

Begründung: Überprüfen Sie die HA VPN-Metriken auf verworfene Pakete und Auslastung. Ein Tunnel zeigt erhöhte Paketverluste. Erhöhen Sie die Kapazität, indem Sie einen zweiten Tunnel zu einer anderen On-Prem-Peer-IP hinzufügen und den Traffic verteilen. Überprüfen Sie die effektive MTU und MSS Clamp, um PMTU-Blackholes auf dem VPN-Pfad zu verhindern.

Cloud Armor-Vorschau für verdächtige missbräuchliche Clients verwenden

Begründung: Aus den Anfrage-Logs geht hervor, dass eine kleine Gruppe von Client-IPs kurz vor den fehlgeschlagenen Probes Traffic-Spitzen verursacht. Fügen Sie eine Deny-Regel in Cloud Armor im Vorschaumodus hinzu, um zu validieren, dass das Blockieren die Backend-Last reduzieren würde, bevor die Regel durchgesetzt wird, und so versehentliche Auswirkungen auf Benutzer zu vermeiden.

Packet Mirroring gezielt einsetzen, um das Verhalten der Data Plane zu bestätigen

Begründung: Spiegeln Sie den Traffic von einer einzelnen fehlerhaften Backend-VM für 15 Minuten zu Cloud IDS. Das PCAP zeigt eine Erschöpfung des SYN-Backlogs während der Bursts von den missbräuchlichen IPs, was den Nutzen der Cloud Armor-Richtlinie und die Notwendigkeit von Rate Limiting bestätigt.

Incident abschließen und System härten

Begründung: Nachdem die Allow-Regel für Health-Checks aktiviert, Private Google Access bestätigt, die VPN-Kapazität skaliert und die geprüfte Cloud Armor-Regel durchgesetzt wurde, kehren die Fehlerraten auf den Normalwert zurück. Fügen Sie Dashboards für die Erfolgsrate der Health-Checks, die NAT-Port-Nutzung, VPN-Drops und die 5xx-Rate pro Region hinzu. Erstellen Sie logbasierte Alerts für Firewall-Denies zu Backend-Tags und SLO-Burn-Rate-Alerts. Dokumentieren Sie den Incident, die Ursachen (hierarchische Firewall-Änderung; missbräuchlicher Traffic; VPN-Sättigung) und fügen Sie Prüfungen mit NIC Analyzer und Firewall Insights zur Pre-Change-Checkliste hinzu.

Diese Abfolge demonstriert einen sicheren, evidenzbasierten Arbeitsablauf: Control Plane bestätigen, Data Plane beobachten, minimale, reversible Änderungen anwenden und dann die gewonnenen Erkenntnisse durch Alerts und automatisierte Prüfungen institutionalisieren.

← GKE · Alle Domänen · Netzwerkautomatisierung →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →