Construire un dashboard de monitoring avec Prometheus, Grafana et Node.js

Un service Node.js peut fonctionner correctement en développement tout en révélant des problèmes sous charge : latence croissante, saturation mémoire, erreurs HTTP ou appels externes trop lents. Un système d’observabilité permet de transformer ces signaux en données exploitables et de réagir avant qu’une panne ne devienne visible pour les utilisateurs.

Prometheus collecte les métriques, Grafana les représente et Node.js expose les informations nécessaires. Cette combinaison open source convient aussi bien à une API REST qu’à un worker, un microservice ou une application exécutée dans Docker. Elle constitue une base solide pour suivre la disponibilité, les performances et la capacité d’un environnement de production.

Comprendre Le Rôle De Chaque Composant

Prometheus adopte un modèle de collecte par scrutation. À intervalles réguliers, il interroge une URL comme /metrics, récupère des séries temporelles au format attendu, puis les stocke avec leurs labels. Il sait ensuite agréger ces données grâce à PromQL, son langage de requête.

Grafana ne collecte rien directement dans ce scénario. Il se connecte à Prometheus comme source de données et transforme les requêtes en graphiques, jauges, tableaux ou alertes. Node.js, de son côté, doit instrumenter l’application et exposer des compteurs, des jauges et des histogrammes pertinents. Pour approfondir l’écosystème JavaScript, le portail Développeur Web propose également des ressources consacrées à Node.js et à l’outillage moderne.

Instrumenter Une Application Node.js

Le paquet prom-client est une solution courante pour ajouter une instrumentation Prometheus. Il fournit des métriques par défaut, comme l’utilisation CPU, la mémoire du processus et les événements de la boucle d’événements. L’installation s’effectue simplement avec npm install prom-client.

import client from "prom-client";

const registry = new client.Registry();
client.collectDefaultMetrics({ register: registry });

const httpDuration = new client.Histogram({
  name: "http_request_duration_seconds",
  help: "Durée des requêtes HTTP",
  labelNames: ["method", "route", "status_code"],
  buckets: [0.05, 0.1, 0.3, 0.5, 1, 2, 5]
});

registry.registerMetric(httpDuration);

Un histogramme convient à la latence, car il répartit les observations dans des intervalles. Un compteur, créé avec new client.Counter, mesure une valeur croissante comme le nombre d’erreurs. Une jauge, avec new client.Gauge, représente un état variable : connexions actives, éléments en file d’attente ou mémoire utilisée.

Exposer L’Endpoint De Métriques

Avec Express, l’endpoint peut renvoyer le contenu du registre et son type MIME spécifique. Il est préférable de garder cette route légère, sans logique métier ni accès à une base de données, afin que la collecte ne perturbe pas le service observé.

app.get("/metrics", async (_req, res) => {
  res.set("Content-Type", registry.contentType);
  res.end(await registry.metrics());
});

La mesure de la durée doit entourer le traitement réel de la requête. Un middleware peut démarrer un chronomètre, puis enregistrer l’observation lors de l’envoi de la réponse. Les routes dynamiques doivent être normalisées : utiliser /users/:id comme label est préférable à une URL contenant chaque identifiant, car une cardinalité excessive augmente le volume de séries.

Ajoutez aussi un identifiant de version ou d’environnement lorsque cela facilite le diagnostic, mais évitez les labels très variables comme une adresse IP, un token ou un identifiant utilisateur. Ces valeurs peuvent produire des milliers de séries inutiles et exposer des informations sensibles.

Configurer La Collecte Avec Prometheus

Le fichier prometheus.yml définit les cibles interrogées. Une configuration minimale pour un service local peut ressembler à ceci :

global:
  scrape_interval: 15s

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

Dans Docker Compose, api correspond au nom du service Node.js sur le réseau interne. En production, les cibles peuvent venir d’un service discovery Kubernetes, d’un fournisseur cloud ou d’un mécanisme de découverte basé sur des fichiers. Vérifiez que le port est accessible depuis Prometheus et que le chemin retourne bien un contenu au format Prometheus.

