Prometheus et Alertmanager 2026 : Monitoring et Alerting Sécurité

Les équipes sécurité font face à un défi croissant : surveiller des infrastructures de plus en plus distribuées, détecter les anomalies en temps réel et déclencher des alertes pertinentes sans noyer les équipes sous des faux positifs. Selon le rapport CISA 2025, 67 % des incidents de sécurité majeurs auraient pu être détectés plus tôt grâce à un monitoring adéquat. Prometheus et Alertmanager constituent aujourd'hui la combinaison de référence pour répondre à ce besoin, adoptée par des milliers d'organisations à travers le monde. Ce guide complet vous explique comment déployer une stack de monitoring sécurité complète : architecture Prometheus, installation Docker Compose, configuration des exporters orientés sécurité, écriture de règles d'alerte critiques, intégration avec Slack, PagerDuty et Teams, tableaux de bord Grafana et détection d'anomalies. Que vous administriez un datacenter on-premise ou une infrastructure cloud hybride, vous trouverez ici les éléments concrets pour construire une supervision robuste et actionnable.

Architecture Prometheus : le modèle pull et la base de données time-series

Prometheus se distingue fondamentalement des solutions de monitoring traditionnelles par son modèle pull : c'est Prometheus qui va interroger périodiquement les cibles (targets) pour récupérer leurs métriques, et non l'inverse. Cette approche présente des avantages considérables en matière de sécurité. D'abord, elle centralise les droits de connexion sur le serveur Prometheus : les cibles n'ont pas besoin d'ouvrir des connexions sortantes vers un serveur central, ce qui simplifie les règles de pare-feu. Ensuite, si une cible est compromise ou disparaît du réseau, Prometheus le détecte immédiatement via l'état "down" — une information précieuse pour la détection d'incidents.

Au cœur de Prometheus se trouve une base de données de séries temporelles (TSDB) optimisée pour le stockage et la requête de métriques horodatées. Chaque métrique est identifiée par un nom et un ensemble de labels (paires clé-valeur) qui permettent une granularité extrême. Par exemple, http_requests_total{method="POST", status="401", instance="web-01"} capture précisément les requêtes POST ayant retourné une erreur d'authentification sur le serveur web-01.

PromQL (Prometheus Query Language) est le langage de requête natif. Il permet d'agréger, filtrer et transformer des métriques avec une expressivité remarquable. Un opérateur sécurité peut en quelques lignes calculer le taux d'erreurs 401 sur les 5 dernières minutes, détecter une augmentation anormale du trafic réseau ou identifier des connexions TCP établies au-delà d'un seuil habituel.

L'écosystème d'exporters est l'autre force de Prometheus. Ces processus légers exposent des métriques au format Prometheus depuis des systèmes tiers : serveurs Linux, bases de données, équipements réseau, applications métier. Prometheus scrape régulièrement ces exporters (toutes les 15 secondes par défaut) et stocke les données localement. La rétention par défaut est de 15 jours, configurable selon les besoins. Pour des durées plus longues, des solutions comme Thanos ou Cortex permettent de stocker les métriques dans un stockage objet (S3, GCS) pour des rétentions de plusieurs années — utile pour la conformité et les analyses forensiques.

Du point de vue sécurité, l'architecture Prometheus s'intègre parfaitement dans une stratégie de défense en profondeur. Elle complète un SIEM en fournissant des métriques d'infrastructure en temps réel, là où le SIEM se concentre sur les logs et les événements de sécurité. La combinaison des deux approches offre une visibilité complète : logs structurés d'un côté, métriques numériques de l'autre.

Installation Docker Compose : stack complète en 15 minutes

Docker Compose est la méthode la plus rapide pour déployer une stack Prometheus complète en environnement de développement ou de production légère. Le fichier suivant déploie Prometheus, Alertmanager, Grafana et Node Exporter dans un réseau Docker isolé.

Créez un répertoire de travail et placez-y les fichiers suivants :

mkdir -p /opt/monitoring/{prometheus,alertmanager,grafana}
cd /opt/monitoring

