Google ACE: Surveillance, journalisation et dépannage opérationnel — Guide d'étude

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Fait partie du Google Associate Cloud 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’excellence opérationnelle sur Google Cloud dépend de la conversion de la télémétrie en actions. La surveillance (Monitoring), la journalisation (Logging) et le dépannage (Troubleshooting) fournissent ensemble les signaux, les garde-fous et les workflows qui maintiennent la fiabilité des services. Cette section couvre les services d’observabilité de base, les outils de diagnostic, les pratiques de fiabilité et les opérations d’incident, avec la logique de conception, les compromis et les modes de défaillance courants.

Fondations de la surveillance et des alertes

Cloud Monitoring ingère des séries temporelles provenant des services Google Cloud, d’agents et de métriques personnalisées pour fournir des tableaux de bord, des vérifications de disponibilité, des SLO et des alertes.

Métriques et cardinalité
- Les types de ressources surveillées (par exemple, gce_instance, aws_ec2_instance, global) définissent la portée des dimensions comme le projet, la région et l’ID d’instance.
- Minimisez les valeurs de libellés non bornées (par exemple, user_id) pour éviter les explosions de haute cardinalité qui ralentissent les requêtes et augmentent les coûts.
- Préférez les métriques de distribution pour la latence (p50/p90/p99) et utilisez des fenêtres d’alignement pour des agrégations cohérentes.
Tableaux de bord
- Utilisez les tableaux de bord de service intégrés pour des démarrages rapides. Créez des tableaux de bord personnalisés pour regrouper les métriques inter-projets. Organisez les panneaux par symptôme (latence, erreurs, saturation) avant la cause (CPU, mémoire).
- Évitez les graphiques par instance pour les flottes ; agrégez par service, zone ou MIG pour réduire le bruit et augmenter le signal.
Règles d’alerte
- Concevez des alertes basées sur les symptômes et liées à l’expérience utilisateur : consommation du SLO de disponibilité, centiles de latence, taux d’erreur. Utilisez des alertes à fenêtres multiples et à taux de consommation multiples pour détecter la consommation rapide et lente (par exemple, 2 % sur 1 heure et 5 % sur 5 minutes).
- Définissez des limites de taux de notification et des comportements de clôture automatique raisonnables. Utilisez des annotations d’atténuation automatique des incidents pour documenter les runbooks.
- Utilisez des alertes d’absence de métrique pour les tâches batch critiques et les pipelines de données avec des planifications strictes.
- Les métriques basées sur les journaux prennent en charge les alertes pour les événements applicatifs ou de sécurité (par exemple, des permissionDenied répétés).
Canaux de notification
- Configurez les canaux par sévérité : astreinte pour SEV1 (on-call, SMS, téléphone), chat pour SEV2/3, e-mail ou webhooks pour les priorités basses. Utilisez Pub/Sub pour l’intégration avec la billetterie ou l’automatisation.
- Testez les canaux périodiquement ; les canaux obsolètes sont un mode de défaillance silencieux.
Vérifications de disponibilité et surveillance synthétique
- Les vérifications HTTP(S) et TCP depuis des points d’observation mondiaux vérifient la joignabilité externe. Associez les vérifications à une correspondance de contenu pour détecter les défaillances partielles.
- Utilisez des vérifications de disponibilité privées via une connectivité hybride ou Private Service Connect pour les services internes.
- Modes de défaillance : les vérifications peuvent échouer en raison de la latence du TTL DNS, de problèmes de rotation de certificats TLS ou de pannes à l’échelle d’une région ; corroborez avec les métriques avant de déclencher une astreinte.
Surveillance multi-projets
- Utilisez un espace de travail Monitoring unique et liez tous les projets pour des tableaux de bord et des alertes consolidés. Cela simplifie les SLO à l’échelle de la flotte et réduit la duplication.

Journalisation, audit et diagnostic applicatif

Cloud Logging est le routeur de journaux, le plan de stockage et de requêtage pour les journaux de la plateforme et des applications. Les outils APM complémentaires (Error Reporting, Trace, Profiler) accélèrent l’isolation de la cause racine.

Routage des journaux, buckets, récepteurs et rétention
- Routez avec des récepteurs vers des buckets de journaux (par défaut ou personnalisés), BigQuery (analytique), Pub/Sub (traitement en flux continu) ou Cloud Storage (archivage).
- Utilisez des buckets de journaux à portée régionale pour la résidence des données et la performance. Appliquez une CMEK si la conformité l’exige.
- Définissez la rétention par bucket (par exemple, 30 à 90 jours pour les opérations, plusieurs années pour l’audit). Une rétention plus longue augmente les coûts ; filtrez agressivement pour maîtriser les dépenses.
- Les exclusions réduisent l’ingestion de journaux verbeux (par exemple, les vérifications de santé). Validez les filtres pour éviter de supprimer involontairement des journaux critiques.
Exemple : créer un récepteur BigQuery pour les journaux d’audit

