Diagnosticar errores 500/502/504 y latencias con logs: método rápido para DevOps

Contexto y objetivo

En producción, un error 500 puede ser código, base de datos, timeouts o saturación. Con Nginx/Apache puedes extraer señales claras: tiempos, endpoints lentos, upstream failures y correlación con picos.

Aprender a buscar patrones y aplicar correcciones: caché, límites, optimización y alertas.

Pasos recomendados

Mira primero el error log: suele indicar el motivo (upstream timeout, connection refused, PHP fatal). Luego usa access log para ver rutas afectadas.

Si los errores se concentran en un endpoint, perfila ese endpoint: DB, llamadas externas, serialización grande, etc.

Añade tiempos en el log para identificar si el problema es latencia (request_time alto) o error inmediato.

Aplica caché donde tenga sentido: assets, respuestas públicas, y resultados repetidos.

Si hay dependencia externa (API), añade timeouts y reintentos controlados; usa circuit breaker para evitar cascadas.

Errores típicos y cómo evitarlos

No tener correlation id y no poder unir logs app/server.

Time-out infinito en upstream: bloqueas workers.

Loggear demasiado en nivel debug en prod: saturas disco.

No separar picos normales de ataques o scrapes.

Cambiar config sin medir: siempre valida con métricas.

Ejemplos prácticos con código

# Nginx - log_format con tiempos
log_format timed '$remote_addr - $time_local "$request" $status $request_time $upstream_response_time "$http_user_agent"';

# Extraer 500/502 y endpoints
grep ' 50[0-9] ' /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -nr | head

// Node.js - añadir correlation id
app.use((req,res,next)=>{
  req.id = crypto.randomUUID();
  res.setHeader("X-Request-Id", req.id);
  next();
});

Checklist final para producción

• Añade request_time/upstream_time en logs.
• Identifica endpoints lentos (p95/p99).
• Busca correlación con picos de tráfico/bots.
• Revisa logs de error junto a access log.
• Implementa mitigaciones: caché, colas, circuit breaker.