Fichier docker-compose.yml :

version: '3.8'

networks:
  monitoring:
    driver: bridge

volumes:
  prometheus_data: {}
  grafana_data: {}
  alertmanager_data: {}

services:
  prometheus:
    image: prom/prometheus:v2.51.0
    container_name: prometheus
    restart: unless-stopped
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml
      - ./prometheus/rules/:/etc/prometheus/rules/
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--storage.tsdb.retention.time=30d'
      - '--web.enable-lifecycle'
      - '--web.enable-admin-api'
      - '--web.external-url=http://monitoring.exemple.interne:9090'
    ports:
      - "127.0.0.1:9090:9090"
    networks:
      - monitoring
    depends_on:
      - alertmanager

  alertmanager:
    image: prom/alertmanager:v0.27.0
    container_name: alertmanager
    restart: unless-stopped
    volumes:
      - ./alertmanager/alertmanager.yml:/etc/alertmanager/alertmanager.yml
      - alertmanager_data:/alertmanager
    command:
      - '--config.file=/etc/alertmanager/alertmanager.yml'
      - '--storage.path=/alertmanager'
      - '--web.external-url=http://monitoring.exemple.interne:9093'
    ports:
      - "127.0.0.1:9093:9093"
    networks:
      - monitoring

  grafana:
    image: grafana/grafana:10.4.0
    container_name: grafana
    restart: unless-stopped
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=ChangeMe2026!
      - GF_USERS_ALLOW_SIGN_UP=false
      - GF_SERVER_ROOT_URL=http://monitoring.exemple.interne:3000
      - GF_SMTP_ENABLED=false
    volumes:
      - grafana_data:/var/lib/grafana
    ports:
      - "127.0.0.1:3000:3000"
    networks:
      - monitoring
    depends_on:
      - prometheus

  node-exporter:
    image: prom/node-exporter:v1.7.0
    container_name: node-exporter
    restart: unless-stopped
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - '--path.procfs=/host/proc'
      - '--path.sysfs=/host/sys'
      - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)'
    ports:
      - "127.0.0.1:9100:9100"
    networks:
      - monitoring

  blackbox-exporter:
    image: prom/blackbox-exporter:v0.25.0
    container_name: blackbox-exporter
    restart: unless-stopped
    volumes:
      - ./prometheus/blackbox.yml:/etc/blackbox_exporter/config.yml
    ports:
      - "127.0.0.1:9115:9115"
    networks:
      - monitoring

Points de sécurité importants dans cette configuration : toutes les interfaces sont liées à 127.0.0.1 uniquement, ce qui empêche l'exposition directe sur Internet. L'accès externe se fait via un reverse proxy Nginx avec authentification. Le mot de passe Grafana doit être changé immédiatement en production. La rétention est fixée à 30 jours pour couvrir les besoins d'analyse forensique courante.

Configuration prometheus.yml : scrape configs et targets

Le fichier prometheus.yml est le cœur de la configuration Prometheus. Il définit les intervalles de collecte, les cibles à surveiller et les règles d'alerte à charger.

global:
  scrape_interval: 15s
  evaluation_interval: 15s
  scrape_timeout: 10s
  external_labels:
    environment: 'production'
    datacenter: 'dc-paris-01'

alerting:
  alertmanagers:
    - static_configs:
        - targets:
          - alertmanager:9093

rule_files:
  - '/etc/prometheus/rules/*.yml'

scrape_configs:
  # Prometheus lui-meme
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  # Node Exporter - metriques systeme Linux
  - job_name: 'node-exporter'
    static_configs:
      - targets:
        - 'node-exporter:9100'
        - '192.168.1.10:9100'
        - '192.168.1.11:9100'
    relabel_configs:
      - source_labels: [__address__]
        target_label: instance

  # Blackbox Exporter - surveillance TLS et HTTP
  - job_name: 'blackbox-http'
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
        - https://www.exemple.fr
        - https://api.exemple.fr
        - https://admin.exemple.fr
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: blackbox-exporter:9115

  - job_name: 'blackbox-tls'
    metrics_path: /probe
    params:
      module: [tcp_connect]
    static_configs:
      - targets:
        - exemple.fr:443
        - api.exemple.fr:443
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: blackbox-exporter:9115

  # MySQL Exporter
  - job_name: 'mysql'
    static_configs:
      - targets: ['192.168.1.20:9104']

  # Nginx Exporter
  - job_name: 'nginx'
    static_configs:
      - targets: ['192.168.1.10:9113']

