Monitoring : logs, alertes, uptime

Le pire moment pour apprendre que la prod est cassée, c'est par un client mécontent. Le monitoring, c'est savoir avant lui. Voici les trois couches que je mets en place : logs structurés, métriques, et des alertes qui ne crient pas pour rien.

Stacklogsmétriquesalertesuptimepino

Les trois couches

Le monitoring n'est pas un outil, c'est trois questions : qu'est-ce qui s'est passé (logs), comment se porte le système (métriques), et suis-je prévenu quand ça va mal (alertes) ?

logsle détail d’un événement précis, pour enquêter

métriquesdes chiffres agrégés dans le temps (latence, erreurs, CPU)

alertesune notification quand un seuil est franchi

uptimeun check externe : le site répond-il, vu de dehors ?

Des logs structurés

Un console.log en texte libre est illisible dès que le volume monte. Un log structuré (JSON) se filtre, se cherche et s'agrège — tu retrouves toutes les erreurs d'un user en une requête.

logger.tsTSCopier

import pino from "pino";
const log = pino();
// un log STRUCTURE (JSON) : filtrable, cherchable, agregeable
log.info({ userId, orgId, route: "/api/invoices", ms: 42 }, "invoice fetched");
log.error({ err, userId }, "invoice fetch failed");
// >> pas de console.log("truc " + x) : illisible a grande echelle

À retenir

Pour un agent IA, la même logique donne le traçage : chaque étape visible et cherchable, comme dans tracer et scorer un agent.

Des alertes utiles

Une alerte qui se déclenche trop souvent finit ignorée — c'est la fatigue d'alerte, et c'est pire que pas d'alerte du tout. On alerte sur des symptômes qui comptent pour l'utilisateur, pas sur chaque soubresaut technique.

Taux d’erreur

Le % de requêtes en 5xx dépasse un seuil : quelque chose est cassé, maintenant.

Latence

Le p95 explose : l'app rame pour une part réelle des utilisateurs.

Uptime externe

Un ping depuis l'extérieur toutes les minutes : le site répond-il vraiment ?

Saturation

Disque plein, connexions DB au max : les pannes annoncées, à prévenir avant le crash.

Par où commencer

·d'abord un simple uptime check externe + alerte : le minimum vital, en 5 minutes ;

·puis des logs structurés centralisés (CloudWatch, Grafana, Sentry pour les erreurs) ;

·enfin les métriques et un dashboard : latence, taux d'erreur, trafic ;

·un seul canal d'alerte clair (Slack, PagerDuty) — pas dix endroits à surveiller.

Attention

Ne monitore pas tout d'un coup. Un uptime check et une alerte sur le taux d'erreur couvrent déjà l'essentiel des pannes réelles.

Sources & ressources

01Google SRE Book — Monitoring Distributed SystemsLes quatre signaux d'or (latence, trafic, erreurs, saturation) et la règle « alerter sur les symptômes, pas les causes ».↗02Google SRE Workbook — Alerting on SLOsTransformer un SLO en alerte : burn rate, fenêtres multiples, budget d'erreur — la recette anti-fatigue d'alerte.↗03OpenTelemetry — Observability primerLa définition posée de logs, métriques, traces et spans, et pourquoi les corréler change tout en enquête.↗04Pino — Super fast, all natural JSON logger for Node.jsLa doc du logger utilisé dans l'exemple : sortie JSON, niveaux, child loggers, serializers, transports.↗05AWS — Using Amazon CloudWatch alarmsAlarmes métriques, log alarms et alarmes composites — ces dernières servent justement à réduire le bruit.↗06AWS — Synthetic monitoring (canaries) with CloudWatch SyntheticsLe check externe vu de dehors : un script qui rejoue le parcours client, jusqu'à une fois par minute.↗07Sentry — Alerts best practicesFiltres, déclencheurs, routage vers un canal : comment garder des alertes utiles et pas trop bruyantes.↗

En résumé

Le monitoring transforme les pannes de surprises en non-événements : tu es prévenu, tu as les logs pour comprendre, et tu corriges avant que ça se voie. Commence minimal — uptime + taux d'erreur — et enrichis. L'objectif n'est pas de tout voir, c'est de savoir avant le client.

Grafana — Getting started ↗

À lire ensuite

Guide

Coder un SaaS en 24h avec Claude Code

Du repo vide au produit en ligne en une journée : le plan, les raccourcis, et ce qui casse quand on va trop vite.

Technique

Les erreurs courantes avec Claude Code

Méga-prompts, pas de CLAUDE.md, jamais de tests, aucun commit : les pièges qui transforment l'agent en boulet.

Guide

Bien utiliser GitLab CI/CD

Un pipeline propre de bout en bout : stages, cache, artefacts, environnements et déploiement automatique.