Google PCNE: Observabilité du réseau, fiabilité et dépannage — Guide d'étude

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

Fait partie du Google Professional Cloud Network Engineer — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Google, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

L’observabilité réseau sur Google Cloud est la collecte, la corrélation et l’analyse disciplinées des signaux réseau qui décrivent l’accessibilité, les performances et l’exactitude à travers les VPC, les équilibreurs de charge, les connexions hybrides et les services. La fiabilité découle d’une conception axée sur la détection des pannes et la remédiation sécurisée : instrumenter une télémétrie de premier ordre, valider le plan de contrôle avant de toucher au plan de données, analyser en profondeur avec des preuves par paquets uniquement lorsque c’est nécessaire, et automatiser la restauration (rollback). Cette section explique comment utiliser les outils et les modèles Google Cloud pour détecter, diagnostiquer et prévenir les problèmes tout en minimisant les risques lors des changements.

Journaux de flux, journalisation, surveillance, métriques et SLO

Les VPC Flow Logs fournissent une télémétrie échantillonnée et agrégée au niveau de la carte réseau (NIC) de la VM, après l’évaluation par le pare-feu VPC. Il ne s’agit pas de captures de paquets complètes et ils ne remplacent pas la journalisation des règles de pare-feu pour obtenir des preuves explicites d’autorisation (allow) ou de refus (deny). Contrôles clés :

Échantillonnage : 0.0–1.0. Un échantillonnage plus élevé améliore la fidélité au détriment du volume de journaux et d’un coût potentiel.
Intervalle d’agrégation : 5s–30m. Des intervalles plus courts réduisent le temps de détection mais augmentent le nombre d’entrées.
Métadonnées : inclure ou exclure les métadonnées de l’instance et du VPC. Inclure pour des analyses plus riches, exclure pour limiter les attributs sensibles.

Activation typique sur un sous-réseau :

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

Exportez avec des récepteurs de journaux (log sinks) pour une analyse durable et un partage entre projets :

BigQuery pour l’analyse SQL et l’analyse des tendances à long terme.
Pub/Sub pour les pipelines en quasi-temps réel vers des SIEM/IDS.
Cloud Storage pour l’archivage.
Exemple de récepteur vers BigQuery :
- gcloud logging sinks create flowlogs-to-bq bigquery.googleapis.com/projects/PROJECT/datasets/DATASET –log-filter=‘resource.type=“gce_subnetwork”’

La journalisation des règles de pare-feu complète les journaux de flux en enregistrant les décisions d’autorisation/refus et les règles correspondantes. Pour observer le trafic bloqué, ajoutez une règle de refus total (deny-all) avec journalisation vers la fin de votre ensemble de règles :

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

Cloud Logging permet des requêtes structurées, la corrélation avec les journaux de requêtes, les journaux de vérification de l’état (health-check), les journaux NAT et les journaux d’équilibreur de charge. Créez des métriques basées sur les journaux pour des signaux tels que :

Augmentations soudaines des connexions refusées vers des tags de backend (listes d’autorisation potentiellement mal configurées).
Volumes élevés de retransmissions SYN vers un port (saturation ou blackholing possible).
Événements NAT « no available ports » (épuisement de Cloud NAT).

Cloud Monitoring agrège les métriques et fournit des tableaux de bord, des alertes et des SLO :

Métriques à surveiller : taux d’erreurs 5xx de l’équilibreur de charge, latence du backend, octets/paquets de la carte réseau de l’instance, ports alloués/utilisés/en dépassement de Cloud NAT, état de la session BGP de Cloud Router, pertes de paquets du tunnel VPN, utilisation de la liaison Interconnect, perte de paquets et latence.
Tableaux de bord : créez des tableaux de bord par service et par connectivité avec des modèles partagés entre les projets pour des opérations cohérentes.
Alertes : privilégiez les alertes sur les symptômes (taux d’erreur, latence, compteurs de pertes) avec un retour rapide, et les alertes sur les causes (instabilité BGP, liaison hors service) avec notification (paging) lorsque l’impact sur l’utilisateur est probable.
SLO : définissez des SLO centrés sur l’utilisateur (par ex., succès et latence HTTP globaux) et des alertes de taux de consommation (burn-rate) pour identifier les consommations rapides et lentes du budget d’erreur. Utilisez les journaux de requêtes comme numérateur/dénominateur via des métriques basées sur les journaux pour une évaluation précise des SLO.

Compromis et modes de défaillance :

Un échantillonnage faible ou une agrégation longue masquent les micro-rafales (microbursts) et les pannes de courte durée.
Les journaux de flux manquent de visibilité sur les paquets rejetés avant le pare-feu ; fiez-vous à la journalisation des règles de pare-feu pour les preuves de refus.
Une journalisation excessive sans filtrage augmente les coûts et peut ralentir les investigations ; exportez et partitionnez les données intelligemment.

