const express = require('express');
const router = express.Router();
const db = require('./db'); // instanța ta de DB
let eventLoopLag = 0;
const calculateLag = () => {
const start = Date.now();
setTimeout(() => {
eventLoopLag = Date.now() - start - 4; // 4ms e delay-ul minim teoretic
}, 4);
};
setInterval(calculateLag, 2000).unref();
router.get('/health/readiness', async (req, res) => {
try {
// 1. Verificăm lag-ul event loop-ului
if (eventLoopLag > 200) {
return res.status(503).json({ status: 'unhealthy', reason: 'Event loop lag too high' });
}
// 2. Verificăm DB rapid (cu timeout scurt)
await Promise.race([
db.raw('SELECT 1'),
new Promise((_, reject) => setTimeout(() => reject(new Error('DB Timeout')), 1500))
]);
return res.status(200).json({ status: 'healthy' });
} catch (err) {
return res.status(503).json({ status: 'unhealthy', error: err.message });
}
});Am văzut de prea multe ori setup-uri de PM2 unde monitorizarea se bazează orbește pe comanda pm2 status. „Dacă scrie online cu verde, e bine”, zice devops-ul din noi. Am pățit-o urât pe un proiect cu 12k useri activi unde PM2 arăta verde, dar aplicația dădea timeout-uri pe bandă rulantă.
De ce „online” în PM2 este o minciună frumoasă
PM2 monitorizează procesul la nivel de sistem de operare. Pentru el, dacă PID-ul există și Node.js consumă memorie, totul e roz.
Dar Node.js este single-threaded. Dacă ai un event loop blocat de o funcție sincronă scrisă prost sau dacă conexiunea la baza de date a picat din cauza unui timeout de rețea, procesul tău este, tehnic, „online”. Practic, este o legumă care nu mai poate răspunde la niciun request HTTP.
Am pățit exact asta când un pool de conexiuni Postgres s-a epuizat. PM2 raporta că totul e perfect, Nginx dădea 504 Gateway Timeout, iar clienții ne sunau nervoși. Am pierdut două ore de debug doar pentru că monitorizarea de bază ne trimitea pe piste greșite.
Ce ratează monitorizarea clasică de PM2
- Deadlock-urile de rețea: Când conexiunile către DB sau Redis sunt „half-open”.
- Event Loop Lag mare: Când CPU-ul e la 100% și procesul nu mai preia evenimente noi.
- Scurgerile de memorie înainte de crash: Până să apuce PM2 să dea restart aplicației din cauza
max_memory_restart, aplicația ta se va târî minute bune, oferind un response time mizerabil.
Cum se face un healthcheck real
Soluția nu e să te bazezi pe PM2 pentru starea de sănătate internă a aplicației, ci să expui un endpoint dedicat (de obicei /health sau /ping) pe care să-l interogheze un load balancer (AWS ALB, Nginx, Cloudflare) sau un serviciu extern de monitorizare.
Endpoint-ul ăsta nu trebuie doar să returneze 200 OK. Trebuie să facă o verificare rapidă, dar superficială, a dependențelor critice.
Iată o implementare pe care o folosesc de obicei în Express. Verifică baza de date și lag-ul event loop-ului, dar cu o limitare inteligentă ca să nu omorâm baza de date cu request-urile de healthcheck.
Trade-off-ul de care trebuie să ții cont
Există o capcană majoră aici: dacă healthcheck-ul tău e prea „strict” și verifică absolut tot (bază de date, Redis, 3 API-uri externe), riști să îți bagi singur aplicația în pământ.
Dacă un API extern de trimis SMS-uri este jos, dar aplicația ta încă poate loga useri și procesa comenzi, ar trebui ca healthcheck-ul să dea fail și load balancer-ul să scoată instanța din producție? Categoric nu.
De asta recomand două endpoint-uri:
/health/liveness– care verifică doar dacă procesul e viu și event loop-ul nu e blocat (folosit pentru restart-uri rapide)./health/readiness– care verifică conexiunea la DB și Redis (folosit de load balancer ca să știe dacă trimite trafic acolo).
După ce am implementat separarea asta și am început să testăm real conectivitatea, am redus alertele false cu 80% și am economisit zeci de nopți nedormite.
Voi cum vă asigurați că procesele voastre de Node chiar răspund la trafic, dincolo de clasicul pm2 status?