Grafana / Prometheus

Prometheus collecte des mesures — temps de réponse, taux d'erreur, mémoire, espace disque, files d'attente — et Grafana les met en courbes et en seuils d'alerte. L'ensemble répond à une question simple qu'une PME se pose toujours trop tard : est-ce que ça marche en ce moment, et depuis quand est-ce que ça se dégrade ? La différence n'est pas cosmétique. Sans mesure, un service tombe et c'est un client qui prévient ; avec, la dégradation se voit pendant qu'elle est encore corrigeable.

• →Elasticsearch / ELKPour l'enquête dans les journaux plutôt que la mesure chiffrée : complémentaire, pas concurrentVoir la page
• →Sonde de disponibilité externePour un site vitrine, savoir qu'il répond depuis l'extérieur suffit souvent
• →Offres de supervision en ligneQuand la supervision doit survivre à la panne de votre infrastructure, contre un abonnement à la volumétrie
• →CloudflareMesures de trafic et de disponibilité vues du bord, sans rien installerVoir la page

1. 01

   Partir des pannes qui coûtent, pas des mesures disponibles : la liste des alertes s'écrit avant la première courbe

2. 02

   Quelques indicateurs par service — disponibilité, latence, taux d'erreur, saturation — plutôt qu'un mur de graphiques

3. 03

   Seuils calés sur l'observation réelle après quelques semaines, pas sur des valeurs par défaut

4. 04

   Alertes routées vers un destinataire nommé, avec ce qu'il doit regarder en premier

5. 05

   Tableaux de bord réduits à ce qu'on consulte pendant un incident, le reste est du décor

• Quelle différence avec une stack de journaux comme l'ELK ?

  Les mesures répondent à « est-ce que ça va, et depuis quand » ; les journaux répondent à « qu'est-ce qui s'est passé exactement ». Prometheus stocke des séries chiffrées, très compactes, sur lesquelles on pose des seuils. Une stack de journaux stocke du texte et sert à l'enquête. On commence presque toujours par les mesures, parce qu'elles déclenchent l'alerte ; on ouvre les journaux ensuite, pour comprendre.
• Faut-il héberger soi-même ou prendre une offre en ligne ?

  Auto-hébergé, le logiciel est gratuit et le coût de fonctionnement est celui d'une petite machine et de son disque, qui grandit avec la durée de rétention. En ligne, l'éditeur propose une offre gratuite suffisante pour un petit périmètre, puis une facturation à la volumétrie. Le vrai critère n'est pas le prix : c'est de savoir si votre supervision doit survivre à la panne de votre propre infrastructure.
• Combien coûte la mise en place d'une supervision ?

  Ce qui pèse, c'est le nombre de services à instrumenter, le fait que l'application expose ou non ses propres mesures, le nombre d'environnements et le niveau d'astreinte visé — être prévenu en heures ouvrées ou à trois heures du matin ne demande pas le même dispositif. Le montant se fixe au devis, après un cadrage initial gratuit qui écrit le périmètre avant tout engagement.
• Faut-il modifier l'application pour être supervisé ?

  Pas pour commencer. Les mesures système, celles du serveur web et celles de la base s'obtiennent sans toucher au code, et couvrent déjà la majorité des pannes. Instrumenter l'application elle-même — durée des traitements métier, files d'attente, erreurs fonctionnelles — vient dans un second temps, quand on veut voir ce qui se dégrade avant que le serveur ne s'en aperçoive.
• Combien de temps garder les mesures ?

  Assez pour comparer une anomalie à une situation normale : quelques semaines suffisent pour l'exploitation courante, un an si l'objectif est de démontrer une tendance ou de dimensionner. La rétention est le principal poste de coût du disque, donc c'est un arbitrage explicite et non un réglage par défaut qu'on laisse tourner.