const express = require('express');
const router = express.Router();
const { checkDatabase, checkRedis } = require('./services');
router.get('/healthz', async (req, res) => {
const timeout = (ms) => new Promise((_, reject) =>
setTimeout(() => reject(new Error('Timeout')), ms)
);
try {
// Rulăm verificările în paralel cu un timeout de 2000ms
await Promise.race([
Promise.all([checkDatabase(), checkRedis()]),
timeout(2000)
]);
res.status(200).send('OK');
} catch (err) {
console.error('Healthcheck failed:', err.message);
res.status(503).send('Service Unavailable');
}
});
module.exports = router;Să fim serioși: dacă te bazezi doar pe statusul „online” afișat de PM2 în consolă, ești la un pas de un downtime masiv neraportat. Am pățit asta la un proiect cu peste 14.000 de utilizatori activi, unde PM2 arăta verde, dar aplicația dădea 502 pe bandă rulantă. În postarea asta îți arăt cum să faci un healthcheck real, care chiar testează dacă aplicația ta e vie, nu doar dacă procesul rulează.
Iluzia lui „online” în PM2
PM2 e excelent ca process manager. Îți restartează aplicația dacă crapă cu uncaughtException, îți ține logurile și face cluster mode destul de ok. Problema e că PM2 se uită doar la nivel de sistem de operare. El se întreabă practic: „Procesul cu PID-ul X mai există? Da? Atunci e online”.
Dar ce te faci când baza de date a picat, pool-ul de conexiuni e blocat sau ai un memory leak care a dus event loop-ul la 100% utilizare? Pentru PM2, procesul tău e perfect sănătos. Pentru clienții tăi, site-ul e mort. Procesul e acolo, dar nu mai răspunde la niciun request HTTP.
Cum construim un healthcheck adevărat
Nu te complica cu tool-uri externe greoaie de la început. Primul pas e să expui un endpoint dedicat în aplicație, de exemplu /healthz sau /ping. Acest endpoint nu trebuie doar să întoarcă un simplu text „OK” hardcodat. Trebuie să verifice conexiunile critice, dar cu un timeout foarte agresiv. Nu vrei ca healthcheck-ul să blocheze și mai mult resursele când lucrurile merg prost.
Am învățat asta pe pielea mea: la început, healthcheck-ul meu aștepta după o interogare SQL care dura uneori 10 secunde dacă baza era încărcată. Am pus un timeout de 2 secunde pe verificarea de DB. Dacă nu răspunde în 2 secunde, e considerat picat.
Cum legăm asta de monitorizare?
Ok, ai endpoint-ul. Cum îl verifici? Dacă rulezi PM2 pe un VPS simplu, poți folosi un script cron de 1 minut care dă un curl local și, dacă primește altceva decât 200, rulează pm2 reload app-name.
Trade-off-ul sincer aici? Dacă ai un spike masiv de trafic și event loop-ul e doar temporar ocupat (să zicem 3-4 secunde), un healthcheck prea agresiv îți va restarta aplicația fix când are mai mare nevoie să proceseze coada de request-uri. De asta, recomand regula de „3 eșecuri consecutive” înainte de a lua măsuri drastice de restart. Pe noi ne-a salvat de la cel puțin 5 restarturi inutile pe zi.
Voi cum vă monitorizați procesele de Node.js în producție? Vă bazați pe PM2 nativ sau aveți scripturi externe de verificare?