L'observabilité qui aide a 3h du matin : Logs, Traces et Ce Qui Compte Vraiment

Les Trois Piliers Sont Faux

Chaque talk sur l'observabilité commence par "les trois piliers : logs, métriques et traces." Ce cadrage est incomplet. Il te dit quoi collecter mais pas quoi en faire. La vraie question a 3h du matin n'est pas "est-ce que j'ai des logs ?" C'est "est-ce que je peux trouver la seule ligne de log qui explique pourquoi la commande de ce client a échoué, a travers 7 services, en moins de 2 minutes ?"

On fait tourner des systemes de production avec plusieurs services, des workers en arriere-plan, des files de messages et des pipelines IA. Cet article couvre ce qui aide réellement quand les choses cassent. Pour les patterns d'implémentation OpenTelemetry, consulte notre guide OpenTelemetry. Pour l'observabilité spécifique a l'IA, consulte notre guide d'observabilité IA.

Logs Structurés : Le Format Qui Te Sauve

Les logs non structurés sont inutiles a grande échelle. console.log('Processing order ' + orderId) devient du bruit dans un systeme qui produit 10 000 lignes de log par minute.

Les logs structurés sont interrogeables, filtrables et alertables :

// Non structuré (inutile a grande échelle)
console.log('Processing order 12345 for customer sara@beispiel.de');

// Structuré (interrogeable, sans PII)
logger.info('order_processing_started', {
    order_id: 'ord_12345',
    customer_id: 'cust_abc',  // ID, pas l'email
    channel: 'web',
    tenant_id: 'tenant_acme',
    items_count: 3,
    total_cents: 15900,
});

Discipline des Niveaux de Log

