Bien que Logging, Monitoring et Error Reporting fassent tous partie de la suite d’observabilité de Google Cloud, chacun remplit un rôle distinct et se concentre sur un aspect différent de la santé et des performances de vos applications.

Vue d’ensemble

📋 Cloud Logging

Ce service est le journal intime de votre système. Il collecte, stocke et analyse les données de logs et les événements provenant de vos services Google Cloud, de vos applications, et même de vos ressources sur site (on-premises).

Les logs sont des enregistrements horodatés d’événements discrets, comme une connexion utilisateur, une transaction en base de données, ou une erreur applicative.

Fonctionnalités

• Stocker et rechercher des logs — Consultez des entrées individuelles, filtrez-les selon différents critères (heure, sévérité, type de ressource) et utilisez le langage de requête LQL pour retrouver des événements spécifiques. Le Logs Explorer est l’interface principale pour cela.
• Déboguer et résoudre des problèmes — Les logs fournissent des informations détaillées sur ce qui s’est passé et pourquoi, ce qui est essentiel pour identifier la cause racine d’un incident.
• Audit et sécurité — Les logs capturent les activités administratives et les accès aux données, indispensables pour les pistes d’audit et la surveillance de la sécurité.
• Créer des métriques basées sur les logs — Extrayez des données numériques à partir des logs pour créer des métriques personnalisées.

📊 Cloud Monitoring

Ce service assure une observation continue de la santé et des performances de votre système dans le temps. Il collecte des métriques — des données numériques mesurées à intervalles réguliers, comme l’utilisation du CPU, la latence des requêtes ou le trafic réseau — depuis vos ressources et applications Google Cloud.

Fonctionnalités

• Visualiser les performances — Créez des tableaux de bord personnalisés avec des graphiques pour suivre les métriques clés et identifier des tendances ou des anomalies. Le Metrics Explorer est l’outil dédié à l’analyse et à la représentation graphique de ces données.
• Détecter les problèmes — En configurant des alertes, vous êtes notifié dès qu’une métrique dépasse un seuil prédéfini (ex. : utilisation CPU supérieure à 80 % pendant une certaine durée).
• Comprendre la santé du système — Obtenez une vue d’ensemble de votre infrastructure et des performances applicatives pour identifier proactivement les problèmes potentiels.
• Vérifications de disponibilité et monitoring synthétique — Ces fonctionnalités vérifient la disponibilité et les performances de vos services depuis différentes zones géographiques.

🚨 Cloud Error Reporting

Ce service est spécialisé dans l’identification et l’agrégation des erreurs applicatives. Il analyse automatiquement les logs (souvent ceux ingérés par Cloud Logging) pour détecter les exceptions, et regroupe les erreurs similaires entre elles.

Fonctionnalités

• Prioriser les erreurs — Met en évidence les nouvelles erreurs ou celles qui surviennent avec une fréquence élevée, afin de concentrer vos efforts sur les problèmes les plus impactants.
• Agréger et analyser les crashs — Compte, analyse et regroupe les crashs de vos services cloud en production, en fournissant des informations sur le nombre d’occurrences, les versions affectées et les stack traces détaillées.
• Recevoir des notifications — Configurez des alertes pour être averti dès que de nouveaux types d’erreurs apparaissent.
• Accélérer le débogage — En regroupant les erreurs et en fournissant du contexte, il aide les développeurs à comprendre et corriger rapidement les défaillances applicatives.

Les alertes

Une alerte est une règle automatique qui surveille une condition et déclenche une notification lorsque cette condition est satisfaite. Dans le contexte de Cloud Error Reporting, il en existe deux types :

• Alerte sur nouvelle erreur — déclenchée dès qu’un groupe d’erreurs jamais vu auparavant est détecté. C’est le type d’alerte natif d’Error Reporting, activable directement depuis la console sans configuration avancée.
• Alerte sur fréquence d’erreurs — déclenchée lorsque le nombre d’occurrences d’une erreur dépasse un seuil sur une période donnée (ex. : plus de 50 erreurs en 5 minutes). Ce type repose sur une métrique basée sur les logs acheminée vers Cloud Monitoring (voir section suivante).