Les métriques système méritent une attention particulière. Node.js renseigne l’application, tandis que Node Exporter peut fournir des données sur le système hôte : espace disque, charge CPU, mémoire disponible et trafic réseau. Cette séparation aide à distinguer un défaut applicatif d’une saturation de l’infrastructure.

Concevoir Des Panneaux Grafana Utiles

Après avoir ajouté Prometheus comme source dans Grafana, créez des panneaux orientés décision. Le taux de requêtes peut être calculé avec rate(http_requests_total[5m]). Pour obtenir un percentile de latence à partir d’un histogramme, utilisez par exemple :

histogram_quantile(
  0.95,
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
)

Un dashboard efficace affiche le trafic, le taux d’erreur, la latence p95 ou p99, l’utilisation mémoire et l’état des dépendances. Chaque graphique doit répondre à une question opérationnelle : l’API est-elle disponible ? Les réponses ralentissent-elles ? Une route particulière génère-t-elle des erreurs ?

Les variables Grafana permettent de filtrer par service, instance, environnement ou route. Utilisez des unités cohérentes, des seuils explicites et des plages temporelles adaptées. Un panneau trop chargé ralentit l’analyse ; plusieurs vues simples sont souvent plus utiles qu’un écran rempli de séries superposées.

Sécuriser Et Fiabiliser La Supervision

L’endpoint /metrics ne doit pas devenir une porte d’entrée publique sans contrôle. Selon l’architecture, placez-le derrière un réseau privé, une règle de pare-feu, une authentification du reverse proxy ou une allowlist réservée aux collecteurs. Ne publiez jamais de secrets, de données personnelles ou de contenu issu directement des requêtes.

La qualité des métriques dépend aussi de leur cohérence. Utilisez des noms explicites en snake_case, documentez les labels et conservez les mêmes unités entre les services. Les alertes doivent signaler une condition exploitable, comme un taux d’erreur supérieur à un seuil pendant plusieurs minutes, plutôt qu’un simple pic isolé.

Pour une application Node.js traitant des fichiers, les performances et la sécurité doivent être observées ensemble. Les pratiques décrites dans ce guide sur l’API de conversion peuvent être complétées par des métriques sur la taille des fichiers, la durée de traitement et le nombre d’échecs.

Repères Pratiques Pour L’Exploitation

Avant de déployer le dashboard, vérifiez les éléments qui garantissent des mesures fiables et actionnables.

Une supervision durable repose également sur des règles simples de maintenance. Les noms de métriques doivent rester stables, les dashboards doivent être versionnés et les alertes doivent posséder un responsable clairement identifié.

La sécurité opérationnelle concerne aussi les cookies et les sessions lorsque Grafana est intégré à une plateforme interne. Les recommandations de sécurisation des cookies sont utiles pour renforcer les attributs HttpOnly, Secure et SameSite des applications qui entourent l’outil de supervision.

Comparer Les Responsabilités Des Outils

Ces composants sont complémentaires, mais ils ne répondent pas au même besoin. Les distinguer facilite le dépannage et évite de placer dans Grafana une logique qui devrait appartenir à l’application ou au collecteur.

Outil Fonction principale Exemple d’utilisation Point de vigilance
Node.js avec prom-client Produire les métriques applicatives Latence, erreurs, files d’attente Labels trop nombreux
Prometheus Collecter, stocker et interroger Scraping, PromQL, règles d’alerte Rétention et cardinalité
Grafana Visualiser et explorer Dashboards, variables, seuils Panneaux surchargés
Node Exporter Mesurer l’hôte système CPU, disque, mémoire, réseau Accès à protéger

Un déploiement peut commencer modestement : un service Node.js instrumenté, une instance Prometheus et un Grafana local. Ajoutez ensuite les alertes, les métriques d’infrastructure et la corrélation avec les logs ou les traces distribuées. Cette progression réduit la complexité initiale tout en construisant une observabilité réellement utile.

Pour aller plus loin, automatisez la création des dashboards, testez les règles PromQL dans votre pipeline CI et vérifiez le comportement sous charge. Un monitoring bien conçu ne se limite pas à afficher des courbes : il accélère l’identification des incidents et fournit aux développeurs des données concrètes pour améliorer leur code.