Monitoreo y alertas de producción: la guía de configuración completa

El incidente de producción promedio cuesta $5,600 por minuto de tiempo de inactividad. Las empresas con monitoreo maduro detectan problemas en menos de 5 minutos, mientras que aquellas sin monitoreo tardan un promedio de 197 minutos en detectarse: la diferencia entre un problema menor y una catástrofe con pérdida de clientes.

Esta guía cubre la configuración del monitoreo de producción de un extremo a otro: qué medir, cómo recopilarlo, dónde visualizarlo y cuándo alertar.

Conclusiones clave

• Los tres pilares de la observabilidad (métricas, registros, seguimientos) tienen diferentes propósitos y los tres son necesarios.
• Alerta sobre síntomas (tasa de error, latencia) y no causas (uso de CPU) para reducir el ruido en un 80%
• Los runbooks adjuntos a cada alerta garantizan una respuesta consistente a incidentes independientemente de quién esté de guardia
• Comience con 5 alertas esenciales y amplíelas solo cuando comprenda la línea de base

---

Los tres pilares de la observabilidad

Métricas

Mediciones numéricas muestreadas a lo largo del tiempo. Las métricas responden "¿qué está pasando ahora mismo?"

Métricas de aplicación:

• Tasa de solicitud (solicitudes por segundo)
• Tasa de error (5xx respuestas por segundo)
• Distribución de latencia (P50, P95, P99)
• Sesiones activas/usuarios concurrentes

Métricas de infraestructura:

• Utilización de CPU por servicio
• Uso de memoria y recolección de basura.
• E/S de disco y espacio disponible
• Rendimiento de la red

Métricas comerciales:

• Órdenes por minuto
• Tasa de abandono del carrito
• Ingresos por hora
• Llamadas API por punto final

Registros

Registros estructurados y con marca de tiempo de eventos discretos. Los registros responden "¿por qué sucedió?"

{
  "timestamp": "2026-03-16T14:32:01.234Z",
  "level": "error",
  "service": "api",
  "requestId": "req_abc123",
  "userId": "usr_456",
  "message": "Payment processing failed",
  "error": "Stripe API timeout after 30000ms",
  "endpoint": "POST /billing/checkout",
  "duration": 30142
}

Registro de mejores prácticas:

• Utilice registro JSON estructurado, no texto sin formato
• Incluir ID de correlación (requestId) entre servicios
• Registrar en niveles apropiados (ERROR para fallas, ADVERTENCIA para degradación, INFORMACIÓN para eventos clave)
• Nunca registres datos confidenciales (contraseñas, tokens, números completos de tarjetas de crédito)

Rastros

Rutas de solicitud de un extremo a otro a través de sistemas distribuidos. Los rastros responden "¿dónde está el cuello de botella?"

La solicitud de un solo usuario para realizar un pago en un comercio electrónico puede incluir:

1. Nginx (2 ms) a la interfaz Next.js (50 ms) a NestJS API (120 ms) a PostgreSQL (45 ms) a Stripe API (800 ms) a servicio de correo electrónico (200 ms)

Sin seguimiento, verá "el pago tarda 1,2 segundos". Con el seguimiento, verá "La API de Stripe representa el 67% de la latencia de pago".

---

Configuración de la pila de monitoreo

Prometheus + Grafana (autohospedado)

# docker-compose.monitoring.yml
services:
  prometheus:
    image: prom/prometheus:v2.50.0
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus-data:/prometheus
    ports:
      - "9090:9090"
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=30d'
      - '--web.enable-lifecycle'

  grafana:
    image: grafana/grafana:10.3.0
    volumes:
      - grafana-data:/var/lib/grafana
    ports:
      - "3030:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=${GRAFANA_PASSWORD}
      - GF_USERS_ALLOW_SIGN_UP=false

  loki:
    image: grafana/loki:2.9.0
    volumes:
      - loki-data:/loki
    ports:
      - "3100:3100"

  alertmanager:
    image: prom/alertmanager:v0.27.0
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml
    ports:
      - "9093:9093"

