Workers en Segundo Plano

ReliaPulse usa workers BullMQ para procesamiento en segundo plano. Los workers corren como procesos separados y manejan tareas que consumen tiempo de forma asíncrona.

Arquitectura de Workers

┌─────────────────────────────────────────────────────────────┐
│                      Redis (BullMQ)                          │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐          │
│  │   uptime    │  │   metrics   │  │notifications│  ...     │
│  │   queue     │  │   queue     │  │   queue     │          │
│  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘          │
└─────────┼────────────────┼────────────────┼─────────────────┘
          │                │                │
          ▼                ▼                ▼
    ┌───────────┐    ┌───────────┐    ┌───────────┐
    │  Uptime   │    │  Metrics  │    │Notification│
    │  Worker   │    │  Worker   │    │  Worker   │
    └───────────┘    └───────────┘    └───────────┘

Workers Disponibles

Uptime Worker

Realiza health checks HTTP en componentes tipo ENDPOINT.

Nombre de Cola: uptime

Tipos de Trabajo:

check - Ejecución de un health check
schedule - Programar checks recurrentes

Flujo de Proceso:

1. Recibir trabajo con componentId
2. Obtener configuración del componente
3. Construir request HTTP (método, headers, body)
4. Ejecutar request con timeout
5. Evaluar condiciones (código de estado, body, tiempo de respuesta)
6. Actualizar estado del componente
7. Crear incidente si se exceden umbrales
8. Encolar notificaciones si cambió el estado

Metrics Worker

Consulta métricas externas de integraciones (Datadog, Prometheus, etc.).

Nombre de Cola: metrics

Tipos de Trabajo:

poll - Obtener métricas de integración
schedule - Programar polls recurrentes

Flujo de Proceso:

1. Recibir trabajo con metricsQueryId
2. Cargar config de integración y query
3. Llamar adaptador de integración
4. Parsear respuesta y extraer valores
5. Almacenar data points
6. Evaluar umbrales
7. Actualizar estado de componente si está vinculado
8. Disparar recálculo de métricas calculadas

Integraciones Soportadas:

Prometheus (PromQL)
Datadog (DQL)
New Relic (NRQL)
Grafana (varios datasources)
Pingdom (estado de checks)

Notification Worker

Entrega notificaciones a través de varios canales.

Nombre de Cola: notifications

Tipos de Trabajo:

send - Enviar notificación individual
broadcast - Enviar a todos los suscriptores

Canales:

Canal	Método de Entrega
Email	API de Resend
SMS	API de Twilio
Slack	Webhook con Block Kit
Discord	Webhook con embeds
Teams	Webhook con Adaptive Cards
Webhook	HTTP POST personalizado
Push	Web Push API

On-Call Worker

Maneja alertas on-call y escalaciones.

Nombre de Cola: oncall

Tipos de Trabajo:

alert - Crear y entregar alerta on-call
escalate - Escalar alerta no reconocida

Flujo de Proceso:

1. Recibir trabajo de alerta
2. Determinar respondedor on-call actual
3. Crear registro OnCallAlert
4. Enviar notificación (SMS, email, push)
5. Esperar reconocimiento
6. Si timeout, escalar al siguiente nivel
7. Repetir hasta reconocimiento o max escalaciones

Cleanup Worker

Elimina datos antiguos para gestionar el tamaño de la base de datos.

Nombre de Cola: cleanup

Programación: Diariamente a medianoche

Datos Limpiados:

ExtractedValueDataPoint - 7 días
CalculatedMetricDataPoint - 7 días
MetricDataPoint - 30 días (configurable)
UptimeCheck - 90 días

Calculated Metrics Worker

Recalcula métricas calculadas cuando cambian los datos fuente.

Nombre de Cola: calculated-metrics

Eventos Disparadores:

ExtractedValue actualizado (desde uptime checks)
Valor de MetricsQuery actualizado (desde polling de métricas)

Flujo de Proceso:

1. Recibir trabajo con calculatedMetricId
2. Cargar fórmula y mapeo de variables
3. Obtener últimos valores de todas las variables
4. Evaluar fórmula con mathjs
5. Almacenar resultado como data point
6. Actualizar lastValue y estado

Programación de Trabajos

Trabajos Recurrentes

Los workers programan sus propios trabajos recurrentes:

// Uptime worker programa checks
await uptimeQueue.add(
  'schedule',
  { componentId },
  {
    repeat: {
      every: component.checkInterval * 1000,
    },
    jobId: `uptime-${componentId}`,
  }
);

Prioridad de Trabajos

Trabajos con mayor prioridad se procesan primero:

await queue.add('urgent-notification', data, {
  priority: 1, // Número menor = mayor prioridad
});

Lógica de Reintentos

Trabajos fallidos se reintentan con backoff exponencial:

{
  attempts: 3,
  backoff: {
    type: 'exponential',
    delay: 1000, // 1s, 2s, 4s
  },
}

Configuración de Workers

Variables de Entorno

# Conexión Redis
REDIS_URL=redis://localhost:6379
 
# Concurrencia de workers
WORKER_CONCURRENCY=10
 
# Nivel de log
LOG_LEVEL=info

Concurrencia

Cada tipo de worker tiene concurrencia configurable:

const worker = new Worker('uptime', processJob, {
  concurrency: 10, // Procesar 10 trabajos simultáneamente
});

Apagado Graceful

Los workers manejan SIGTERM para apagado graceful:

process.on('SIGTERM', async () => {
  await worker.close();
  process.exit(0);
});

Monitoreo de Workers

Health Check

Los workers exponen estado de salud:

// Verificar si el worker está procesando
const isRunning = worker.isRunning();
const isPaused = worker.isPaused();

Eventos de Trabajos

Los workers emiten eventos para monitoreo:

worker.on('completed', (job) => {
  log.info({ jobId: job.id }, 'Trabajo completado');
});
 
worker.on('failed', (job, err) => {
  log.error({ jobId: job.id, err }, 'Trabajo fallido');
});

Métricas de Cola

BullMQ proporciona estadísticas de cola:

const counts = await queue.getJobCounts();
// { waiting: 10, active: 2, completed: 100, failed: 5 }

Logging

Los workers usan logging JSON estructurado:

{
  "level": "info",
  "time": "2026-01-24T12:00:00.000Z",
  "worker": "uptime",
  "jobId": "job-123",
  "organizationId": "org-456",
  "componentId": "comp-789",
  "msg": "Health check completado"
}

Despliegue Docker

Los workers corren como un contenedor separado:

# docker-compose.yml
services:
  worker:
    build: .
    command: npm run worker
    environment:
      - REDIS_URL=redis://redis:6379
      - DATABASE_URL=${DATABASE_URL}
    depends_on:
      - redis
      - db

Escalando Workers

Escalado Horizontal

Añadir más contenedores worker para mayor throughput:

# docker-compose.yml
services:
  worker:
    deploy:
      replicas: 3

Aislamiento de Colas

Ejecutar workers separados para diferentes colas:

services:
  worker-uptime:
    command: npm run worker:uptime
  worker-notifications:
    command: npm run worker:notifications

Mejores Prácticas

Idempotencia - Los trabajos deben ser seguros para reintentar
Timeouts - Establecer timeouts apropiados
Manejo de Errores - Loguear errores con contexto
Monitoreo - Rastrear profundidad de cola y tiempo de procesamiento
Backpressure - Limitar tamaño de cola para prevenir problemas de memoria

Esquema de Base de Datos Caching con Redis