Le paramètre external_labels est crucial en environnement multi-datacenter ou multi-cluster : il permet d'identifier la source des métriques dans Alertmanager et dans Grafana. L'evaluation_interval contrôle la fréquence d'évaluation des règles d'alerte — 15 secondes est un bon compromis entre réactivité et charge CPU.

Exporters orientés sécurité : ce qu'il faut surveiller

Le choix et la configuration des exporters déterminent la qualité du monitoring sécurité. Voici les exporters les plus pertinents et ce qu'ils apportent concrètement.

Node Exporter est l'exporter de référence pour les systèmes Linux. Il expose des centaines de métriques couvrant CPU, mémoire, disque, réseau et système de fichiers. Pour la sécurité, les métriques les plus intéressantes sont : node_netstat_Tcp_CurrEstab (connexions TCP établies — indicateur précoce de DDoS ou de scan réseau), node_network_receive_bytes_total et node_network_transmit_bytes_total (trafic réseau — exfiltration de données), node_filesystem_avail_bytes (espace disque — un disque saturé peut empêcher l'enregistrement des logs de sécurité), node_entropy_available_bits (entropie système — utile pour détecter une activité cryptographique anormale) et node_cpu_seconds_total (charge CPU — minage de cryptomonnaies détectable par une charge anormalement élevée).

Blackbox Exporter est indispensable pour surveiller les certificats TLS. Il teste la disponibilité HTTP/HTTPS depuis l'extérieur et expose la métrique probe_ssl_earliest_cert_expiry qui donne la date d'expiration du certificat TLS en timestamp Unix. Cette métrique permet de déclencher une alerte 30 jours avant l'expiration — évitant les incidents de type "certificat expiré" qui ont causé des interruptions majeures chez de nombreuses organisations ces dernières années. Il surveille également le code de retour HTTP, le temps de réponse et la validité de la chaîne de certificats.

MySQL Exporter expose des métriques critiques pour détecter des comportements anormaux en base de données : mysql_global_status_threads_connected (connexions actives — tentative de saturation), mysql_global_status_aborted_connects (connexions échouées — tentatives d'authentification infructueuses), mysql_global_status_queries (volume de requêtes — détection d'injection SQL volumétrique). Pour l'installer sur votre serveur MySQL, créez un utilisateur dédié avec des droits minimaux : CREATE USER 'prometheus'@'localhost' IDENTIFIED BY 'motdepasse_fort'; GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'prometheus'@'localhost';

Nginx Exporter lit le stub_status de Nginx et expose : le nombre de connexions actives, les connexions en attente, les requêtes traitées. Couplé aux logs Nginx parsés par un agent comme Promtail ou le module nginx_log_exporter, il permet de calculer le taux d'erreurs 4xx/5xx par endpoint — indicateur de tentatives d'exploitation ou de scan de vulnérabilités.

Fail2ban Exporter est un outil moins connu mais précieux pour les serveurs exposés. Il expose le nombre de bans actifs par jail (f2b_banned_ip_count{jail="sshd"}, f2b_banned_ip_count{jail="nginx-http-auth"}), permettant de détecter une augmentation soudaine des bans — signe d'une attaque par force brute en cours.

Windows Exporter (anciennement WMI Exporter) couvre les systèmes Windows. Il expose notamment windows_logon_logon_type (types de connexions — connexions réseau suspectes), les événements du journal de sécurité Windows et les métriques IIS. Ces données sont complémentaires à ce que peut détecter un outil comme Wazuh SIEM/XDR au niveau des logs.