volumes:
  prometheus-data:
  grafana-data:
  loki-data:

Configuración de Prometeo

# prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - "alerts/*.yml"

alerting:
  alertmanagers:
    - static_configs:
        - targets: ["alertmanager:9093"]

scrape_configs:
  - job_name: "api"
    metrics_path: /metrics
    static_configs:
      - targets: ["api:3001"]

  - job_name: "node-exporter"
    static_configs:
      - targets: ["node-exporter:9100"]

  - job_name: "postgres"
    static_configs:
      - targets: ["postgres-exporter:9187"]

  - job_name: "redis"
    static_configs:
      - targets: ["redis-exporter:9121"]

---

Métricas de la aplicación NestJS

Exponiendo las métricas de Prometheus

// metrics.module.ts
import { Module } from '@nestjs/common';
import { PrometheusModule } from '@willsoto/nestjs-prometheus';
import {
  makeCounterProvider,
  makeHistogramProvider,
  makeGaugeProvider,
} from '@willsoto/nestjs-prometheus';

@Module({
  imports: [
    PrometheusModule.register({
      path: '/metrics',
      defaultMetrics: { enabled: true },
    }),
  ],
  providers: [
    makeCounterProvider({
      name: 'http_requests_total',
      help: 'Total HTTP requests',
      labelNames: ['method', 'path', 'status'],
    }),
    makeHistogramProvider({
      name: 'http_request_duration_seconds',
      help: 'HTTP request duration in seconds',
      labelNames: ['method', 'path'],
      buckets: [0.01, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10],
    }),
    makeGaugeProvider({
      name: 'active_connections',
      help: 'Number of active connections',
    }),
  ],
  exports: [PrometheusModule],
})
export class MetricsModule {}

---

Configuración de alerta

Las cinco alertas esenciales

Todo sistema de producción necesita estas alertas desde el primer día:

# alerts/essential.yml
groups:
  - name: essential
    rules:
      - alert: ServiceDown
        expr: up == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Service {{ $labels.job }} is down"
          runbook: "https://wiki.example.com/runbooks/service-down"

      - alert: HighErrorRate
        expr: |
          rate(http_requests_total{status=~"5.."}[5m])
          / rate(http_requests_total[5m]) > 0.01
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Error rate above 1% for 5 minutes"
          runbook: "https://wiki.example.com/runbooks/high-error-rate"

      - alert: HighLatency
        expr: |
          histogram_quantile(0.95,
            rate(http_request_duration_seconds_bucket[5m])
          ) > 2
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "P95 latency above 2 seconds"

      - alert: DiskSpaceLow
        expr: |
          node_filesystem_avail_bytes{mountpoint="/"}
          / node_filesystem_size_bytes{mountpoint="/"} < 0.2
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Disk space below 20% on {{ $labels.instance }}"

      - alert: SSLCertExpiringSoon
        expr: |
          probe_ssl_earliest_cert_expiry - time() < 14 * 24 * 3600
        labels:
          severity: warning
        annotations:
          summary: "SSL certificate expires within 14 days"

Enrutamiento de alerta

# alertmanager.yml
global:
  slack_api_url: "${SLACK_WEBHOOK_URL}"

route:
  group_by: ['alertname', 'severity']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'default'
  routes:
    - match:
        severity: critical
      receiver: 'pagerduty'
      repeat_interval: 15m
    - match:
        severity: warning
      receiver: 'slack'

receivers:
  - name: 'default'
    slack_configs:
      - channel: '#alerts'
        title: '{{ .GroupLabels.alertname }}'
        text: '{{ .CommonAnnotations.summary }}'

  - name: 'pagerduty'
    pagerduty_configs:
      - routing_key: "${PAGERDUTY_KEY}"
        severity: '{{ .GroupLabels.severity }}'

  - name: 'slack'
    slack_configs:
      - channel: '#alerts-warnings'
        title: '{{ .GroupLabels.alertname }}'

Reglas de calidad de alerta

---

