Google PCD: Observabilité, débogage et opérations de fiabilité des sites — Guide d'étude

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Fait partie du Google Professional Cloud Developer — 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é, le débogage et les opérations de fiabilité des sites (SRE) dans Google Cloud visent à rendre les systèmes mesurables, diagnosticables et résilients. Une observabilité robuste requiert une journalisation et des métriques cohérentes, un traçage distribué, des alertes exploitables et une réponse aux incidents disciplinée. La fiabilité exige de la clarté sur les indicateurs et les objectifs de niveau de service (SLI/SLO), des signaux de santé rigoureux et une boucle de rétroaction qui transforme les informations de production en améliorations d’ingénierie. Cette section décrit comment mettre en place ces capacités de bout en bout dans Google Cloud et comment raisonner sur les compromis et les modes de défaillance courants.

Fondations de la journalisation et de la surveillance

Cloud Logging

Émettre des journaux structurés. Privilégiez le format JSON avec des noms de champs stables afin que les requêtes et les métriques basées sur les journaux restent robustes d’une version à l’autre. Incluez la sévérité, le nom du service, la version, l’emplacement et un ID de requête ou un contexte de trace pour la corrélation.
Corréler les journaux aux traces en définissant les champs :
- logging.googleapis.com/trace: projects/PROJECT_ID/traces/TRACE_ID
- logging.googleapis.com/spanId: SPAN_ID
- logging.googleapis.com/trace_sampled: true
Buckets et rétention. Le bucket _Default a généralement une rétention de 30 jours (configurable). Le bucket _Required contient certains journaux d’audit avec une rétention plus longue et fixe. Créez des buckets régionaux pour contrôler la résidence des données et définir une rétention personnalisée par bucket.
Collecteurs. Acheminez les journaux vers BigQuery pour l’analyse, vers Pub/Sub pour les consommateurs en streaming, ou vers Storage pour l’archivage. Utilisez des collecteurs agrégés au niveau du dossier ou de l’organisation pour capturer les projets enfants.
Requêtes. Utilisez le langage de requête de Logging pour filtrer par resource.type, labels, jsonPayload, httpRequest ou textPayload.

Exemples :

Entrée de journal structurée (abrégée) : { “severity”: “ERROR”, “message”: “Checkout failed”, “service”: “payments”, “version”: “2026-09-01”, “user_id_hash”: “9c1…”, “labels”: {“tenant”:“gold”}, “logging.googleapis.com/trace”: “projects/myproj/traces/4bf92f3577b34da6a3ce929d0e0e4736”, “logging.googleapis.com/spanId”: “00f067aa0ba902b7” }
Mettre à jour la rétention : gcloud logging buckets update _Default –location=global –retention-days=180
Créer un collecteur BigQuery pour les journaux d’erreurs : gcloud logging sinks create bq-errors
bigquery.googleapis.com/projects/myproj/datasets/log_analytics
–log-filter=‘severity>=ERROR’
Lire les erreurs 5xx récentes pour Cloud Run : gcloud logging read ‘resource.type=“cloud_run_revision” AND httpRequest.status>=500’ –limit=20

Cloud Monitoring

Métriques. Utilisez les métriques Google Cloud, les métriques personnalisées et les métriques basées sur les journaux. Privilégiez les libellés à faible cardinalité ; une explosion de la cardinalité des libellés entraîne des problèmes de coût et de latence des requêtes.
Tableaux de bord. Créez des tableaux de bord dédiés par service et par dépendance (base de données, cache, files d’attente). Visualisez les signaux RED (requêtes, erreurs, durée - requests, errors, duration) et USE (utilisation, saturation, erreurs - utilization, saturation, errors).
Règles d’alerte. Déclenchez sur des seuils, l’absence de métriques, des ratios, des taux de consommation de SLO (burn rates), ou des échecs de tests de disponibilité. Configurez les canaux de notification (e-mail, SMS, PagerDuty, Pub/Sub, webhooks). Supprimez les alertes intempestives (flapping) via le fenêtrage et les aligneurs.
Tests de disponibilité. Sondez depuis plusieurs régions ; utilisez des tests de disponibilité privés pour les points de terminaison internes ou exécutez des tests synthétiques depuis le VPC.

Métriques basées sur les journaux