La production devrait tourner au niveau info. Le debug génere trop de volume. Les error et warn devraient toujours déclencher une revue (si ce n'est pas une alerte).

Pas de PII dans les Logs

Ton agrégateur de logs (Datadog, CloudWatch, Loki, Elasticsearch) indexe tout. Si les logs contiennent des emails, des noms ou des numéros de téléphone, ton infrastructure de logs devient régulée par le RGPD.

// Mauvais : PII dans les logs
logger.info('Email sent to sara.mustermann@beispiel.de about order 12345');

// Bon : uniquement des IDs
logger.info('notification_sent', {
    recipient_id: 'cust_abc',
    notification_type: 'order_confirmation',
    order_id: 'ord_12345',
    channel: 'email',
});

Pour l'architecture complete de protection des PII, consulte notre guide de prévention des fuites de données.

Correlation IDs : Tracer une Requete a Travers les Services

Une seule requete utilisateur peut toucher un API gateway, un service d'authentification, un service produit, un service de paiement, un worker de notifications et un indexeur de recherche. Sans correlation ID, trouver toutes les entrées de log pour une requete nécessite de deviner les timestamps et de faire du grep.

// Génerer au point d'entrée (API gateway ou premier service)
const correlationId = crypto.randomUUID();

// Propager a travers chaque service via les headers
const response = await httpClient.post('/api/orders', body, {
    headers: { 'X-Correlation-Id': correlationId },
});

// Inclure dans chaque entrée de log
logger.info('order_created', {
    correlation_id: correlationId,
    order_id: order.id,
    tenant_id: ctx.tenantId,
});

// Inclure dans chaque message envoyé aux files
await queue.add('send_confirmation', {
    orderId: order.id,
    correlationId,
});

Quand tu debugs, fais une requete par correlation ID :

correlation_id = "a1b2c3d4-e5f6-7890-abcd-ef1234567890"

Chaque entrée de log de chaque service pour cette requete apparait. La chaine complete est visible. C'est l'outil de debug le plus impactant dans les systemes distribués.

Fatigue d'Alertes : Moins d'Alertes, de Meilleures Alertes

L'approche par défaut : alerter sur tout. Taux d'erreur > 0 ? Alerte. Latence > 500ms ? Alerte. Profondeur de file > 10 ? Alerte. Le résultat : 200 alertes par jour, toutes ignorées.

Principes de Conception des Alertes

Niveaux d'Alertes

L'objectif : les alertes P1 se déclenchent moins d'une fois par semaine. Si elles se déclenchent quotidiennement, elles sont soit mal configurées, soit ton systeme a des problemes de fiabilité fondamentaux.

Gestion des Couts

L'observabilité coute cher. L'ingestion de logs, le stockage de métriques, la rétention de traces et l'hébergement de dashboards s'additionnent vite.

Réduire le Volume de Logs Sans Perdre le Signal

// Ne pas logger chaque health check
if (req.path === '/health' || req.path === '/ready') {
    return next(); // Passer le logging
}

// Échantillonner les opérations verbeuses
if (req.path.startsWith('/api/search') && Math.random() > 0.1) {
    ctx.skipLogging = true; // Logger seulement 10% des requetes de recherche
}

// Toujours logger les erreurs, événements métier et requetes lentes
logger.info('request_completed', {
    path: req.path,
    status: res.statusCode,
    duration_ms: duration,
    // Inclure les champs détaillés uniquement pour les requetes lentes ou en erreur
    ...(duration > 1000 || res.statusCode >= 400 ? {
        query_params: sanitize(req.query),
        response_size: res.contentLength,
    } : {}),
});

Le Modele de Maturité de l'Observabilité

La plupart des équipes sont a L1-L2. L3 (correlation IDs) est la plus grande amélioration individuelle. L4 (bon alerting) prévient le burnout. L5 est ambitieux mais atteignable.

Erreurs Courantes

1. Logs non structurés. console.log avec concaténation de chaines, c'est du bruit a grande échelle. Utilise du JSON structuré avec des champs typés.

2. PII dans les logs. Ton agrégateur de logs devient régulé par le RGPD. Logge des IDs, pas des valeurs.

3. Alerter sur tout. 200 alertes par jour signifie zéro alerte lue. Classe les alertes par sévérité et impact métier.

4. Labels de métriques a haute cardinalité. Utiliser des IDs utilisateur ou des IDs de requete comme labels de métriques crée des millions de séries temporelles. Utilise des labels bornés (code de statut, endpoint, tenant).

5. Pas de correlation IDs. Sans eux, debugger une requete a travers 7 services nécessite de deviner les timestamps et de prier.

6. Pas d'échantillonnage de logs. Logger chaque health check et chaque requete de recherche a pleine verbosité double ta facture de logs. Échantillonne les opérations verbeuses, logge toujours les erreurs.

7. Pas de budget de couts pour l'observabilité. La dépense d'observabilité devrait représenter 5 a 15% de la dépense d'infrastructure. Suis-la. Optimise-la.

8. Des dashboards que personne ne regarde. Si un dashboard n'a pas été consulté depuis 30 jours, supprime-le. La prolifération de dashboards ajoute du cout et de la confusion.

Points Clés

• Les logs structurés ne sont pas négociables. Du JSON avec des champs typés. Interrogeable, filtrable, alertable. Jamais de concaténation de chaines.

• Les correlation IDs sont l'outil de debug le plus impactant. Génere-les au point d'entrée, propage-les a travers chaque service et chaque file. Fais une requete par correlation ID pour voir la chaine de requete complete.

• Pas de PII dans les logs. Jamais. Logge des IDs clients, pas des emails clients. Logge des IDs de commande, pas des contenus de commande. Ton infrastructure de logs ne doit pas devenir une responsabilité en matiere de protection des données.

• Moins d'alertes, de meilleures alertes. Les alertes P1 devraient se déclencher moins d'une fois par semaine. Chaque alerte doit etre actionnable. Inclus l'impact métier dans le message d'alerte.

• Budgétise ton observabilité. Le volume de logs, la cardinalité des métriques, l'échantillonnage des traces et les politiques de rétention impactent tous les couts. Suis la dépense d'observabilité en pourcentage de la dépense d'infrastructure.

On intégre l'observabilité dans chaque systeme que l'on déploie, que ce soit nos services IA, notre infrastructure cloud ou notre développement logiciel sur mesure. Si tu as besoin d'aide avec l'observabilité en production, échange avec notre équipe ou demande un devis.