Une politique d’alerte dans Cloud Monitoring se compose de trois éléments :

Bonnes pratiques

Une alerte bien configurée répond à une question précise et actionnable. Quelques bonnes pratiques :

• Alerter sur du nouveau, pas sur du connu — une erreur connue et déjà suivie n’a pas besoin de générer une alerte à chaque occurrence. Utilisez les alertes sur nouveaux groupes pour détecter les régressions.
• Accompagner chaque alerte d’un runbook — le champ documentation d’une politique d’alerte doit contenir un lien vers la procédure à suivre, pas seulement un message générique.
• Calibrer les seuils — une alerte qui se déclenche trop souvent est ignorée (alert fatigue). Commencez par des seuils larges, puis affinez en fonction du volume réel d’erreurs de votre service.
• Distinguer urgence et information — une erreur critique en production mérite un canal synchrone (PagerDuty, SMS) ; une dégradation lente peut se contenter d’un e-mail ou d’un message dans un chat d’équipe.

Logs structurés & métriques

C’est ici que les trois services cessent d’être des outils parallèles pour former un pipeline cohérent.

Logs structurés

Les logs structurés sont simplement des logs écrits en JSON plutôt qu’en texte brut. Plutôt que :

ERROR: request failed for user 99, latency 320ms

Vous émettez :

{
  "severity": "ERROR",
  "message": "request failed",
  "userId": 99,
  "latencyMs": 320
}

La différence essentielle est que Cloud Logging peut indexer et interroger chaque champ individuellement. Dans le Logs Explorer, vous pouvez filtrer sur jsonPayload.userId = 99 ou jsonPayload.latencyMs > 500 directement. Avec du texte brut, vous seriez limité à de la recherche par chaîne de caractères, bien moins puissante.

Les logs structurés permettent aussi à Cloud Logging de reconnaître des champs réservés spéciaux comme severity, httpRequest, trace et spanId, qu’il utilise pour enrichir automatiquement l’entrée de log.

Métriques basées sur les logs

Les métriques basées sur les logs sont des métriques dérivées directement des logs. Elles constituent le principal point d’intégration entre Cloud Logging et Cloud Monitoring. Il en existe deux types :

• Métriques compteur — comptent le nombre d’entrées de log correspondant à un filtre donné dans le temps. Exemple : compter toutes les entrées où severity = ERROR
• Métriques de distribution — extraient une valeur numérique d’un champ de log structuré et suivent sa distribution statistique dans le temps. Exemple : extraire jsonPayload.latencyMs de chaque log de requête et suivre les percentiles (p50, p95, p99)

Une fois définies, ces métriques apparaissent dans Cloud Monitoring comme n’importe quelle métrique native. Vous pouvez les représenter sur des tableaux de bord, créer des alertes dessus et les interroger dans le Metrics Explorer.

🔁 En résumé

Ces trois services sont distincts mais profondément intégrés, et les logs structurés sont la matière première qui alimente l’ensemble de la chaîne.

• Cloud Logging fournit la donnée brute → ce qui s’est passé
• Cloud Monitoring surveille la santé globale du système → est-ce que quelque chose ne va pas en ce moment ?
• Cloud Error Reporting se concentre sur les erreurs applicatives → quelles erreurs surviennent, et à quelle fréquence ?
• Les logs structurés sont le carburant de tout le pipeline → plus vos logs sont structurés, plus les trois services deviennent puissants
• Les métriques basées sur les logs sont le pont entre Logging et Monitoring → transformez n’importe quel champ de vos logs en signal de monitoring de premier ordre
• Le Log Router + Log Sink permettent de router vos logs vers n’importe quelle destination → Pub/Sub, BigQuery, Cloud Storage, ou un système externe comme ClickUp via une Cloud Function

Le pipeline complet

