const express = require('express');
const router = express.Router();
const mongoose = require('mongoose'); // Exemplu cu MongoDB
let toobusy = false;
// Monitorizăm event loop lag-ul simplu
setInterval(() => {
const start = Date.now();
setTimeout(() => {
const lag = Date.now() - start - 50; // 50ms e intervalul dorit
toobusy = lag > 200; // Dacă lag-ul e peste 200ms, suntem prea încărcați
}, 50);
}, 1000).unref();
router.get('/health', async (req, res) => {
if (toobusy) {
return res.status(503).send('Server toobusy - Event Loop lag detected');
}
try {
// Verificăm conexiunea la DB, dar cu un timeout scurt
const dbStatus = mongoose.connection.readyState === 1;
if (!dbStatus) {
return res.status(500).send('Database connection is down');
}
res.status(200).send('OK');
} catch (err) {
res.status(500).send('Healthcheck failed');
}
});Toți am trecut prin asta. Dai un pm2 status, vezi acolo un verde frumos cu statusul online și răsufli ușurat. Totuși, telefoanele încep să sune, clienții urlă, iar în loguri e liniște totală.
Am pățit chestia asta acum vreo doi ani, la un proiect cu peste 14.000 de utilizatori activi concurenți. Node-ul nostru intrase într-un loop infinit din cauza unui regex scris prost de un junior (da, clasica poveste). Procesul rula la 100% CPU, event loop-ul era complet blocat, dar PM2 raporta fericit că totul e în regulă. De ce? Pentru că pentru PM2, atâta timp cât procesul OS (PID-ul) există și nu a crăpat fizic, aplicația ta e „vie”.
De ce monitorizarea nativă din PM2 dă rateuri
PM2 este un manager de procese excelent, dar nu este un instrument de monitorizare a sănătății aplicației (application health monitor). El știe doar atât: procesul a pornit, nu a luat crash cu exit code diferit de zero, deci e bine.
PM2 nu știe:
- Dacă baza ta de date a picat și toate rutele returnează 500.
- Dacă event loop-ul are un lag de 5 secunde.
- Dacă ai un memory leak masiv și garbage collector-ul rulează continuu, blocând orice request nou.
Pentru a rezolva asta, ai nevoie de un healthcheck activ. Adică ceva din exterior (sau un proces secundar) care să „împungă” aplicația și să verifice dacă mai răspunde la stimulii de bază.
Soluția: Un endpoint de /health inteligent
Nu e suficient să pui o rută care returnează 200 OK instant. Dacă event loop-ul e blocat parțial, s-ar putea ca rutele simple să răspundă, dar cele care ating baza de date să moară.
Trebuie să scrii un endpoint care verifică elementele critice. Dar atenție la trade-off: dacă verifici conexiunea la baza de date la fiecare 2 secunde pe un load balancer cu 50 de instanțe, o să-ți blochezi singur baza de date cu interogări inutile.
Eu prefer o abordare hibridă: cache de 5-10 secunde pentru verificările grele (DB, Redis) și verificare în timp real pentru event loop lag.
Cum integrăm asta cu PM2 în producție
Dacă rulezi PM2 pe un VPS simplu, fără Kubernetes sau un load balancer deștept în față (cum ar fi AWS ALB sau Cloudflare), ai nevoie de un script extern care să ruleze pe post de watchdog.
O variantă curată este să folosești un script simplu de bash rulat prin cron (sau chiar un alt proces PM2 de tip daemon) care face un request local cu curl. Dacă endpoint-ul /health dă timeout sau întoarce altceva în afară de 200 de trei ori la rând, scriptul rulează pm2 reload <app_name>.
Este o soluție „bătrânească”, dar am economisit cu ea cam 30% din timpul de downtime în nopțile de weekend înainte să migrăm infrastructura în Cloud.
Ce folosiți pentru a monitoriza aplicațiile Node.js sub PM2? Vă bazați pe PM2 Plus (care costă destul de mult pentru ce oferă) sau aveți scripturi custom?