undefined

Exemple : créer une exclusion

undefined

Requêtes et l’explorateur de journaux
- Utilisez des filtres avancés sur resource.type, severity, les libellés et les charges utiles JSON. Enregistrez les requêtes pour les chemins de triage courants (échecs de démarrage, permissionDenied, quotaExceeded).
- Créez des métriques basées sur les journaux de type distribution et compteur pour les alertes et les tableaux de bord.
Cloud Audit Logs
- Journaux d’audit sur l’activité d’administration : toujours activés, ingestion sans frais ; enregistrent les opérations d’écriture administratives (par exemple, createInstance).
- Journaux d’audit sur l’accès aux données : enregistrent les opérations de lecture et d’écriture du plan de données (par exemple, storage.objects.get). Désactivés par défaut pour de nombreux services ; activez-les sélectivement car le volume et le coût peuvent être élevés.
- Journaux d’audit des événements système : actions du système Google (par exemple, autoscaler, migration à chaud de maintenance).
- Journaux de refus de règles : enregistrements explicites des refus de règles IAM et d’organisation. Cruciaux pour le dépannage des accès et les revues de sécurité.
- Routez les journaux d’audit vers BigQuery pour la rétention et l’investigation ; indexez les libellés tels que authenticationInfo.principalEmail pour les attributions.
Error Reporting, Trace et Profiler
- Error Reporting regroupe automatiquement les traces de pile par service et version ; intégrez-le avec les canaux de notification pour les nouveaux groupes d’erreurs et les pics soudains.
- Cloud Trace collecte les distributions de latence des requêtes et les spans ; réglez l’échantillonnage pour équilibrer la surcharge et la fidélité (par exemple, 1 sur 1000 pour les services à haut QPS, avec un échantillonnage basé sur la queue de distribution si vous utilisez des collecteurs OpenTelemetry).
- Profiler fournit un profilage continu du CPU/tas à faible surcharge en production. Limitez-le aux chemins critiques ou aux charges de travail représentatives pour contrôler le volume de données et la surcharge. Utilisez le mappage de source pour des graphes d’appels lisibles.
- Compromis : un échantillonnage plus élevé améliore les diagnostics mais augmente les coûts et l’exposition potentielle de données personnelles ; nettoyez les champs sensibles et utilisez la tokenisation.

Dépannage des services, des ressources et du réseau

Un dépannage efficace part des symptômes pour remonter aux limites du système, puis aux ressources et à leurs dépendances.

Santé des services gérés, état des services, quotas, incidents régionaux
- Validez si un incident est en amont : vérifiez la santé du service et les avis régionaux récents. Recherchez les pics d’erreurs, une latence élevée ou des erreurs de quota.
- Les quotas sont par projet et souvent par région ; quotaExceeded et rateLimitExceeded dans les journaux indiquent une limitation (throttling). Demandez des augmentations avant les événements de forte charge.
- Mode de défaillance : des pannes régionales partielles peuvent apparaître comme des erreurs intermittentes ; configurez le basculement multi-régional lorsque c’est possible.
Santé des ressources et diagnostics des VM
- Utilisez les opérations sur les instances, les événements de maintenance et les vérifications de santé (health checks). Pour les MIGs, inspectez les redémarrages de l’autoréparation (autohealing) et les échecs des vérifications de santé pour isoler les images ou les configurations défectueuses.
- Console série de la VM pour les messages de démarrage et du noyau :
  - gcloud compute connect-to-serial-port VM_NAME –zone=ZONE
  - Causes courantes : kernel panics, mauvaises entrées fstab bloquant le démarrage, configurations réseau incorrectes, mauvaise configuration de OS Login entraînant des échecs SSH.
- Assurez l’utilisation de OS Login avec des clés SSH par utilisateur et des rôles IAM (compute.osLogin ou compute.osAdminLogin) pour un accès attribuable.
Logs Explorer pour l’analyse des défaillances
- Commencez par les journaux de symptômes (5xx, deadlineExceeded), pivotez par étiquettes de ressource, puis corrélez avec les changements de déploiement et les journaux de quota. Utilisez les vues en histogramme pour localiser les points de changement.
Observabilité du réseau
- VPC Flow Logs : échantillonnage par VNIC du trafic 5-tuple ; à activer sur les sous-réseaux. Ajustez l’échantillonnage (par exemple, 0.5) et les options de métadonnées pour trouver un équilibre entre performance et détail.
  - gcloud compute networks subnets update SUBNET –region=REGION –enable-flow-logs –flow-sampling=0.5 –aggregation-interval=interval-5-min –metadata=include-all