PromQL pour la sécurité : requêtes pratiques

PromQL est à Prometheus ce que SQL est aux bases de données relationnelles. La maîtrise de quelques patterns essentiels suffit pour construire des alertes et des dashboards sécurité efficaces.

Connexions TCP établies anormalement élevées :

node_netstat_Tcp_CurrEstab > 5000

Cette requête simple retourne les instances dont le nombre de connexions TCP établies dépasse 5000. La valeur seuil dépend de votre infrastructure — établissez une baseline sur 2 semaines avant de configurer l'alerte.

Taux d'erreurs 401 en augmentation :

rate(nginx_http_requests_total{status="401"}[5m]) > 10

La fonction rate() calcule le taux par seconde sur une fenêtre glissante. Plus de 10 erreurs 401 par seconde sur 5 minutes indique une tentative d'authentification par force brute ou un scraper malveillant.

Charge CPU suspecte :

100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90

Une charge CPU supérieure à 90% sur 5 minutes peut indiquer un minage de cryptomonnaies ou l'exécution d'un ransomware en phase de chiffrement. Couplé à une alerte sur l'I/O disque, ce pattern est redoutablement efficace.

Espace disque critique :

(node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 10

Prédiction d'épuisement disque dans 4 heures :

predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[1h], 4*3600) < 0

La fonction predict_linear() est particulièrement utile pour anticiper les problèmes avant qu'ils surviennent. Elle extrapole la tendance sur une fenêtre de temps donnée.

Services down :

up == 0

La métrique up est générée automatiquement par Prometheus pour chaque target : 1 si le scrape a réussi, 0 sinon. Simple et fiable.

Expiration TLS imminente :

(probe_ssl_earliest_cert_expiry - time()) / 86400 < 30

Cette requête retourne les certificats TLS qui expirent dans moins de 30 jours. La division par 86400 convertit les secondes en jours pour faciliter la lisibilité.

Règles d'alerte : les alerting rules indispensables

Les règles d'alerte Prometheus sont définies dans des fichiers YAML chargés via rule_files dans prometheus.yml. Créez un fichier /opt/monitoring/prometheus/rules/security.yml :