Les compteurs résument les occurrences (par exemple, le nombre de requêtes /api/alpha/*).
Les distributions capturent la latence ou la taille des charges utiles.
Exemple : gcloud logging metrics create api_alpha_count
–description=“Nombre de requêtes /api/alpha/”
–log-filter=‘httpRequest.requestUrl=~"/api/alpha/." AND resource.type=“cloud_run_revision”’

Analyses opérationnelles

Pour une analyse ad hoc, acheminez les données vers BigQuery via un collecteur ; concevez des schémas et un partitionnement par horodatage pour maîtriser les coûts.
Utilisez Log Analytics dans les buckets de Logging pour agréger les données sans les exporter, le cas échéant.
Construisez des signaux de capacité à partir de métriques telles que le CPU, la mémoire, la profondeur des files d’attente, les connexions Cloud SQL, le CPU haute priorité de Spanner, les messages non confirmés (unacked) de Pub/Sub et les taux d’erreurs 429/5xx de Cloud Storage.

Pièges et compromis courants

La journalisation excessive augmente les coûts d’ingestion et masque les signaux importants ; privilégiez l’échantillonnage et une discipline de sévérité.
L’absence d’ID de corrélation entrave le tri des incidents ; propagez les ID de trace de bout en bout.
Une longue rétention dans les buckets “chauds” (hot) augmente les coûts ; exportez vers un archivage ou BigQuery pour les besoins à long terme.

Traçage, erreurs et diagnostics approfondis

Traçage distribué

Contexte de trace. Préférez le contexte de trace W3C (traceparent, tracestate). Pour l’interopérabilité avec Cloud Trace, continuez à prendre en charge x-cloud-trace-context : x-cloud-trace-context: TRACE_ID/SPAN_ID;o=1
Propagation. Propagez les en-têtes de trace à travers les services, les files d’attente de messages et les limites asynchrones ; capturez de nouveaux spans enfants lors d’appels RPC ou SQL. La perte de contexte brise les cartes de service et gonfle les nœuds de « service inconnu ».
Échantillonnage. Équilibrez le coût et la fidélité ; l’échantillonnage dynamique en amont (head-based) sur le trafic entrant et l’échantillonnage en aval (tail-based) pour les requêtes lentes rares peuvent améliorer l’utilité.

Cloud Trace

Fournit des histogrammes de latence, des cascades de spans et des cartes de service. Utilisez des annotations pour les sous-opérations critiques (RPC, requêtes de base de données).
Diagnostiquez les valeurs aberrantes à l’aide des traces p95/p99 ; surveillez le fan-out, les requêtes N+1 ou la contention de verrous.
Activez la corrélation trace-log pour que le clic sur une trace révèle ses journaux.

Error Reporting

Agrège automatiquement les exceptions par signature de pile par service/version. Configurez le contexte de service pour éviter la confusion entre les services. Supprimez les erreurs connues bruyantes ou dirigez-les vers des notifications de priorité inférieure.
Masquez les PII (informations personnelles identifiables) des messages d’exception ; journalisez plutôt des codes d’erreur stables et des ID de corrélation.

Cloud Profiler

Profilage continu du CPU/tas à faible surcharge pour les runtimes pris en charge. Comparez les profils entre les versions et les niveaux de trafic pour détecter les régressions. Évitez d’interpréter les artefacts d’échantillonnage comme des décomptes exacts.

Cloud Debugger

Les Snapshots capturent les variables à un emplacement du code sans interrompre le processus. Les Logpoints injectent des instructions de journalisation temporaires. Restreignez l’accès, masquez les variables sensibles et limitez la portée aux expressions ne contenant pas de PII.

Exemple court : ajouter un traceparent W3C et corréler un journal

Propagation HTTP : traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
Champ de journal pour lier à Cloud Trace : “logging.googleapis.com/trace”: “projects/myproj/traces/4bf92f3577b34da6a3ce929d0e0e4736”

Ingénierie de la fiabilité, alertes et signaux de santé

SLI, SLO, SLA et budgets d’erreur

Les SLI mesurent la satisfaction des utilisateurs : disponibilité, latence, exactitude. Définissez-les par point de terminaison critique et parcours utilisateur.
Les SLO fixent des objectifs, par ex., 99,9 % des requêtes en moins de 300 ms sur 30 jours.
Les budgets d’erreur quantifient la non-fiabilité admissible. Dépensez les budgets pour les déploiements, les expérimentations ou les migrations ; gelez les changements si le taux de consommation (burn rate) est trop élevé.
Les SLA sont des engagements externes ; maintenez le SLO plus strict que le SLA pour protéger la marge.

Conception d’alertes de qualité

Préférez les alertes basées sur les SLO et les symptômes plutôt que sur les causes lorsque c’est possible.
Utilisez des alertes multi-fenêtres et multi-taux de consommation (par exemple, 14x sur 5 minutes et 2x sur 1 heure) pour détecter les consommations rapides et lentes tout en réduisant le bruit.
Ajoutez l’absence de métrique pour les watchdogs (par ex., le signal de vie d’une tâche de longue durée).
Acheminez par sévérité ; limitez le débit des notifications ; fournissez des liens vers les runbooks et les tableaux de bord.

Vérifications de santé et sondes (probes)

Les sondes de préparation (readiness checks) bloquent le trafic jusqu’à ce que les dépendances soient prêtes ; les sondes de vivacité (liveness checks) déclenchent des redémarrages sur les processus bloqués ; les sondes de démarrage (startup probes) protègent les services à démarrage lent des redémarrages prématurés.
Pour les VM avec équilibrage de charge, autorisez les plages sources du vérificateur de santé, sinon le trafic n’atteindra jamais les backends : gcloud compute firewall-rules create allow-lb
–network prod –allow tcp
–source-ranges 130.211.0.0/22,35.191.0.0/16 –direction INGRESS
Exemple Kubernetes : readinessProbe: httpGet: { path: /ready, port: 8080 } periodSeconds: 5 failureThreshold: 3 livenessProbe: httpGet: { path: /healthz, port: 8080 } initialDelaySeconds: 30 periodSeconds: 10
Tests synthétiques. Utilisez les vérifications de disponibilité (uptime checks) et des flux de bout en bout sur mesure via Cloud Scheduler + Cloud Run/Functions pour valider la connexion, les paiements ou d’autres parcours critiques.
Surveillance des dépendances. Suivez la saturation des connexions à la base de données, les taux d’erreur RPC, les retards dans les files d’attente, les erreurs de sortie (egress) et les SLI des tiers. Configurez les nouvelles tentatives avec un backoff exponentiel tronqué pour les erreurs transitoires 429/5xx, avec des clés d’idempotence pour la sécurité.

Réponse aux incidents, débogage axé sur la sécurité et cause racine

Cycle de vie de la réponse aux incidents

Triage : classifier la gravité, désigner un responsable d’incident (incident commander) et alerter l’équipe d’astreinte via des canaux définis.
Contenir : appliquer les atténuations connues et les contrôles de trafic (rollback, canary, disjoncteur, limiteurs de débit).
Communiquer : maintenir une salle de crise (war room) interne, informer régulièrement les parties prenantes et publier un statut pour les utilisateurs si nécessaire.
Résoudre et restaurer : vérifier l’état via les SLI ; éviter de déclarer la fin de l’incident prématurément.
Post-mortem : analyser sans blâme la chronologie, les lacunes de détection, les facteurs contributifs et les actions à entreprendre avec des responsables et des dates d’échéance. Suivre jusqu’à la résolution.

Runbooks

Inclure les déclencheurs, le contexte requis, les commandes de diagnostic, les atténuations sûres, les étapes de rollback et les chemins d’escalade. Fournir des liens vers les tableaux de bord, les journaux et les playbooks pour des modes de défaillance spécifiques.

Surveillance des quotas et de la capacité

Surveiller les quotas de service via les métriques de Cloud Monitoring. Automatiser les alertes à 70-80 % d’utilisation et demander des augmentations à l’avance pour les tests de charge ou les lancements planifiés.
Signaux de capacité à suivre : CPU, mémoire, descripteurs de fichiers, pools de threads, connexions à la base de données, limites de l’autoscaler et profondeur de la file d’attente des requêtes.

Débogage sans exposer d’informations sensibles

Caviarder les secrets et les informations personnelles identifiables (PII) à la source ; centraliser les secrets dans Secret Manager. Utiliser le hachage ou la tokenisation pour les identifiants utilisateur. Activer le caviardage au niveau des champs dans le middleware de journalisation.
Limiter l’accès aux journaux, aux traces et aux outils de débogage via IAM ; utiliser CMEK et VPC Service Controls le cas échéant.
Dans Debugger, désactiver la collecte de grands graphes d’objets et ajouter des conditions pour éviter de capturer des trames sensibles.

Analyse de la cause racine à travers les couches

Exécution (Runtime) : corréler les pics de GC, de pools de threads ou de CPU via Profiler avec la latence p99 dans Trace.
Réseau : inspecter les journaux du répartiteur de charge, les VPC Flow Logs, les journaux de pare-feu et les Connectivity Tests pour valider les chemins. Les échecs de vérification de l’état résultent souvent de règles de pare-feu manquantes ou de ports incorrects.
IAM : examiner les Cloud Audit Logs pour les refus d’autorisation ou les changements de politique ; confirmer les rôles de compte de service et les portées des jetons.
Données : utiliser Cloud SQL Insights, les statistiques de requêtes Spanner, l’utilisation CPU et les tablettes chaudes (hot tablets) de Bigtable, ainsi que les taux d’erreur de Storage pour trouver les points chauds. Appliquer des nouvelles tentatives avec backoff pour les pannes transitoires et réduire le fan-out qui amplifie la latence de queue.
Relier le tout avec des ID de trace corrélés et des métriques basées sur les journaux ; exporter vers BigQuery pour exécuter des jointures multi-sources lors de l’analyse post-incident.

Scénario de problème pratique

Fjord Retail migre un processus de paiement multi-services vers Google Cloud en utilisant Cloud Run, Cloud SQL, Pub/Sub et une API de taxes externe. Les utilisateurs signalent des délais d’attente intermittents et des taux d’erreur en dents de scie lors des ventes flash, et l’équipe d’astreinte reçoit des alertes bruyantes et peu informatives.

Approche :

Instrumenter la journalisation structurée avec corrélation de traces

Ajouter la propagation traceparent W3C à travers les services et inclure logging.googleapis.com/trace dans tous les journaux. Justification : la corrélation de bout en bout permet aux ingénieurs de passer d’une requête utilisateur lente à l’RPC ou à la requête lente exacte et à ses journaux.

Créer des buckets, une rétention et des exportations Logging

Augmenter la rétention de _Default à 90 jours et créer un bucket régional pour les charges de travail de l’UE. Ajouter un récepteur agrégé vers BigQuery pour les journaux de niveau ERROR et WARNING :

undefined

Justification : une rétention à chaud suffisante facilite le débogage ; BigQuery permet une analyse rapide des incidents sans augmenter les coûts de stockage à chaud. 3) Définir les SLI/SLO et les alertes basées sur les SLO

SLI de disponibilité : requêtes réussies / total. SLI de latence : durée p95 pour POST /checkout.
SLO : 99,9 % de disponibilité mensuelle ; 95 % des paiements en < 300 ms.
Configurer des alertes de taux d’épuisement (burn rate) multi-fenêtres et une alerte d’absence de métrique pour le heartbeat du processus de paiement. Justification : les alertes basées sur les symptômes réduisent le bruit et n’alertent que lorsqu’il y a un impact sur l’utilisateur.

Configurer des sondes d’état et des vérifications synthétiques

Les services Cloud Run exposent /ready et /healthz. Ajouter un test de disponibilité global pour /checkout et une tâche synthétique privée dans le VPC qui effectue un paiement complet avec des identifiants de test. Justification : la sonde de préparation (readiness) empêche les backends froids de recevoir du trafic ; les tests synthétiques détectent les problèmes de bout en bout et les régressions des tiers.

Activer Cloud Trace et Profiler, et adopter les nouvelles tentatives avec backoff

Installer les agents Trace/Profiler le cas échéant ; activer l’instrumentation automatique du client HTTP et l’annotation des spans SQL. Implémenter un backoff exponentiel tronqué avec des clés d’idempotence pour les appels à l’API de taxes. Justification : le traçage isole les contributeurs à la latence ; le backoff réduit l’amplification des erreurs 429/5xx et protège les budgets d’erreur.

Surveiller la capacité et les quotas

Ajouter des tableaux de bord et des alertes pour les connexions Cloud SQL, le CPU, le pool de tampons InnoDB, les messages non confirmés (unacked) de Pub/Sub, la simultanéité de Cloud Run et l’utilisation des quotas de service. Justification : la saturation de la capacité est une cause cachée fréquente de la latence de queue ; les alertes précoces préviennent les pannes.

Renforcer le débogage pour la confidentialité

Utiliser des ID utilisateur hachés et exclure les PII des messages d’erreur. Restreindre Debugger à la production avec des règles de caviardage et des logpoints uniquement. Justification : maintenir l’observabilité tout en respectant la minimisation des données.

Mettre en place des moniteurs de dépendances et des disjoncteurs

Suivre le taux de réussite et la latence de l’API de taxes externe via des métriques personnalisées ; déclencher un disjoncteur pour utiliser des taux de taxes mis en cache lorsque les échecs dépassent un seuil. Justification : isoler les défaillances des dépendances tierces et maintenir la disponibilité du processus de paiement principal.

Préparer les runbooks et les chemins d’escalade

Documenter les étapes : vérifier les tableaux de bord SLO, inspecter la carte de service Trace pour les arêtes chaudes, examiner Cloud SQL Insights pour les requêtes lentes, vérifier le pare-feu et les vérifications de l’état, et évaluer la marge de quota. Inclure les procédures de rollback et de canary. Justification : une réponse cohérente et rapide réduit le MTTR et évite les modifications ad-hoc risquées.

Pipeline d’analyse post-incident

Utiliser les exportations BigQuery pour calculer les taux d’erreur par locataire et pour corréler les journaux avec les traces et les informations de Cloud SQL par ID de trace. Justification : un historique durable et interrogeable permet des analyses de cause racine précises et des mesures préventives.

Ce plan améliore la qualité du signal, raccourcit le temps de détection et de résolution, protège l’expérience utilisateur lors des pics de charge et garantit la confidentialité lors du débogage en production.

← Livraison continue · Tous les domaines · Performance →

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