La conclusion pratique est la suivante : si votre application écrit des logs en texte brut non structuré, vous n’utilisez Cloud Logging que comme un simple outil de recherche. Mais si vous écrivez des logs JSON structurés avec des champs numériques significatifs, vous débloquez le pipeline complet jusqu’aux tableaux de bord et alertes de Monitoring — sans avoir besoin d’instrumenter votre application avec une librairie de métriques séparée.

Votre application
  └─► émet des logs JSON structurés
        └─► Cloud Logging (stockage, indexation, requêtes)
              ├─► Cloud Error Reporting (lit les logs, regroupe les exceptions)
              └─► Métriques basées sur les logs
                    └─► Cloud Monitoring (tableaux de bord, alertes)

⚙️ Log Router, Sinks & Cloud Function

Écrire des logs structurés

Sur Cloud Run, écrire des logs structurés est aussi simple qu’écrire du JSON sur stdout — Cloud Logging l’ingère et l’indexe automatiquement, aucune librairie requise.

// Sur Cloud Run : écrire sur stdout suffit
const log = (severity, message, extra = {}) => {
  process.stdout.write(JSON.stringify({
    severity, // champ réservé, reconnu nativement par Cloud Logging
    message,  // champ réservé, affiché en résumé dans le Logs Explorer
    ...extra,
  }) + '\n');
};

// Utilisation
log('INFO', 'Requête reçue', {
  service: 'api-gateway',
  userId: 'usr_8a3f',
  latencyMs: 145,
});

log('ERROR', 'Paiement échoué', {
  service: 'payment',
  orderId: 'ord_7c2d',
  reason: 'card_declined',
});

Les champs severity et message sont reconnus nativement. Tout autre champ (ici service, userId, latencyMs) devient immédiatement interrogeable dans le Logs Explorer via jsonPayload.latencyMs > 500 ou jsonPayload.reason = "card_declined".

Le Log Router

Le Log Router est le moteur de routage central de Cloud Logging. Il traite chaque entrée de log à son arrivée et l’évalue contre l’ensemble des sinks configurés pour décider où la copier.

Points clés :

• Chaque entrée est évaluée contre tous les sinks simultanément — un même log peut être envoyé à plusieurs destinations en parallèle
• Le routage est basé sur des filtres LQL (ex. : severity >= ERROR, resource.type = "cloud_run_revision")
• Les logs non capturés par un sink restent quand même dans le bucket _Default de Cloud Logging — un sink est une copie, pas un déplacement

Les Log Sinks

Un Log Sink est une règle composée de deux éléments :

1. Un filtre LQL — quels logs capturer
2. Une destination — où les envoyer

Example d’automatisation

Pour illustrer comment ces services s’articulent concrètement, voici un exemple de bout en bout : chaque fois qu’une erreur survient dans une application Cloud Run, une notification est automatiquement envoyée dans le chat d’équipe ClickUp. Aucune intervention manuelle, aucun scraping de logs — le pipeline réagit en temps réel. Le schéma ci-dessous montre le chemin complet parcouru par l’événement, des étapes détaillées suivent ensuite.

Votre app Cloud Run
  └─► log structuré { severity: "ERROR", ... }
        └─► Cloud Logging
              └─► Log Router
                    └─► Log Sink  (filtre : severity >= ERROR)
                          └─► Pub/Sub Topic  [error-notifications]
                                └─► Cloud Function  [notifyClickUp]
                                      └─► ClickUp API
                                            └─► message dans le chat de l'équipe

Étape 1 — Pub/Sub & Log Sink

# 1. Créer le topic Pub/Sub
gcloud pubsub topics create error-notifications

# 2. Créer le Log Sink pointant vers ce topic
gcloud logging sinks create error-to-pubsub \
  pubsub.googleapis.com/projects/MON_PROJET/topics/error-notifications \
  --log-filter='severity >= ERROR AND resource.type = "cloud_run_revision"'

# 3. Récupérer le compte de service généré par GCP pour ce sink
gcloud logging sinks describe error-to-pubsub \
  --format='value(writerIdentity)'
