Health-Check de un Backend Node.js: 12 Señales que Auditamos
Datadog te cobra 31 dólares por host. Tu startup de 12 servicios acaba de gastar runway en logs antes de facturar al primer cliente. Y la peor parte no es el precio: es que la mayoría de los equipos que pagan por un SaaS de observabilidad carísimo no entienden qué están midiendo. Pagan por dashboards que nadie abre, por alertas que todos silencian, y por retention de 30 días de datos que nunca consultan.
Auditoría técnica real de un backend Node.js de PyME no necesita un contrato enterprise de Datadog. Necesita responder a 12 preguntas específicas que revelan la madurez operacional del sistema. Las hemos estandarizado en el health-check que corremos antes de aceptar un cliente de backend: si el sistema falla en más de 4 de esas 12, la conversación cambia de "optimizamos" a "reconstruimos la capa de observabilidad antes de tocar la lógica de negocio".
Todo el stack que cubrimos es open source, se autohospeda en un VPS de 20 dólares al mes, y reemplaza el 90% de las funciones de Datadog/New Relic para el tamaño de operación típico de una PyME. No es un ejercicio académico: es el stack que corremos nosotros mismos.
En este artículo aprenderás:
- Las 12 señales del health-check que auditamos en cualquier backend Node.js: logs, traces, métricas, errores, latencia y más
- Stack OSS completo: OpenTelemetry + Prometheus + Grafana + Loki + Tempo, con
docker-compose.ymlfuncional - Qué instrumentar primero si solo tienes 2 horas antes de la próxima reunión con el CFO
- Alertas mínimas que cualquier backend en producción debería tener antes de dormir tranquilo
- Cuándo sí conviene un SaaS pagado — y cuándo es desperdicio de dinero
Las tres dimensiones de la observabilidad
Antes de las 12 señales, hay que separar qué estamos midiendo. La observabilidad moderna se apoya en tres pilares complementarios, y confundirlos es la razón número uno por la que los dashboards no ayudan a diagnosticar incidentes.
Logs son eventos discretos con contexto estructurado. "El usuario X intentó login con password incorrecto" es un log. Sirven para auditoría, para rastrear el flujo lógico, y para revisar qué pasó en un momento específico del pasado.
Métricas son series temporales numéricas agregadas. "99 requests por segundo a /api/orders, latencia p95 de 340ms" es métrica. Sirven para dashboards, alertas y detección de tendencias. Son baratas en storage porque se agregan.
Traces son el recorrido de una petición específica a través del sistema. "El request abc123 entró al API gateway, pasó por el servicio de auth en 12ms, por el servicio de inventarios en 85ms, y tiró una excepción en la llamada a PostgreSQL". Sirven para debugging de casos específicos y para entender por qué un endpoint se volvió lento.
Un sistema maduro tiene los tres. Un sistema inmaduro típicamente tiene logs sin estructura (console.log) y nada más. Las 12 señales del health-check cubren las tres dimensiones y algunas piezas transversales.
OpenTelemetry (OTel) es un estándar CNCF (Cloud Native Computing Foundation) que te permite instrumentar tu aplicación una sola vez y emitir logs + métricas + traces a cualquier backend. Cambiar de SaaS pagado a stack OSS mañana se reduce a cambiar la variable de entorno OTEL_EXPORTER_OTLP_ENDPOINT. Si instrumentás con el SDK propietario de Datadog, quedás casado con ellos.
Las 12 señales del health-check
Corremos estas 12 en una llamada técnica de 45 minutos con el equipo del cliente. Cada una tiene una respuesta binaria "sí/no" y un umbral específico.
1. Logs estructurados en JSON, no texto plano. console.log('user logged in') no es log estructurado. logger.info({ userId, event: 'login' }) sí lo es. Sin estructura, no hay forma de filtrar ni agregar. Librería recomendada: pino (MIT), 5× más rápido que Winston.
2. Correlation ID propagado end-to-end. Cada request entrante debe generar o propagar un traceId que aparezca en todos los logs y spans generados durante su vida. Sin esto, debuggear un incidente es imposible porque no puedes reconstruir qué logs pertenecen al mismo request.
3. Métrica de latencia con percentiles p50, p95, p99. El promedio de latencia miente. El p99 te dice qué experimenta el 1% peor de usuarios, que típicamente es el 1% que se va. Exportado a Prometheus con histograma, no como gauge.
4. Métrica de error rate por endpoint. Tasa de respuestas 5xx y 4xx por ruta, por minuto. Un pico de 4xx puede significar ataque de enumeración o cliente roto; un pico de 5xx es incendio.
5. Traces distribuidos de extremo a extremo. Un request llega al API gateway, pasa por 3 servicios, toca PostgreSQL y Redis. Su trace debe mostrar los 5 spans en orden cronológico con duración de cada uno. Sin esto, no entiendes por qué un endpoint se volvió lento.
6. Dashboard con Four Golden Signals. Google SRE estableció cuatro señales universales: latencia, tráfico, errores y saturación (CPU/memoria). Un dashboard de Grafana con esos cuatro paneles es el 80% del valor operacional.
7. Alertas basadas en SLO, no en CPU. "Alertá cuando la CPU supere 80%" es inútil: a veces 90% de CPU es óptimo. "Alertá cuando el error rate del checkout supere 1% por 5 minutos" es accionable. Las alertas deben disparar cuando el usuario se ve afectado.
8. Retention de 7-30 días de logs y 90 días de métricas. Menos de eso y no puedes hacer post-mortems; más de eso para PyME es desperdicio de storage. Loki para logs y Prometheus para métricas, ambos configurables.
9. Health check /healthz que verifique dependencias. No solo return 200. Debe intentar una query a PostgreSQL, un PING a Redis, y devolver el status de cada dependencia. Los orquestadores (Kubernetes, Docker Swarm, Render) lo necesitan para tomar decisiones de reinicio.
10. Logs de queries lentas de la base de datos. pg_stat_statements en PostgreSQL o slow query log en MySQL, corriendo permanentemente. Sin esto, no detectas el N+1 que está matando la latencia hasta que un cliente se queja.
11. Runbook asociado a cada alerta. "API 5xx >1%" dispara una alerta en PagerDuty, Slack o donde sea. Esa alerta debe enlazar a un documento con los 5 pasos de diagnóstico: ¿está Postgres vivo? ¿el pool está lleno? ¿hubo deploy reciente? Sin runbook, la persona oncall pierde 20 minutos buscando por dónde empezar.
12. Experimento mensual de "kill -9". Una vez al mes, el equipo mata un proceso en staging deliberadamente y mide cuánto tarda el sistema en detectarlo, alertar, y recuperarse. Si las alertas tardan más de 2 minutos o el sistema no se recupera solo, hay trabajo pendiente.
Sistemas que pasan 10-12 de las 12 están operacionalmente maduros. Sistemas que pasan 4-6 necesitan 2-3 sprints de infraestructura antes de pensar en features. Sistemas que pasan 0-3 están volando ciegos y cada incidente los sorprende.
¿Cuántas de las 12 señales tiene tu backend?
Agendá 45 minutos por Meet y corremos las 12 señales contra tu código. Salís con el docker-compose.yml del stack OSS aplicado a tu stack y el cómo-implementar de cada señal que no pase. Todo self-hosted, cero SaaS de pago.
Agendar health-check →Stack OSS: OpenTelemetry + Prometheus + Grafana + Loki
El stack que reemplaza Datadog/New Relic/Honeycomb para el 90% de casos de PyME:
- OpenTelemetry (Apache 2.0): SDK para instrumentar la aplicación. Exporta logs, métricas y traces al formato OTLP.
- Prometheus (Apache 2.0): almacena métricas series-temporales, hace scraping.
- Grafana (AGPL 3.0): dashboards y alertas. Interfaz única para los tres pilares.
- Loki (AGPL 3.0): almacena logs indexados por labels, API compatible con Prometheus.
- Tempo (AGPL 3.0): almacena traces distribuidos, compatible con OTel.
Todo corre en un VPS de 4-8GB RAM. Un docker-compose.yml mínimo:
# docker-compose.yml
services:
prometheus:
image: prom/prometheus:latest
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
- prometheus-data:/prometheus
ports: ["9090:9090"]
loki:
image: grafana/loki:latest
volumes:
- ./loki-config.yml:/etc/loki/local-config.yaml:ro
- loki-data:/loki
ports: ["3100:3100"]
tempo:
image: grafana/tempo:latest
command: ["-config.file=/etc/tempo.yml"]
volumes:
- ./tempo-config.yml:/etc/tempo.yml:ro
- tempo-data:/var/tempo
ports: ["3200:3200", "4317:4317"]
grafana:
image: grafana/grafana:latest
environment:
- GF_SECURITY_ADMIN_PASSWORD=changeme
volumes:
- grafana-data:/var/lib/grafana
- ./grafana-datasources.yml:/etc/grafana/provisioning/datasources/datasources.yml:ro
ports: ["3001:3000"]
volumes:
prometheus-data: {}
loki-data: {}
tempo-data: {}
grafana-data: {}
Y la instrumentación de Node.js:
// otel.ts - importar PRIMERO en tu entry point
import { NodeSDK } from '@opentelemetry/sdk-node';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { PrometheusExporter } from '@opentelemetry/exporter-prometheus';
const sdk = new NodeSDK({
serviceName: 'orders-api',
traceExporter: new OTLPTraceExporter({
url: 'http://tempo:4318/v1/traces',
}),
metricReader: new PrometheusExporter({ port: 9464 }),
instrumentations: [getNodeAutoInstrumentations()],
});
sdk.start();
Logs estructurados con pino:
import pino from 'pino';
export const logger = pino({
level: process.env.LOG_LEVEL ?? 'info',
formatters: {
level: (label) => ({ level: label }),
},
base: { service: 'orders-api', env: process.env.NODE_ENV },
timestamp: pino.stdTimeFunctions.isoTime,
});
// uso:
logger.info({ userId, event: 'login' }, 'user logged in');
Con auto-instrumentations-node, automáticamente se instrumentan Express, HTTP, PostgreSQL (pg), Redis (ioredis), MongoDB, y 30+ librerías más. Sin tocar el código de negocio. Los spans se propagan automáticamente con traceId en los headers entre servicios.
¿Cuánto estás pagando por Datadog o New Relic?
Revisamos tu factura y tu uso real en 30 min por Meet. Te decimos qué features estás usando, cuáles no, y si migrar al stack OSS tiene sentido. Aunque no trabajemos juntos después, te quedás con los números.
Agendar revisión de costos →Las alertas mínimas antes de dormir tranquilo
Un backend en producción sin alertas es un sistema del que te enteras que fallaba cuando te escribe un cliente. Estas 5 alertas son el mínimo absoluto para una PyME seria:
Alerta 1: Error rate > 1% por 5 minutos. Regla Prometheus:
- alert: HighErrorRate
expr: |
sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
/ sum(rate(http_requests_total[5m])) by (service) > 0.01
for: 5m
annotations:
summary: "Error rate en {{$labels.service}} supera 1%"
runbook: "https://wiki.tuempresa.com/runbooks/high-error-rate"
Alerta 2: Latencia p95 > 1s por 10 minutos. Señal temprana de saturación o query lenta nueva.
Alerta 3: Saturación de pool PostgreSQL > 80%. Si el pool se llena, los próximos requests se quedan esperando y la cascada empieza.
Alerta 4: Disk usage > 80% en el servidor de base de datos. Postgres se rompe feo cuando llega a 100%. Quieres saberlo al 80% para planificar, no al 99% para correr.
Alerta 5: Uptime check desde ubicación externa falla. UptimeRobot es gratis para hasta 50 monitores y verifica desde fuera de tu infraestructura. Es la única alerta que sigue funcionando cuando tu Prometheus se cae.
Cada alerta debe tener un runbook asociado. Sin runbook, la alerta genera ansiedad sin acción.
Cuándo sí pagar por un SaaS
El stack OSS no es religión. Hay casos donde un SaaS pagado compensa:
- Equipo < 3 personas sin especialista de infra. No tenés a quién mantener el stack. El costo de una persona es mucho mayor al de Datadog.
- Compliance específico (SOC 2, HIPAA) que requiere auditoría de proveedor certificado.
- > 100 servicios con tráfico alto y tráfico volátil. El storage de Prometheus empieza a ser problema real, Datadog lo resuelve con agregación inteligente.
- Correlación avanzada con Real User Monitoring que el stack OSS no hace igual de bien.
Para el 90% de PyMEs mexicanas con backend Node.js y 5-20 servicios, el stack OSS cubre todo. La decisión real suele ser "¿tengo 3 horas una vez para montar esto y 1 hora al mes para mantenerlo?". Si la respuesta es sí, ahorrás varios miles de dólares al año.
"Migramos de Datadog a stack OSS en dos sprints. Bajamos la factura de observabilidad de 8 mil pesos mensuales a 600 pesos del VPS. Ganamos además control total sobre la retention y queries que antes eran imposibles con el plan contratado."
Conclusión
El health-check de 12 señales no es un ritual burocrático: es la forma más rápida de entender si un backend está operacionalmente listo para producción o está volando ciego. Pasarlo no requiere presupuesto enterprise. Requiere decisión técnica de instrumentar correctamente desde el día uno y un stack OSS bien elegido.
Lo que cubrimos:
- ✅ Las 12 señales del health-check con umbrales específicos
- ✅ Tres pilares: logs, métricas, traces
- ✅ Stack OSS completo con docker-compose funcional
- ✅ Instrumentación Node.js con OpenTelemetry en 10 líneas
- ✅ 5 alertas mínimas con reglas Prometheus
- ✅ Cuándo sí pagar por un SaaS
¿Querés las 12 señales aplicadas a tu backend?
Te corremos el health-check contra tu código real en 45 minutos por Meet. Dos devs revisando tu stack. Te dejamos un documento con las señales que pasás, las que no, y las 3 intervenciones de mayor impacto. Sin pitch, sin seguimiento invasivo.
Agendar health-check técnico →