groups:
  - name: security_alerts
    interval: 30s
    rules:

    # Expiration certificat TLS
    - alert: TLSCertificateExpiringSoon
      expr: (probe_ssl_earliest_cert_expiry - time()) / 86400 < 30
      for: 1h
      labels:
        severity: warning
        team: security
      annotations:
        summary: "Certificat TLS expirant bientot"
        description: "Le certificat TLS de {{ $labels.instance }} expire dans {{ $value | printf \"%.0f\" }} jours."
        runbook_url: "https://wiki.interne/runbooks/tls-cert-renewal"

    - alert: TLSCertificateExpiredCritical
      expr: (probe_ssl_earliest_cert_expiry - time()) / 86400 < 7
      for: 30m
      labels:
        severity: critical
        team: security
      annotations:
        summary: "CRITIQUE : Certificat TLS expire dans moins de 7 jours"
        description: "{{ $labels.instance }} : expiration dans {{ $value | printf \"%.0f\" }} jours."

    # Taux d'erreurs HTTP 401/403
    - alert: HighHTTP401Rate
      expr: rate(nginx_http_requests_total{status=~"401|403"}[5m]) > 5
      for: 3m
      labels:
        severity: warning
        team: security
      annotations:
        summary: "Taux eleve d'erreurs d'authentification HTTP"
        description: "{{ $labels.instance }} genere {{ $value | printf \"%.1f\" }} req/s en erreur 401/403."

    # Connexions TCP anormalement elevees
    - alert: HighTCPConnections
      expr: node_netstat_Tcp_CurrEstab > 10000
      for: 5m
      labels:
        severity: warning
        team: security
      annotations:
        summary: "Nombre de connexions TCP anormalement eleve"
        description: "{{ $labels.instance }} : {{ $value }} connexions TCP etablies (seuil : 10000)."

    - alert: CriticalTCPConnections
      expr: node_netstat_Tcp_CurrEstab > 50000
      for: 2m
      labels:
        severity: critical
        team: security
      annotations:
        summary: "CRITIQUE : Possible attaque DDoS en cours"
        description: "{{ $labels.instance }} : {{ $value }} connexions TCP. Verifiez immediatement."

    # Espace disque critique
    - alert: DiskSpaceCritical
      expr: (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 10
      for: 5m
      labels:
        severity: critical
        team: ops
      annotations:
        summary: "Espace disque critique"
        description: "{{ $labels.instance }} : seulement {{ $value | printf \"%.1f\" }}% d'espace disponible sur /."

    - alert: DiskWillFillIn4Hours
      expr: predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[1h], 4*3600) < 0
      for: 30m
      labels:
        severity: warning
        team: ops
      annotations:
        summary: "Disque plein prevu dans 4 heures"
        description: "{{ $labels.instance }} : le disque sera plein dans moins de 4 heures selon la tendance actuelle."

    # Service down
    - alert: ServiceDown
      expr: up == 0
      for: 5m
      labels:
        severity: critical
        team: ops
      annotations:
        summary: "Service inaccessible"
        description: "{{ $labels.job }} sur {{ $labels.instance }} est down depuis plus de 5 minutes."

    # Tentatives SSH en rafale (via fail2ban exporter)
    - alert: SSHBruteForceDetected
      expr: increase(f2b_banned_ip_count{jail="sshd"}[10m]) > 10
      for: 2m
      labels:
        severity: warning
        team: security
      annotations:
        summary: "Attaque par force brute SSH detectee"
        description: "{{ $labels.instance }} : {{ $value }} nouvelles IP bannies sur SSH en 10 minutes."

    # Charge CPU suspecte
    - alert: SuspiciousHighCPU
      expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
      for: 10m
      labels:
        severity: warning
        team: security
      annotations:
        summary: "Charge CPU anormalement elevee"
        description: "{{ $labels.instance }} : CPU a {{ $value | printf \"%.1f\" }}% depuis 10 minutes. Verifiez les processus."

Le paramètre for est essentiel pour éviter les faux positifs : il demande à Prometheus de vérifier que la condition est vraie en continu pendant la durée spécifiée avant de déclencher l'alerte. Une valeur trop courte génère du bruit, une valeur trop longue retarde la détection.

Configuration Alertmanager : routage, receivers et intégrations

Alertmanager reçoit les alertes de Prometheus et les route vers les receivers appropriés selon des règles de matching. Il gère également le groupement des alertes (pour éviter les tempêtes de notifications), le silencing (pour mettre en pause des alertes pendant une maintenance) et l'inhibition (pour supprimer des alertes secondaires quand une alerte primaire est active).

Fichier alertmanager.yml complet :

global:
  resolve_timeout: 5m
  smtp_smarthost: 'smtp.exemple.fr:587'
  smtp_from: 'alerting@exemple.fr'
  smtp_auth_username: 'alerting@exemple.fr'
  smtp_auth_password: 'motdepasse_smtp'
  smtp_require_tls: true

route:
  group_by: ['alertname', 'instance', 'severity']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'default-receiver'

  routes:
    # Alertes critiques securite vers PagerDuty + Slack
    - match:
        severity: critical
        team: security
      receiver: 'security-critical'
      repeat_interval: 1h

    # Alertes warning securite vers Slack uniquement
    - match:
        severity: warning
        team: security
      receiver: 'security-warning'
      repeat_interval: 6h

    # Alertes ops critiques vers PagerDuty
    - match:
        severity: critical
        team: ops
      receiver: 'ops-critical'
      repeat_interval: 2h