# → serviceAccount:pXXXXX-YYYY@gcp-sa-logging.iam.gserviceaccount.com

# 4. Accorder le rôle publisher à ce compte de service
gcloud pubsub topics add-iam-policy-binding error-notifications \
  --member='serviceAccount:WRITER_IDENTITY_ICI' \
  --role='roles/pubsub.publisher'

Étape 2 — La Cloud Function

const functions = require('@google-cloud/functions-framework');

functions.cloudEvent('notifyClickUp', async (cloudEvent) => {
  // 1. Décoder le message Pub/Sub (encodé en base64)
  const pubsubData = cloudEvent.data.message.data;
  const logEntry = JSON.parse(Buffer.from(pubsubData, 'base64').toString());

  // 2. Extraire les informations pertinentes du log
  const severity  = logEntry.severity || 'UNKNOWN';
  const message   = logEntry.jsonPayload?.message
                 || logEntry.textPayload
                 || 'Aucun message';
  const service   = logEntry.resource?.labels?.service_name || 'service inconnu';
  const timestamp = logEntry.timestamp
                  ? new Date(logEntry.timestamp).toLocaleString('fr-FR', { timeZone: 'Europe/Paris' })
                  : new Date().toLocaleString('fr-FR', { timeZone: 'Europe/Paris' });

  // Champs custom de vos logs structurés
  const orderId   = logEntry.jsonPayload?.orderId  || null;
  const reason    = logEntry.jsonPayload?.reason   || null;

  // 3. Formater le message ClickUp
  const lines = [
    `🚨 **[${severity}]** \`${service}\``,
    `📝 ${message}`,
    orderId ? `🔖 Commande : \`${orderId}\`` : null,
    reason  ? `❌ Raison : ${reason}`         : null,
    `🕐 ${timestamp}`,
  ].filter(Boolean).join('\n');

  // 4. Envoyer vers le chat ClickUp
  const viewId   = process.env.CLICKUP_VIEW_ID;
  const apiToken = process.env.CLICKUP_API_TOKEN;

  const response = await fetch(
    `https://api.clickup.com/api/v2/view/${viewId}/comment`,
    {
      method: 'POST',
      headers: {
        'Authorization': apiToken,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        comment_text: lines,
        notify_all: true,
      }),
    }
  );

  if (!response.ok) {
    console.error(JSON.stringify({
      severity: 'ERROR',
      message: 'Échec de l\'envoi vers ClickUp',
      status: response.status,
    }));
  }
});

Étape 3 — Déploiement

Le token ClickUp ne doit jamais être en dur dans le code. Stockez-le dans Secret Manager et injectez-le comme variable d’environnement au déploiement.

# Créer le secret dans Secret Manager
gcloud secrets create clickup-api-token \
  --replication-policy="automatic"

# Ajouter la valeur du token (remplacez par votre token ClickUp)
echo -n "pk_VOTRE_TOKEN_CLICKUP" | \
  gcloud secrets versions add clickup-api-token --data-file=-

# Déployer la Cloud Function (2ème génération)
gcloud functions deploy notifyClickUp \
  --gen2 \
  --runtime=nodejs20 \
  --region=europe-west1 \
  --trigger-topic=error-notifications \
  --entry-point=notifyClickUp \
  --set-env-vars="CLICKUP_VIEW_ID=VOTRE_VIEW_ID" \
  --set-secrets="CLICKUP_API_TOKEN=clickup-api-token:latest"

ID de la vue ClickUp

Le view_id se trouve directement dans l’URL lorsque vous ouvrez votre vue Chat dans ClickUp :

https://app.clickup.com/{workspace_id}/v/li/{view_id}

Ces trois services forment ensemble une suite d’observabilité complète. En adoptant les logs structurés dès le départ et en tirant parti du Log Router pour connecter vos logs à des systèmes externes, vous transformez une simple infrastructure de journalisation en un pipeline d’alerte et de notification entièrement automatisé.