- Journalisation du pare-feu : capturez les décisions d’autorisation/refus (allow/deny) sur les règles critiques pour diagnostiquer les blocages inattendus ou les règles masquées (shadowing).
  - gcloud compute firewall-rules update RULE_NAME –enable-logging
- Connectivity Tests : modélisez et vérifiez la joignabilité à travers les VPC, le peering, Cloud VPN, Cloud Interconnect et les règles de pare-feu. Utile pour la validation avant modification et le tri des incidents.
  - gcloud network-management connectivity-tests create test-a –source-instance=projects/PRJ/zones/ZONE/instances/VM1 –destination-ip=10.0.3.21 –protocol=TCP –destination-port=443
- Signaux complémentaires : journaux de Cloud NAT et des répartiteurs de charge (load balancers) pour les problèmes de sortie (egress) et de périphérie (edge). Les modes de défaillance incluent le routage asymétrique, les routes manquantes, les règles de pare-feu mal ordonnées et les contraintes de stratégie.

Fiabilité, SLO et Opérations d’Incident

La discipline opérationnelle lie la télémétrie aux objectifs d’impact sur l’utilisateur et à une exécution cohérente des incidents.

SLO, budgets d’erreur et lignes de base
- Définir des SLO sur des SLI centrés sur l’utilisateur (disponibilité, latence, exactitude). Exemple : 99,9 % des requêtes de lecture se terminent en moins de 200 ms sur 30 jours.
- Suivre les budgets d’erreur et concevoir des tableaux de bord consolidés par service et par version de release. Conditionner les déploiements à la consommation du budget.
- Établir des lignes de base de performance avant les montées en charge du trafic ; les régressions sont détectées par l’écart, et non par des valeurs absolues.
Réduction du bruit des alertes
- Préférer les alertes au niveau du service plutôt qu’au niveau de l’instance. Utiliser des conditions basées sur le taux de changement et les percentiles. Appliquer la limitation des notifications, la clôture automatique des incidents et la mise en sourdine des alertes pour les fenêtres de maintenance.
- Dédoublonner les alertes via des étiquettes et des politiques communes ; utiliser un routage tenant compte des dépendances pour éviter de contacter l’astreinte à la fois pour la base de données et l’application pour le même incident.
Flux de travail de réponse aux incidents
- Triage et déclaration de la sévérité ; assigner les rôles (commandant d’incident, opérations, communications, scribe).
- Chemins d’escalade : rotations d’astreinte, experts du domaine et support fournisseur (inclure l’ID de projet, les ID de requête, les horodatages et les régions dans les tickets de support).
- Communication : maintenir une source unique de vérité (canal de discussion et document d’incident). Fournir des mises à jour périodiques aux parties prenantes avec l’impact, la mitigation et les ETA.
- Playbooks de mitigation : rollback, failover, désactivation de feature flag ou ajout de capacité. Préférer les changements réversibles avec un faible rayon d’impact.
Revue post-incident et RCA (Analyse de cause racine)
- Basée sur les preuves : corréler les métriques, les journaux, les traces et les événements de changement. Inclure quels signaux de détection se sont déclenchés, pourquoi ou pourquoi pas, et le temps de détection/mitigation.
- Identifier les facteurs contributifs, pas seulement la cause immédiate. Capturer des actions concrètes avec des responsables et des échéances ; mettre à jour les runbooks et les alertes en conséquence.
- Une culture sans blâme encourage la divulgation complète et les corrections systémiques.
Runbooks opérationnels
- Structure : déclencheur et détection, arbre de diagnostic rapide, mitigations sûres, étapes de rollback/restauration, vérification et critères de sortie.
- Garder les commandes et les filtres prêts à être copiés-collés ; vérifier l’IAM de moindre privilège pour les intervenants (par exemple, storage.objectCreator pour les sauvegardes en écriture seule ; comptes de service dédiés pour l’identité de la charge de travail).
- Versionner les runbooks avec une gestion du changement ; les tester pendant les game days.

Scénario de Problème Pratique

Northwind Outfitters exploite une plateforme de e-commerce régionale sur Google Cloud. Après un récent pic de trafic, les utilisateurs signalent par intermittence des délais d’attente dépassés lors du paiement et des recherches de produits lentes. L’équipe des opérations doit rapidement restaurer la fiabilité, réduire le bruit des alertes et renforcer les diagnostics sur plusieurs projets.

Approche :

Consolider la surveillance sur l’ensemble des projets

Action : Créer un unique espace de travail Monitoring et y lier les projets prod, payments et search. Construire un tableau de bord « Parcours Utilisateur » montrant la disponibilité, la latence et les taux d’erreur pour le paiement et la recherche.
Justification : La visibilité centralisée facilite le triage au niveau du service et la corrélation des problèmes inter-services (par exemple, la latence de la recherche se répercutant en délais d’attente dépassés lors du paiement).