Network Intelligence Center et diagnostics avancés

Le Network Intelligence Center (NIC) fournit des diagnostics proactifs et structurés :

Tests de connectivité :

Valide l’accessibilité du plan de contrôle à travers les routes, les règles de pare-feu (y compris les règles hiérarchiques), les comptes de service/tags, les équilibreurs de charge, Cloud NAT et la connectivité hybride.
Les diagnostics de route calculent le prochain saut (next hop) sélectionné et signalent les erreurs de configuration telles que des routes manquantes ou des chemins asymétriques.
Utilisez-le avant et après tout changement réseau pour détecter un rayon d’impact (blast radius) involontaire. Il modélise le plan de contrôle et ne garantit pas la qualité du plan de données ; associez-le à des preuves par paquets/métriques.

Tableau de bord des performances :

Vue gérée par Google de la perte de paquets et de la latence entre les régions et vers des points d’observation Internet. Utile pour détecter les macro-événements (congestion régionale ou sur un chemin) par opposition aux problèmes locaux d’un service.

Topologie du réseau :

Visualise les connexions inter-projets, inter-VPC et hybrides ainsi que les volumes de trafic (en s’appuyant sur les journaux) pour identifier les points chauds (hot spots), les chemins de peering inattendus et les comportements transitifs que vous pourriez ne pas avoir prévus.

Statistiques de pare-feu (Firewall Insights) :

Détecte les règles masquées (shadowed rules), les autorisations inutilisées, les sources trop permissives et les règles sans tags/comptes de service cibles. Il recommande des règles plus strictes pour réduire la surface d’attaque sans interrompre les flux connus.

Analyseur de réseau (Network Analyzer) :

Vérifications de configuration statiques et dynamiques sur l’ensemble des projets pour faire apparaître des conditions telles que :
- Vérifications de l’état bloquées par le pare-feu (n’oubliez pas d’autoriser les plages d’adresses IP sources des vérifications de l’état de Google).
- Backends d’équilibreur de charge dans les mauvaises régions ou sans les ports nommés requis.
- Sous-réseaux avec l’accès privé à Google désactivé, bloquant l’accès aux API pour les instances sans adresse IP externe.
- Routes qui créent un trou noir (blackhole) pour des préfixes importants ou un routage asymétrique à travers des VPN/Interconnects.

Conseils opérationnels :

Intégrez les vérifications du NIC dans le CI/CD pour les changements réseau et exécutez-les à une cadence planifiée. Considérez les résultats comme une dette de fiabilité et priorisez les correctifs en fonction de leur impact sur la réduction des risques.

Mise en miroir de paquets, répartiteurs de charge et télémétrie hybride

Mise en miroir de paquets (Packet Mirroring) :

Met en miroir le trafic des VM vers un collecteur (appliance ou IDS géré) pour une inspection approfondie. Définissez la portée par sous-réseau, tags de réseau ou comptes de service ; limitez aux protocoles requis pour maîtriser les coûts.
Surcharges et compromis : le trafic de sortie mis en miroir engendre des coûts ; une mise en miroir excessive peut surcharger les collecteurs ; ne pas mettre en miroir sans discernement en production. Utilisez des sessions limitées dans le temps et à portée restreinte pour les incidents.
Intégration IDS :
- Cloud IDS fournit une détection des menaces gérée et hors bande en s’appuyant sur Packet Mirroring. Privilégiez-le pour une activation rapide et une maintenance réduite.
- Les appliances IDS tierces restent une option viable lorsque des signatures spécifiques ou des écosystèmes de fournisseurs sont requis.

Journaux du répartiteur de charge et preuves des vérifications de l’état :

Les journaux de requêtes du répartiteur de charge HTTP(S) incluent la méthode, l’URL, le backend, le code de réponse, la latence et les adresses IP des clients via X-Forwarded-For. Utilisez-les pour l’analyse du chemin client, car traceroute s’arrête aux Google Front Ends (GFE).
Activez la journalisation sur les services de backend et configurez l’échantillonnage pour équilibrer les coûts et la visibilité. Activez la journalisation des vérifications de l’état pour voir les résultats des sondes et les raisons des échecs.
Restreindre l’accès client : appliquez les restrictions au niveau des backends en taguant les instances et en créant des règles de pare-feu qui n’autorisent que les plages d’adresses IP clientes approuvées et les adresses IP des vérifications de l’état de Google. Pour l’atténuation des menaces de couche 7 et un déploiement progressif, utilisez les règles Cloud Armor en mode aperçu (preview) avant de les appliquer.

Télémétrie VPN et Interconnect :

