Surveillance des applications JavaScript : métriques et alertes de A à Z
\n\nDans le monde moderne du développement, il ne suffit pas d'écrire du code fonctionnel. Il est crucial de comprendre comment votre application se comporte en environnement de production. La surveillance des applications JavaScript (en particulier sur Node.js) n'est pas seulement une tendance, mais une nécessité. Elle permet d'identifier les goulots d'étranglement, de prévenir les pannes et d'assurer une haute disponibilité des services. Dans cet article, nous allons parcourir le cycle complet : de la collecte des métriques clés à la configuration des alertes, en utilisant une pile d'outils moderne.
\n\nPourquoi la surveillance de Node.js est-elle importante ?
\nLes applications Node.js fonctionnent souvent en mode asynchrone, traitant des milliers de requêtes par seconde. Sans surveillance, vous risquez :
\n- \n
- De passer à côté d'une fuite mémoire (memory leak) qui entraînerait un crash du serveur. \n
- De ne pas remarquer une augmentation du temps de réponse (latence), ce qui dégraderait l'expérience utilisateur. \n
- De perdre des données à cause d'erreurs non traitées. \n
Un système de surveillance vous offre une visibilité (observabilité) et vous permet de prendre des décisions basées sur des données, et non sur des suppositions.
\n\nMétriques clés pour les applications JavaScript
\nToutes les métriques peuvent être divisées en trois groupes : métriques d'infrastructure, métriques métier et métriques d'application. Examinons-les en détail.
\n\n1. Métriques d'infrastructure (méthode USE)
\nCe sont les indicateurs de base de la santé du serveur : CPU, mémoire, disque, réseau. Pour Node.js, la mémoire (heap, non-heap) et le nombre de descripteurs de fichiers ouverts sont particulièrement importants.
\n\n2. Métriques d'application (méthode RED)
\nLa méthode RED (Rate, Errors, Duration) est le standard de référence pour les microservices :
\n- \n
- Rate (Débit) : nombre de requêtes par seconde (RPS). \n
- Errors (Erreurs) : pourcentage de requêtes terminées par une erreur (4xx, 5xx). \n
- Duration (Durée) : temps d'exécution de la requête (percentiles p50, p95, p99). \n
3. Métriques métier
\nSpécifiques à votre produit : nombre d'utilisateurs enregistrés, commandes terminées, sessions actives, etc.
\n\nCollecte de métriques avec Prometheus et Node.js
\nPrometheus est le standard de facto pour la collecte de métriques. Pour Node.js, nous utilisons la bibliothèque prom-client. Voici un exemple de configuration.
Installation et configuration de base
\nnpm install prom-client express\n\nCréons un serveur avec un endpoint /metrics :
const express = require('express');\nconst client = require('prom-client');\n\nconst app = express();\nconst port = 3000;\n\n// Création d'un registre de métriques\nconst register = new client.Registry();\n\n// Ajout des métriques standard Node.js\nclient.collectDefaultMetrics({ register });\n\n// Création d'un histogramme personnalisé pour le temps de réponse\nconst httpRequestDuration = new client.Histogram({\n name: 'http_request_duration_seconds',\n help: 'Duration of HTTP requests in seconds',\n labelNames: ['method', 'route', 'status'],\n buckets: [0.01, 0.05, 0.1, 0.5, 1, 2, 5]\n});\nregister.registerMetric(httpRequestDuration);\n\n// Middleware pour mesurer le temps\napp.use((req, res, next) => {\n const end = httpRequestDuration.startTimer();\n res.on('finish', () => {\n end({ method: req.method, route: req.route?.path || 'unknown', status: res.statusCode });\n });\n next();\n});\n\n// Endpoint pour les métriques\napp.get('/metrics', async (req, res) => {\n res.set('Content-Type', register.contentType);\n res.end(await register.metrics());\n});\n\napp.get('/', (req, res) => {\n res.send('Hello, monitoring!');\n});\n\napp.listen(port, () => {\n console.log(`App listening at http://localhost:${port}`);\n});\n\nCompteurs personnalisés
\nAjoutons un compteur d'erreurs :
\nconst errorCounter = new client.Counter({\n name: 'app_errors_total',