Paneles de control de Grafana

Jerarquía del panel

1. Panel de control general: estado de alto nivel en todos los servicios. Esta es la primera pantalla que alguien mira durante un incidente.
2. Paneles de servicio: Métricas detalladas para cada servicio (API, web, trabajadores).
3. Paneles de infraestructura: métricas a nivel de nodo (CPU, memoria, disco, red).
4. Paneles de control empresarial: ingresos, pedidos, actividad de los usuarios.

El método RED para paneles de servicio

Para cada servicio, muestre:

• Rate: solicitudes por segundo
• Errores: Tasa de error como porcentaje
• Duración: Distribución de latencia (P50, P95, P99)

Esto proporciona visibilidad instantánea del estado del servicio sin sobrecarga cognitiva.

---

Seguimiento de errores con Sentry

// sentry.config.ts
import * as Sentry from '@sentry/nestjs';

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.NODE_ENV,
  tracesSampleRate: 0.1,
  profilesSampleRate: 0.1,
  integrations: [
    Sentry.postgresIntegration(),
  ],
  beforeSend(event) {
    // Strip sensitive data
    if (event.request?.headers) {
      delete event.request.headers['authorization'];
      delete event.request.headers['cookie'];
    }
    return event;
  },
});

Centinela proporciona:

• Agrupación automática de errores y deduplicación.
• Apilar trazas con mapas fuente.
• Seguimiento de versiones (qué implementación introdujo el error)
• Monitoreo del desempeño (rastreos de transacciones)

---

Preguntas frecuentes

¿Cuánto cuesta una pila de monitoreo?

Autohospedado (Prometheus + Grafana + Loki): aproximadamente entre 50 y 100 dólares al mes para los recursos de alojamiento. Alternativas administradas: Datadog comienza en $15/host/mes para infraestructura, más $0,10/GB para registros. Sentry Cloud cuesta $ 26 al mes para el plan de equipo. Un presupuesto inicial razonable para una pequeña empresa es de 100 a 200 dólares al mes en total.

¿Cuál es la diferencia entre monitoreo y observabilidad?

El monitoreo le avisa cuando algo anda mal. La observabilidad te dice por qué. El monitoreo consiste en paneles predefinidos y alertas para modos de falla conocidos. La observabilidad se trata de la capacidad de hacer preguntas arbitrarias sobre el comportamiento de su sistema utilizando métricas, registros y seguimientos. Necesita ambos, pero el seguimiento es la base.

¿Cómo evitamos la fatiga por alerta?

Tres reglas: (1) cada alerta debe requerir acción humana, (2) establecer umbrales basados ​​en líneas de base reales, no en ideales teóricos, (3) revisar y ajustar las alertas mensualmente. Si una alerta se activa más de una vez por semana sin que sea necesario realizar ninguna acción, solucione el problema subyacente o aumente el umbral. Los equipos que sufren fatiga de alertas ignoran todas las alertas, incluidas las críticas.

¿Deberíamos monitorear nuestro sistema ERP de manera diferente?

Los sistemas ERP tienen requisitos de monitoreo únicos. Más allá de las métricas web estándar, supervise: el uso del grupo de conexiones de la base de datos, la profundidad de la cola de trabajos en segundo plano, el estado de sincronización de la integración (Shopify, pasarelas de pago), el tiempo de ejecución de informes programado y el recuento de sesiones de usuario por módulo. ECOSIRE proporciona monitoreo administrado de Odoo como parte de nuestros paquetes de soporte.

---

¿Qué viene después?

El monitoreo son los ojos y oídos de su infraestructura de producción. Combínelo con automatización de CI/CD para lograr confianza en la implementación y planificación de recuperación ante desastres para brindar resiliencia. Para obtener una hoja de ruta completa de DevOps, consulte nuestra guía de DevOps para pequeñas empresas.

Comuníquese con ECOSIRE para monitorear la configuración y los servicios de infraestructura administrados.

---

Publicado por ECOSIRE: ayuda a las empresas a ver lo que importa en la producción.