Métriques Cloud VPN (HA VPN) : octets, paquets abandonnés (drops), erreurs de chiffrement, disponibilité du tunnel et état de la session BGP. Alertez sur les abandons de paquets, les événements DPD fréquents et les instabilités de session BGP (flaps).
Mise à l’échelle du débit : ajoutez des tunnels vers des adresses IP de pairs distinctes et répartissez le trafic ; surveillez la marge de manœuvre (headroom). Si vous avez besoin d’une configuration actif/passif entre des Cloud Routers, préférez l’attribut MED on-prem pour influencer la sélection du chemin.
Métriques Interconnect : utilisation par lien, erreurs CRC et disponibilité ; surveillez une utilisation soutenue > 60-70 % et les pics d’erreurs. Maintenez une capacité de réserve et des circuits diversifiés. Examinez les augmentations de latence avec les indicateurs de retransmissions et de mise en file d’attente.
Signaux de saturation en périphérie : une augmentation des retransmissions TCP, une latence accrue au 99e centile sans modification du code, des événements de débordement de port NAT et des alertes d’occupation de la file d’attente sont des avertissements précoces d’un impact imminent.

Méthodologie de dépannage, gestion des incidents et fiabilité proactive

Dépannage structuré de DNS à l’application :

Identifier le parcours utilisateur défaillant et la fenêtre temporelle ; rattacher à une région et à un chemin (public via LB, privé via VPC, ou hybride).
DNS :

Valider la résolution avec les journaux Cloud DNS, la sortie de dig et le comportement des politiques. Vérifier les conflits split-horizon et s’assurer que les politiques de transfert sont en vigueur.
Confirmer les TTL et les changements récents ; les caches obsolètes peuvent simuler des pannes.

Répartiteur de charge et périphérie :

Examiner les journaux de requêtes et de health-check. Corréler les pics de 5xx avec l’état des backends et les événements de déploiement. Pour L7, se fier aux journaux de requêtes plutôt qu’à traceroute.
Vérifier les listes d’autorisation des clients et les IP de health-check de Google dans les règles de pare-feu lorsque l’accès est restreint.

Routage et pare-feu :

Utiliser Connectivity Tests pour une évaluation déterministe du plan de contrôle. Inspecter les routes effectives et les politiques de pare-feu hiérarchiques. Rechercher le routage asymétrique et les règles masquées.
Pour les paquets refusés, se fier à la journalisation des règles de pare-feu ; envisager d’ajouter une règle de refus total journalisée vers le bas de la pile de priorité pendant les enquêtes.

Sortie vers les API Google :

Si les instances n’ont pas d’adresses IP externes, confirmer Private Google Access et/ou Cloud NAT. L’absence de l’un ou l’autre entraîne des échecs intermittents et des délais d’attente déroutants.

Hybride :

Examiner les métriques de Cloud Router et de VPN/Interconnect. Un BGP actif mais des routes non installées peuvent refléter des préférences d’attributs ; vérifier MED/local-pref et les ASN. Surveiller les pertes de paquets et les problèmes de MTU de chemin.

Preuves par paquets :

Si le plan de contrôle semble correct mais que les symptômes persistent, utiliser Packet Mirroring de manière ciblée pour collecter des PCAP près de la VM ou du niveau affecté ; vérifier la synchronisation SYN/SYN-ACK, les retransmissions et les bits MSS/DF pour les trous noirs MTU.

Gestion des incidents :

Sécurité des changements : déployer les changements par étapes en les limitant à des tags/comptes de service, avec une précédence plus faible et des règles désactivées ; activer la journalisation et tester avec des canaries. Utiliser le mode aperçu de Cloud Armor pour les changements de politique L7.
Rollback : prédéfinir les changements inverses, conserver les configurations précédentes dans un contrôle de version et utiliser des feature flags à courte durée de vie à la périphérie de l’application, le cas échéant.
Analyse post-incident : construire une chronologie à partir des journaux et des métriques, classifier les facteurs contributifs (par ex., règle permissive masquée par un refus, épuisement de NAT), enregistrer les lacunes de détection et ajouter des mesures de protection : alertes, vérifications NIC et renforcement des politiques.

Planification de la capacité et fiabilité proactive :

Suivre les objectifs de marge de manœuvre : 30–50 % sur les liens VPN/Interconnect, utilisation des ports NAT inférieure à 60 % en continu, CPU et QPS des backends de LB bien en dessous des déclencheurs d’autoscaling.
Créer des métriques basées sur les journaux pour les risques clés : pics de refus, débordement de NAT, nombre de flaps BGP, taux de 5xx et erreurs de connexion des backends de LB. Utiliser des alertes de taux de consommation (burn-rate) multi-fenêtres pour détecter les incidents rapides et lents.
Surveillance synthétique : utiliser les Uptime Checks depuis plusieurs régions pour les points d’accès publics et des sondes privées depuis des VM de test pour les services internes.
Améliorations préventives : affiner les règles de pare-feu à l’aide de Firewall Insights, résoudre les problèmes détectés par Network Analyzer, raccourcir l’agrégation des journaux de flux pendant les pics d’événements et exporter les journaux vers BigQuery pour la détection récurrente d’anomalies.