Mettre en œuvre des SLO et des alertes sur le taux de consommation (burn rate)

Action : Définir des SLO : 99,9 % des paiements en moins de 400 ms, 99,95 % des recherches en moins de 250 ms. Créer des alertes de consommation sur plusieurs fenêtres (2 % sur 1 heure et 5 % sur 5 minutes) sur les SLI de latence et de taux d’erreur. Notifier l’astreinte par paging, les parties prenantes par chat.
Justification : Les alertes sur le taux de consommation détectent les régressions rapides et les dégradations lentes et soutenues sans déclencher d’alertes sur la variance normale.

Ajouter des vérifications de disponibilité synthétiques avec correspondance de contenu

Action : Configurer des vérifications de disponibilité TCP et HTTPS pour les points d’entrée publics et une vérification de disponibilité privée pour l’API de paiement interne, en validant que le corps de la réponse contient « ok ».
Justification : Détecte l’accessibilité et les défaillances partielles comme des backends mal routés ou des services en amont dégradés.

Resserrer les routes et la rétention des journaux

Action : Créer des buckets de journaux dédiés : ops (90 jours), security-audit (2 ans, CMEK). Router les journaux Admin Activity, Data Access, System Event et Policy Denied vers BigQuery via des récepteurs (sinks) pour l’analyse. Ajouter des exclusions pour les vérifications de santé verbeuses.
Justification : Une rétention bien dimensionnée contrôle les coûts ; BigQuery permet des analyses forensiques rapides. Les exclusions réduisent le bruit sans perdre de preuves critiques.

Activer les diagnostics applicatifs

Action : Instrumenter les services avec OpenTelemetry pour Trace ; activer Error Reporting pour le backend et le frontend ; déployer Profiler sur le service de paiement avec des profils CPU et de tas (heap) à un échantillonnage conservateur.
Justification : Les traces identifient les points chauds de latence ; Error Reporting met en évidence les nouveaux groupes d’erreurs ; Profiler révèle la contention CPU et les fuites de mémoire avec une faible surcharge.

Renforcer l’observabilité du réseau

Action : Activer les VPC Flow Logs sur les sous-réseaux de prod (échantillonnage de 0,5, inclure toutes les métadonnées) et la journalisation du pare-feu sur les règles allow/deny pour l’entrée vers les services de recherche et de paiement. Créer des Connectivity Tests depuis le niveau web vers la recherche et depuis les paiements vers Cloud SQL.
Justification : Les journaux de flux et de pare-feu exposent les pertes de paquets, les retransmissions et les règles masquées ; les Connectivity Tests valident l’accessibilité et identifient les erreurs de configuration.

Diagnostics au niveau des ressources et accès sécurisé

Action : Pour les VM instables, inspecter les problèmes de démarrage avec la console série :

undefined

Si le SSH est requis, imposer OS Login et accorder compute.osAdminLogin au groupe « ops-admins ». Chaque administrateur utilise sa propre clé SSH.
Justification : Les journaux de la console série révèlent les défaillances du noyau et de l’initialisation. OS Login avec des clés par utilisateur garantit un accès attribuable et de moindre privilège.

Vérification des quotas et de la santé régionale

Action : Examiner les événements quotaExceeded récents dans les journaux ; augmenter les quotas régionaux d’API et d’adresses IP pour l’autoscaling de la recherche. Consulter les avis sur l’état de santé du service pour la région impactée ; dévier temporairement le trafic avec la pondération du load balancer.
Justification : L’étranglement par les quotas et les incidents régionaux sont des sources courantes de défaillances intermittentes ; une mise à l’échelle proactive et une gestion du trafic en atténuent l’impact.

Réduction du bruit et mises à jour des runbooks

Action : Remplacer les alertes CPU par instance par des alertes de saturation au niveau du service. Ajouter des fenêtres de maintenance pour mettre en sourdine les alertes non actionnables. Mettre à jour les runbooks avec de nouvelles requêtes de triage, des tableaux de bord de traces et des procédures de rollback.
Justification : Réduit la fatigue liée aux astreintes et accélère les réponses cohérentes et sûres.

Revue post-incident et actions

Action : Mener une revue sans blâme. Corréler les incidents de consommation de budget d’erreur avec une augmentation de la latence de queue de la recherche et un récent déploiement d’index. Actions à entreprendre : ajouter des déploiements canary pour la recherche, des garde-fous sur la taille de l’index et une marge de manœuvre pour l’autoscaler ; s’engager à effectuer des tests périodiques des canaux d’alerte.
Justification : Une RCA basée sur les preuves prévient la récurrence et améliore la détection, la mitigation et la résilience.

← Déploiement · Tous les domaines · Sécurité →

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