receivers:
  - name: 'default-receiver'
    email_configs:
      - to: 'ops@exemple.fr'
        send_resolved: true

  - name: 'security-critical'
    pagerduty_configs:
      - routing_key: 'votre_integration_key_pagerduty'
        severity: critical
        description: '{{ range .Alerts }}{{ .Annotations.summary }}{{ end }}'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/TOKEN/CHANNEL/HASH'
        channel: '#alertes-securite-critique'
        send_resolved: true
        title: 'ALERTE CRITIQUE : {{ .GroupLabels.alertname }}'
        text: |
          {{ range .Alerts }}
          Instance: {{ .Labels.instance }}
          Description: {{ .Annotations.description }}
          {{ end }}

  - name: 'security-warning'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/TOKEN/CHANNEL/HASH'
        channel: '#alertes-securite'
        send_resolved: true
        title: 'Alerte : {{ .GroupLabels.alertname }}'
        text: |
          {{ range .Alerts }}
          Instance: {{ .Labels.instance }}
          Description: {{ .Annotations.description }}
          {{ end }}

  - name: 'ops-critical'
    pagerduty_configs:
      - routing_key: 'votre_integration_key_pagerduty_ops'
        severity: critical
    email_configs:
      - to: 'astreinte@exemple.fr'
        send_resolved: true

inhibit_rules:
  # Si le service est completement down, inhiber les autres alertes de cette instance
  - source_match:
      alertname: 'ServiceDown'
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['instance']

  # Si une alerte critique est active, inhiber le warning du meme type
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'instance']

Le group_wait de 30 secondes laisse le temps à d'autres alertes corrélées de s'agréger avant l'envoi de la première notification. Le group_interval contrôle la fréquence des notifications pour un groupe d'alertes existant. Le repeat_interval définit à quelle fréquence rappeler qu'une alerte est toujours active.

Pour l'intégration Microsoft Teams, utilisez un webhook entrant Teams et le receiver webhook_configs d'Alertmanager. Des outils comme alertmanager-webhook-teams ou prometheus-msteams facilitent la mise en forme des messages au format Teams Adaptive Cards.

Pour OpsGenie, Alertmanager dispose d'un receiver natif opsgenie_configs qui permet de définir la priorité, les équipes assignées et les tags directement dans la configuration.

Dashboards Grafana pour la sécurité

Grafana transforme les métriques Prometheus en visualisations exploitables. L'interface permet de créer des tableaux de bord interactifs avec drill-down par instance, par datacenter ou par application.

Dashboards communautaires à importer immédiatement :

Le dashboard Node Exporter Full (ID 1860) est la référence absolue pour les métriques système Linux. Il couvre CPU, mémoire, disque, réseau, processus et connexions réseau avec des visualisations optimisées. Importez-le via Dashboards → Import → saisir l'ID 1860.

Le dashboard Blackbox Exporter (ID 7587) affiche la disponibilité et les temps de réponse de tous vos endpoints surveillés, avec une vue dédiée à l'expiration des certificats TLS.

Pour créer un dashboard sécurité personnalisé, structurez-le en 4 rangées : une rangée de KPIs (nombre d'alertes actives, services down, certs expirant bientôt), une rangée réseau (connexions TCP, trafic entrant/sortant, erreurs), une rangée authentification (erreurs 401/403 par service, bans fail2ban) et une rangée ressources (CPU, mémoire, disque avec indicateurs de tendance).

La fonctionnalité Alerting de Grafana permet de définir des alertes directement depuis les dashboards, indépendamment des règles Prometheus. Utile pour des alertes visuelles basées sur des requêtes complexes. Depuis Grafana 9, le système d'alerting unifié supporte l'envoi vers les mêmes receivers qu'Alertmanager.

Les annotations Grafana permettent de marquer les événements importants sur les graphiques (déploiements, incidents, maintenances). Quand une alerte se déclenche, Grafana peut automatiquement annoter les dashboards concernés, facilitant la corrélation entre événements et métriques.

Détection d'anomalies : au-delà des seuils statiques

Les seuils statiques ont une limite fondamentale : ils ne s'adaptent pas aux variations normales de charge (pic de trafic le matin, maintenance hebdomadaire, soldes). La détection d'anomalies dynamique permet de déclencher des alertes basées sur l'écart par rapport au comportement habituel.

predict_linear() pour l'anticipation :

predict_linear(node_filesystem_avail_bytes[6h], 24*3600) < 0

Cette requête prédit si le disque sera plein dans 24 heures en extrapolant la tendance des 6 dernières heures. Particulièrement utile pour anticiper les problèmes avant qu'ils impactent les services.

Détection par écart-type avec stddev_over_time() :

abs(rate(http_requests_total[5m]) - avg_over_time(rate(http_requests_total[5m])[1h:5m]))
  > 3 * stddev_over_time(rate(http_requests_total[5m])[1h:5m])

Cette requête détecte les variations de trafic supérieures à 3 écarts-types par rapport à la moyenne de la dernière heure. Elle s'adapte automatiquement aux variations diurnes.

Pour une détection d'anomalies plus sophistiquée, des solutions de machine learning spécialisées pour les séries temporelles peuvent être intégrées via l'API Prometheus. Ces approches apprennent les patterns saisonniers de vos métriques et génèrent des seuils dynamiques qui évoluent avec votre infrastructure.

Pour la détection d'exfiltration de données, surveillez les ratios de trafic réseau : un ratio trafic sortant/entrant anormalement élevé sur une longue durée peut indiquer une exfiltration. La métrique node_network_transmit_bytes_total comparée à sa moyenne historique sur 7 jours via avg_over_time() est un bon point de départ. Couplé aux capacités d'analyse réseau d'un outil comme Nessus et Greenbone, ce monitoring forme une couche défensive robuste.

Sécurisation de la stack Prometheus

Par défaut, Prometheus expose son interface web sans authentification. En production, cette configuration est inacceptable — quiconque peut accéder à l'interface peut voir l'inventaire de votre infrastructure, les métriques système et potentiellement exploiter l'API admin pour modifier la configuration.

Authentification TLS native (Prometheus 2.24+) : Prometheus supporte l'authentification HTTP Basic et le TLS directement dans sa configuration web.yml :

# web.yml
tls_server_config:
  cert_file: /etc/prometheus/tls/prometheus.crt
  key_file: /etc/prometheus/tls/prometheus.key
  client_auth_type: RequireAndVerifyClientCert
  client_ca_file: /etc/prometheus/tls/ca.crt

basic_auth_users:
  admin: $2b$12$hNf2lSsxfm0.i4a.1kVpSOVyBCfIB51VRjgBUyv6kdnyTlmsvJ9C

Le hash du mot de passe est généré avec bcrypt : htpasswd -nB admin.

Reverse proxy Nginx avec authentification : Pour les déploiements Docker, un reverse proxy Nginx devant Prometheus offre authentification, rate limiting et journalisation des accès. Configurez une directive auth_basic avec un certificat TLS Let's Encrypt si Prometheus est accessible depuis Internet.

Segmentation réseau : Prometheus doit être isolé dans un VLAN de management. Les exporters ne doivent accepter des connexions qu'en provenance du serveur Prometheus (règle iptables ou nftables : iptables -A INPUT -p tcp --dport 9100 -s 192.168.10.5 -j ACCEPT; iptables -A INPUT -p tcp --dport 9100 -j DROP).

Rétention et chiffrement des données : Les métriques de sécurité peuvent contenir des informations sensibles sur l'activité réseau et les comportements utilisateurs. Chiffrez le volume Docker prometheus_data avec LUKS ou utilisez un stockage objet chiffré pour les rétentions longues. Implémentez une politique de rétention adaptée à vos obligations de conformité : le RGPD peut imposer des durées de conservation limitées pour certains types de métriques comportementales.

Mises à jour régulières : La stack Prometheus/Grafana/Alertmanager est activement maintenue et bénéficie de corrections de sécurité régulières. Automatisez les mises à jour des images Docker avec Watchtower ou Renovate, en testant d'abord sur un environnement de staging. En 2024, plusieurs vulnérabilités critiques ont été corrigées dans les plugins Grafana — un argument supplémentaire pour maintenir la stack à jour.

Questions fréquentes sur Prometheus et Alertmanager