J’ai arrêté de payer 480 €/mois de logs — la stack d’observabilité auto-hébergée en 7 étapes

La facture d’observabilité est un classique de la dérive silencieuse. On commence par envoyer quelques métriques, on ajoute les logs applicatifs parce que c’est pratique, puis les logs d’accès parce que le support en a besoin, et six mois plus tard la ligne mensuelle a été multipliée par cinq sans qu’aucune décision explicite n’ait été prise. C’est exactement ce qui nous est arrivé : 480 € par mois, dont l’essentiel provenait de l’ingestion de logs que nous consultions trois fois par trimestre.

La bascule vers une stack auto-hébergée a ramené ce poste à un VPS à 42 € par mois. Ce n’est pas une prouesse technique : Prometheus, Loki et Grafana sont matures, documentés et conçus pour ça. Le travail réel a porté sur trois points qu’aucun tutoriel ne détaille assez : le dimensionnement honnête, la maîtrise de la cardinalité, et la discipline d’alerting.

Cette méthode en sept étapes est celle que nous appliquons désormais. Elle est volontairement ordonnée : les étapes 1 et 7 sont celles qu’on est tenté de sauter, et ce sont précisément celles qui déterminent si l’installation tiendra six mois.

Étape 1 — Dimensionner avant d’installer quoi que ce soit

C’est l’étape que tout le monde saute, et c’est la seule qui ne se rattrape pas facilement après coup. Deux grandeurs déterminent tout le reste : le nombre de séries temporelles actives et le volume de logs quotidien.

Pour les métriques, la règle de calcul est simple : comptez environ 3 Ko de mémoire vive par série temporelle active. Une machine standard instrumentée avec node_exporter produit de l’ordre de 800 à 1 200 séries. Vingt machines représentent donc environ 20 000 séries, soit à peu près 60 Mo pour les seules métriques système — auxquelles s’ajoutent les métriques applicatives, généralement bien plus nombreuses.

Pour les logs, ne devinez pas : mesurez. Sur une machine représentative, laissez tourner une commande de comptage pendant 48 heures pour obtenir le volume réel par jour. Multipliez par le nombre de machines, puis par la rétention souhaitée, et ajoutez 40 % de marge. Loki compresse bien, mais la marge couvre les pics d’incident — le moment précis où l’on ne veut pas manquer de disque.

Notre point de départ recommandé pour 10 à 30 cibles : 4 vCPU, 8 Go de RAM, 160 Go de SSD, avec 30 jours de rétention de métriques et 14 jours de logs. Ces deux durées sont volontairement différentes : les métriques servent à voir des tendances sur plusieurs semaines, les logs servent à enquêter sur un incident récent. Leur appliquer la même rétention est un gaspillage systématique.

Étape 2 — Poser la base avec Docker Compose, sans exposer un seul port

La stack tient dans un fichier Compose unique : Prometheus, Loki, Grafana, et les exporters. Le point de méthode important est ailleurs : aucun de ces services ne doit publier de port sur l’interface publique. Prometheus et Loki n’ont pas d’authentification par défaut. Un Prometheus exposé sur internet, c’est votre topologie d’infrastructure offerte à qui la demande.

Les trois services communiquent sur un réseau Docker interne. Seul Grafana est accessible, et uniquement via un reverse proxy en frontal qui porte le certificat TLS et l’authentification. Tous les volumes sont nommés et déclarés explicitement, jamais des bind mounts vers des chemins temporaires : c’est ce qui rendra la sauvegarde de l’étape 7 possible.

Fixez les versions d’images précisément, sans utiliser le tag latest. Une stack d’observabilité qui se met à jour toute seule au redémarrage est une stack qui tombera pendant l’incident où vous en aurez le plus besoin. Cette discipline rejoint celle que nous décrivons pour configurer un environnement Docker sécurisé.

Étape 3 — Collecter les métriques en maîtrisant la cardinalité

Branchez d’abord node_exporter sur chaque machine : CPU, mémoire, disque, réseau. C’est immédiat et cela couvre déjà la moitié des incidents d’infrastructure. Ajoutez ensuite les métriques applicatives, et c’est là que se joue la survie de votre installation.

La cardinalité est le seul piège vraiment dangereux de Prometheus. Chaque combinaison distincte de labels crée une série temporelle conservée en mémoire. Un label user_id sur une métrique de requêtes, et vous passez de quelques centaines de séries à plusieurs millions. Le processus se fait tuer par le noyau pour dépassement mémoire, généralement quelques jours après le déploiement — assez tard pour qu’on ne fasse pas le lien avec le changement.

La règle est sans exception : un label ne doit prendre qu’un nombre fini et petit de valeurs. Nom du service, environnement, méthode HTTP, code de statut : oui. Identifiant d’utilisateur, de requête, de session, adresse IP, chemin d’URL complet avec paramètres : jamais. Ces informations existent, elles ont leur place — dans les logs, à l’étape suivante. Avant chaque mise en production d’une nouvelle métrique, posez-vous la question du nombre de valeurs possibles du label. Si vous ne savez pas répondre, la réponse est trop.

Étape 4 — Brancher les logs sur Loki, en indexant les labels et non le contenu

Loki fonctionne sur un principe différent d’Elasticsearch, et c’est ce qui explique son coût de fonctionnement très bas : il n’indexe pas le contenu des logs. Il n’indexe que les labels, et stocke le reste sous forme de blocs compressés parcourus à la demande.