Scénario de problème pratique

Contoso Games exploite une API de jeu mondiale à charge répartie via HTTP(S) dans us-east1 et europe-west1, avec un VPN HA vers un centre de données sur site. Des utilisateurs en Europe signalent des délais d’attente intermittents et une latence plus élevée après un récent changement de pare-feu. Les instances n’ont pas d’adresses IP externes et doivent atteindre les API Google en privé.

Approche :

Établir la fenêtre temporelle et l’impact sur les SLO

Justification : La localisation de la fenêtre temporelle limite les requêtes aux journaux pertinents et aligne l’enquête sur les SLO impactant les utilisateurs. Une alerte de taux de consommation (burn-rate) confirme une consommation rapide du SLO dans europe-west1.

Valider le plan de contrôle avec Connectivity Tests

Justification : Créer un test depuis le frontend du répartiteur de charge HTTP(S) externe vers le service backend de europe-west1 et depuis les VM affectées vers un VIP de Private Google Access. Le test signale une politique de pare-feu hiérarchique bloquant les health checks vers certains backends et l’absence de Private Google Access pour un sous-réseau.

Confirmer l’état de la périphérie et des backends via les journaux

Justification : Filtrer les journaux de requêtes du répartiteur de charge pour europe-west1 et response_code >= 500 afin d’isoler les erreurs de backend. Les journaux de health-check montrent des échecs de sondes provenant d’adresses IP sources de health-check Google connues. Cela prouve un flapping des backends induit par le pare-feu plutôt que des régressions applicatives.

Rétablir l’état et assurer la sécurité avec des changements ciblés

Justification : Ajouter une règle d’autorisation ciblée sur les tags des backends qui autorise les plages sources des health-checks. Activer la journalisation sur cette règle. Comme l’accès est restreint à des clients connus, vérifier que la règle de pare-feu de la liste d’autorisation n’inclut que les plages d’IP client spécifiques et les plages de health-check. Garder la nouvelle règle initialement désactivée, puis l’activer pendant un déploiement canary à faible trafic pour limiter le rayon d’impact.

Rétablir la sortie privée vers les API Google

Justification : Activer Private Google Access sur le sous-réseau affecté pour que les instances sans IP externe atteignent les services Google sans hairpinning via le VPN ou des pare-feu tiers. Cela réduit la latence et supprime un point d’étranglement.

Vérifier la saturation et le MTU de la connexion hybride

Justification : Examiner les métriques du VPN HA pour les pertes de paquets et l’utilisation. Un tunnel montre des pertes élevées. Augmenter la capacité en ajoutant un deuxième tunnel vers une autre IP de pair sur site et répartir le trafic. Vérifier le MTU effectif et le MSS clamp pour éviter les trous noirs PMTU sur le chemin VPN.

Utiliser le mode aperçu de Cloud Armor pour les clients suspects d’abus

Justification : D’après les journaux de requêtes, un petit ensemble d’IP clientes provoque des pics de trafic juste avant les échecs de sondes. Ajouter une règle de refus dans Cloud Armor en mode aperçu pour valider que le blocage réduirait la charge du backend avant sa mise en application, évitant ainsi un impact accidentel sur les utilisateurs.

Utiliser Packet Mirroring de manière ciblée pour confirmer le comportement du plan de données

Justification : Miroiter le trafic d’une seule VM backend défaillante vers Cloud IDS pendant 15 minutes. Le PCAP montre un épuisement du backlog SYN pendant les rafales provenant des IP abusives, corroborant l’utilité de la politique Cloud Armor et la nécessité d’une limitation de débit.

Clore l’incident et renforcer la sécurité

Justification : Après avoir activé la règle d’autorisation pour les health-checks, confirmé Private Google Access, augmenté la capacité du VPN et appliqué la règle Cloud Armor validée, les taux d’erreur reviennent à la normale. Ajouter des tableaux de bord pour le taux de réussite des health-checks, l’utilisation des ports NAT, les pertes VPN et les 5xx par région. Créer des alertes basées sur les journaux pour les refus de pare-feu vers les tags de backend et des alertes de taux de consommation de SLO. Consigner l’incident, les causes profondes (changement de pare-feu hiérarchique ; trafic abusif ; saturation du VPN) et ajouter les vérifications de NIC Analyzer et Firewall Insights à la liste de contrôle pré-changement.

Cette séquence démontre un flux de travail sûr et basé sur des preuves : confirmer le plan de contrôle, observer le plan de données, appliquer des changements minimaux et réversibles, puis institutionnaliser les apprentissages avec des alertes et des vérifications automatisées.

← GKE · Tous les domaines · Automatisation du réseau →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →