Surveillance et alertes de production : le guide de configuration complet

L'incident de production moyen coûte 5 600 $ par minute d'arrêt. Les entreprises disposant d'une surveillance avancée détectent les problèmes en moins de 5 minutes, tandis que celles sans surveillance mettent en moyenne 197 minutes pour la détection - la différence entre un incident mineur et une catastrophe perdant un client.

This guide covers end-to-end production monitoring setup: what to measure, how to collect it, where to visualize it, and when to alert.

Points clés à retenir

• Les trois piliers de l'observabilité (métriques, logs, traces) répondent à des objectifs différents et tous les trois sont nécessaires
• Alerte sur les symptômes (taux d'erreur, latence) et non sur les causes (utilisation du CPU) pour réduire le bruit de 80%
• Les Runbooks joints à chaque alerte garantissent une réponse cohérente aux incidents, quelle que soit la personne d'astreinte
• Commencez avec 5 alertes essentielles et développez uniquement lorsque vous comprenez la ligne de base

---

Les trois piliers de l'observabilité

Métriques

Mesures numériques échantillonnées au fil du temps. Les métriques répondent « que se passe-t-il en ce moment ? »

Mesures d'application :

• Taux de requêtes (requêtes par seconde)
• Taux d'erreur (5xx réponses par seconde)
• Répartition des latences (P50, P95, P99)
• Sessions actives / utilisateurs simultanés

Mesures d'infrastructure :

• Utilisation du processeur par service
• Utilisation de la mémoire et garbage collection
• E/S disque et espace disponible
• Débit du réseau

Mesures commerciales :

• Commandes par minute
• Taux d'abandon de panier
• Revenu par heure
• Appels API par point de terminaison

Journaux

Enregistrements horodatés et structurés d’événements discrets. Les journaux répondent : « Pourquoi est-ce arrivé ? »

{
  "timestamp": "2026-03-16T14:32:01.234Z",
  "level": "error",
  "service": "api",
  "requestId": "req_abc123",
  "userId": "usr_456",
  "message": "Payment processing failed",
  "error": "Stripe API timeout after 30000ms",
  "endpoint": "POST /billing/checkout",
  "duration": 30142
}

Bonnes pratiques de journalisation :

• Utilisez la journalisation JSON structurée, pas le texte brut
• Inclure les ID de corrélation (requestId) entre les services
• Journaliser aux niveaux appropriés (ERREUR pour les échecs, WARN pour la dégradation, INFO pour les événements clés)
• N'enregistrez jamais de données sensibles (mots de passe, jetons, numéros complets de carte de crédit)

Traces

Chemins de requêtes de bout en bout via des systèmes distribués. Traces répond « où est le goulot d'étranglement ? »

Une demande d'utilisateur unique pour une caisse de commerce électronique peut toucher :

1. Nginx (2 ms) vers l'interface Next.js (50 ms) vers l'API NestJS (120 ms) vers PostgreSQL (45 ms) vers l'API Stripe (800 ms) vers le service de messagerie (200 ms)

Sans trace, vous voyez « le paiement prend 1,2 seconde ». Avec le traçage, vous voyez « L'API Stripe représente 67 % de la latence de paiement ».

---

Configuration de la pile de surveillance

Prometheus + Grafana (auto-hébergé)

# docker-compose.monitoring.yml
services:
  prometheus:
    image: prom/prometheus:v2.50.0
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus-data:/prometheus
    ports:
      - "9090:9090"
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=30d'
      - '--web.enable-lifecycle'

  grafana:
    image: grafana/grafana:10.3.0
    volumes:
      - grafana-data:/var/lib/grafana
    ports:
      - "3030:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=${GRAFANA_PASSWORD}
      - GF_USERS_ALLOW_SIGN_UP=false

  loki:
    image: grafana/loki:2.9.0
    volumes:
      - loki-data:/loki
    ports:
      - "3100:3100"

  alertmanager:
    image: prom/alertmanager:v0.27.0
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml
    ports:
      - "9093:9093"

volumes:
  prometheus-data:
  grafana-data:
  loki-data:

Configuration de Prometheus

# prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - "alerts/*.yml"

alerting:
  alertmanagers:
    - static_configs:
        - targets: ["alertmanager:9093"]

scrape_configs:
  - job_name: "api"
    metrics_path: /metrics
    static_configs:
      - targets: ["api:3001"]

  - job_name: "node-exporter"
    static_configs:
      - targets: ["node-exporter:9100"]

  - job_name: "postgres"
    static_configs:
      - targets: ["postgres-exporter:9187"]

  - job_name: "redis"
    static_configs:
      - targets: ["redis-exporter:9121"]

---

Métriques des applications NestJS

Exposer les métriques Prometheus

// metrics.module.ts
import { Module } from '@nestjs/common';
import { PrometheusModule } from '@willsoto/nestjs-prometheus';
import {
  makeCounterProvider,
  makeHistogramProvider,
  makeGaugeProvider,
} from '@willsoto/nestjs-prometheus';

@Module({
  imports: [
    PrometheusModule.register({
      path: '/metrics',
      defaultMetrics: { enabled: true },
    }),
  ],
  providers: [
    makeCounterProvider({
      name: 'http_requests_total',
      help: 'Total HTTP requests',
      labelNames: ['method', 'path', 'status'],
    }),
    makeHistogramProvider({
      name: 'http_request_duration_seconds',
      help: 'HTTP request duration in seconds',
      labelNames: ['method', 'path'],
      buckets: [0.01, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10],
    }),
    makeGaugeProvider({
      name: 'active_connections',
      help: 'Number of active connections',
    }),
  ],
  exports: [PrometheusModule],
})
export class MetricsModule {}

---

Configuration des alertes

Les cinq alertes essentielles

Chaque système de production a besoin de ces alertes dès le premier jour :

# alerts/essential.yml
groups:
  - name: essential
    rules:
      - alert: ServiceDown
        expr: up == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Service {{ $labels.job }} is down"
          runbook: "https://wiki.example.com/runbooks/service-down"

      - alert: HighErrorRate
        expr: |
          rate(http_requests_total{status=~"5.."}[5m])
          / rate(http_requests_total[5m]) > 0.01
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Error rate above 1% for 5 minutes"
          runbook: "https://wiki.example.com/runbooks/high-error-rate"

      - alert: HighLatency
        expr: |
          histogram_quantile(0.95,
            rate(http_request_duration_seconds_bucket[5m])
          ) > 2
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "P95 latency above 2 seconds"

      - alert: DiskSpaceLow
        expr: |
          node_filesystem_avail_bytes{mountpoint="/"}
          / node_filesystem_size_bytes{mountpoint="/"} < 0.2
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Disk space below 20% on {{ $labels.instance }}"

      - alert: SSLCertExpiringSoon
        expr: |
          probe_ssl_earliest_cert_expiry - time() < 14 * 24 * 3600
        labels:
          severity: warning
        annotations:
          summary: "SSL certificate expires within 14 days"

Routage des alertes

# alertmanager.yml
global:
  slack_api_url: "${SLACK_WEBHOOK_URL}"

route:
  group_by: ['alertname', 'severity']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'default'
  routes:
    - match:
        severity: critical
      receiver: 'pagerduty'
      repeat_interval: 15m
    - match:
        severity: warning
      receiver: 'slack'

receivers:
  - name: 'default'
    slack_configs:
      - channel: '#alerts'
        title: '{{ .GroupLabels.alertname }}'
        text: '{{ .CommonAnnotations.summary }}'

  - name: 'pagerduty'
    pagerduty_configs:
      - routing_key: "${PAGERDUTY_KEY}"
        severity: '{{ .GroupLabels.severity }}'

  - name: 'slack'
    slack_configs:
      - channel: '#alerts-warnings'
        title: '{{ .GroupLabels.alertname }}'

Règles de qualité des alertes

---

Tableaux de bord Grafana

Hiérarchie du tableau de bord

1. Tableau de bord de présentation : état de santé de haut niveau dans tous les services. C'est le premier écran que l'on regarde lors d'un incident.
2. Tableaux de bord des services : métriques détaillées pour chaque service (API, Web, Workers).
3. Tableaux de bord d'infrastructure : métriques au niveau du nœud (CPU, mémoire, disque, réseau).
4. Tableaux de bord commerciaux : revenus, commandes, activité des utilisateurs.

La méthode RED pour les tableaux de bord de service

Pour chaque prestation, affichez :

• Rate : requêtes par seconde
• Erreurs : taux d'erreur en pourcentage
• Duration : Répartition de la latence (P50, P95, P99)

Cela offre une visibilité instantanée sur l’état du service sans surcharge cognitive.

---

Suivi des erreurs avec Sentry

// sentry.config.ts
import * as Sentry from '@sentry/nestjs';

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.NODE_ENV,
  tracesSampleRate: 0.1,
  profilesSampleRate: 0.1,
  integrations: [
    Sentry.postgresIntegration(),
  ],
  beforeSend(event) {
    // Strip sensitive data
    if (event.request?.headers) {
      delete event.request.headers['authorization'];
      delete event.request.headers['cookie'];
    }
    return event;
  },
});

Sentry fournit :

• Regroupement automatique des erreurs et déduplication
• Empiler les traces avec les cartes sources
• Suivi des versions (quel déploiement a introduit l'erreur)
• Suivi des performances (traces des transactions)

---

Questions fréquemment posées

Combien coûte une pile de surveillance ?

Auto-hébergé (Prometheus + Grafana + Loki) : environ 50-100 $/mois pour les ressources d'hébergement. Alternatives gérées : Datadog commence à 15 $/hôte/mois pour l'infrastructure, plus 0,10 $/Go pour les journaux. Sentry Cloud coûte 26 $/mois pour le plan d'équipe. Un budget de départ raisonnable pour une petite entreprise est de 100 à 200 $/mois au total.

Quelle est la différence entre la surveillance et l'observabilité ?

La surveillance vous indique quand quelque chose ne va pas. L'observabilité vous dit pourquoi. La surveillance concerne des tableaux de bord prédéfinis et des alertes pour les modes de défaillance connus. L'observabilité concerne la capacité de poser des questions arbitraires sur le comportement de votre système à l'aide de métriques, de journaux et de traces. Vous avez besoin des deux, mais la surveillance est la base.

Comment éviter la fatigue des alertes ?

Trois règles : (1) chaque alerte doit nécessiter une action humaine, (2) définir des seuils basés sur des références réelles et non sur des idéaux théoriques, (3) examiner et ajuster les alertes mensuellement. Si une alerte se déclenche plus d'une fois par semaine sans nécessiter d'action, corrigez le problème sous-jacent ou augmentez le seuil. Les équipes souffrant de lassitude face aux alertes ignorent toutes les alertes, y compris les plus critiques.

Devrions-nous surveiller notre système ERP différemment ?

Les systèmes ERP ont des exigences de surveillance uniques. Au-delà des métriques Web standard, surveillez : l'utilisation du pool de connexions à la base de données, la profondeur de la file d'attente des tâches en arrière-plan, l'état de synchronisation de l'intégration (Shopify, passerelles de paiement), le temps d'exécution du rapport planifié et le nombre de sessions utilisateur par module. ECOSIRE fournit une surveillance Odoo gérée dans le cadre de nos packages de support.

---

Ce qui vient ensuite

La surveillance est les yeux et les oreilles de votre infrastructure de production. Associez-le à l'automatisation CI/CD pour un déploiement en toute confiance et à un plan de reprise après sinistre pour la résilience. Pour une feuille de route DevOps complète, consultez notre guide DevOps pour les petites entreprises.

Contactez ECOSIRE pour la surveillance de la configuration et des services d'infrastructure gérés.

---

Publié par ECOSIRE -- aide les entreprises à voir ce qui compte dans la production.