La conséquence pratique est directe : la recherche plein texte sur trente jours de logs est lente, tandis que la recherche filtrée par labels puis par motif sur une fenêtre courte est rapide. Vos labels doivent donc être choisis pour découper le volume en tranches exploitables — service, environnement, niveau de log — et pas pour décrire le contenu. Ici encore, la cardinalité compte : un label par conteneur éphémère et l’index gonfle.

Configurez dès maintenant la rétention et la compaction. Un Loki laissé sans politique de rétention remplira le disque, et un disque plein sur la machine d’observabilité signifie que vous perdez la visibilité au pire moment. Vérifiez que la suppression fonctionne réellement en observant l’évolution de l’espace disque pendant les deux premières semaines — la configuration de rétention est un des points où une erreur passe inaperçue.

Étape 5 — Construire trois tableaux de bord, pas trente

La tentation, avec Grafana, est d’importer une vingtaine de tableaux de bord communautaires en une soirée. Six mois plus tard, personne ne sait lequel regarder pendant un incident. Nous nous limitons délibérément à trois.

Le tableau « santé machine » répond à une seule question : l’infrastructure tient-elle ? CPU, mémoire, disque, réseau, par machine, avec des seuils visibles. C’est celui qu’on ouvre en premier quand quelque chose est lent.

Le tableau « santé applicative » montre ce que vit l’utilisateur : taux de requêtes, taux d’erreur, latence aux 50e, 95e et 99e centiles. Ne vous contentez jamais de la moyenne : une latence moyenne correcte cache régulièrement un 99e centile catastrophique qui touche vos plus gros clients.

Le tableau « enquête » associe, sur une même page et une même fenêtre temporelle, les métriques applicatives et les logs correspondants. C’est le tableau qui fait gagner le plus de temps en incident, parce qu’il supprime l’aller-retour entre deux outils au moment où l’on réfléchit le moins bien.

Étape 6 — Écrire des alertes qui ne réveillent personne pour rien

Une stack d’observabilité sans alerting est un musée : on n’y va que quand on sait déjà qu’il y a un problème. Mais un alerting mal conçu est pire que pas d’alerting du tout, parce qu’il apprend à l’équipe à ignorer les notifications.

Le principe directeur tient en une phrase : alerter sur ce que vit l’utilisateur, pas sur ce que fait la machine. Une charge CPU de 92 % avec des temps de réponse normaux ne justifie aucun réveil. Un taux d’erreur HTTP qui dépasse 2 % pendant cinq minutes consécutives, si.

Ajoutez systématiquement une durée de maintien du seuil. Sans elle, chaque micro-pic déclenche une notification. Avec cinq minutes de maintien, seules les dégradations réelles passent le filtre. Prévoyez aussi une alerte sur les cibles de collecte injoignables : sans elle, une machine qui cesse d’émettre devient un angle mort silencieux, et l’absence de données ressemble beaucoup à l’absence de problème.

Enfin, imposez-vous une règle de discipline : toute alerte déclenchée qui n’a donné lieu à aucune action est corrigée ou supprimée dans la semaine. C’est cette revue régulière, bien plus que la qualité initiale des règles, qui maintient une astreinte crédible sur la durée. Après six mois, notre jeu de règles en compte sept.

Étape 7 — Sauvegarder, sécuriser, et tester la restauration

C’est l’étape la plus négligée, sur un service qu’on considère à tort comme jetable. Perdre ses données d’observabilité, c’est perdre l’historique qui permet de dire si la dégradation d’aujourd’hui est nouvelle ou installée depuis trois semaines.

Sauvegardez trois choses, avec des priorités différentes : la configuration (fichiers Compose, règles Prometheus, provisioning Grafana), qui doit vivre dans un dépôt Git et non sur le serveur ; les tableaux de bord Grafana, exportés en JSON et versionnés au même endroit ; et enfin les volumes de données, sauvegardés vers un stockage externe. Si vous deviez n’en garder qu’une, gardez la configuration : elle permet de reconstruire la stack en une heure, quand les données ne sont que de l’historique.

Côté sécurisation, trois mesures suffisent et sont non négociables : reverse proxy avec TLS devant Grafana, authentification forte sur les comptes administrateurs, et aucun port de Prometheus ou Loki accessible depuis l’extérieur. Si l’accès distant est nécessaire, passez par un tunnel ou un réseau privé plutôt que par une exposition publique, même protégée par mot de passe. Pour le durcissement de la machine hôte elle-même, l’approche de nos confrères de WebGuard Agency sur la segmentation réseau reste une bonne base de départ.

Enfin, testez la restauration une fois, sur une machine jetable, avant de considérer le chantier terminé. Une sauvegarde jamais restaurée n’est pas une sauvegarde, c’est une intention. Le même raisonnement s’applique à vos bases de données, comme nous le détaillons dans notre méthode de sauvegarde PostgreSQL PITR sur VPS auto-hébergé. Et si votre motivation initiale était de reprendre la main sur des abonnements qui dérivent, la démarche complète est décrite dans notre retour sur le fait de remplacer des abonnements par un serveur auto-hébergé. Les équipes qui industrialisent ce type de plateforme trouveront aussi des retours utiles côté Plug-Tech.

FAQ