Disenador de Instrumentacion de Logs

El Problema

La mayoria del logging es reactivo — los desarrolladores agregan console.log despues de que aparece un bug y lo eliminan despues del fix. Esto significa que el SIGUIENTE bug requerira otra ronda de agregar logs, deployar, esperar reproduccion, leer logs e iterar. El logging estrategico, disenado de antemano, significa que cada bug futuro viene pre-instrumentado con los datos que necesitas para diagnosticarlo. La diferencia entre “necesito 3 ciclos de deploy para encontrar este bug” y “puedo diagnosticarlo desde la primera ocurrencia.”

El Prompt

Eres un arquitecto de logging y observabilidad. Disena un plan de instrumentacion de logging estrategico:

APLICACION: [tipo, framework, arquitectura]
FLUJOS CRITICOS: [lista los user journeys y operaciones de sistema mas importantes]
LOGGING ACTUAL: [describe la situacion actual de logging]
DESTINO DE LOGS: [stdout, archivo, CloudWatch, Datadog, ELK, Sentry]

Disena la instrumentacion de logging:
1. **Estrategia de Niveles de Log**: Define exactamente que va en cada nivel — ERROR, WARN, INFO, DEBUG. Con ejemplos concretos para esta aplicacion.
2. **Schema de Log Estructurado**: Disena el formato JSON con campos obligatorios: timestamp, level, service, requestId, userId, action, duration, metadata.
3. **Estrategia de Correlacion**: Disena la propagacion de request ID / trace ID — como hilar un solo ID a traves de requests HTTP, colas de mensajes, jobs de background y llamadas a base de datos.
4. **Ubicacion Estrategica de Logs**: Para cada flujo critico, identifica los 5-7 puntos exactos de log que capturan el ciclo de vida del flujo.
5. **Contexto de Performance**: Cada log a nivel INFO o superior debe incluir datos de timing. Disena el patron para capturar duraciones.
6. **Patrones para Alertas**: Define que patrones de log deben disparar alertas — no solo errores, sino patrones de anomalias.

Ejemplo de Salida

Schema de Log: { timestamp, level, service: "order-api", requestId, userId, action: "checkout.complete", durationMs: 1247, metadata: { orderId, itemCount } }
Correlacion: Header X-Request-Id propagado via middleware → almacenado en AsyncLocalStorage → auto-inyectado en cada log
Ubicaciones estrategicas para flujo de Checkout:
  1. INFO "checkout.started" — {userId, cartItemCount, cartTotal}
  2. INFO "payment.initiated" — {provider, amount, currency}
  3. INFO "payment.completed" — {transactionId, durationMs}
  4. WARN "inventory.low" — {sku, remaining} (solo si stock < umbral)
  5. ERROR "payment.failed" — {provider, errorCode, errorMessage}
  6. INFO "checkout.completed" — {orderId, totalDurationMs}
Patrones de alerta: tasa de payment.failed > 5% en 5min, p95 de checkout.completed > 10s

Cuando Usar

Usa este skill al configurar logging para un nuevo proyecto, cuando tu logging actual es inadecuado para depurar issues de produccion, o cuando necesitas mejorar la observabilidad sin agregar ruido. Esencial antes de lanzar a produccion.

Tips Pro

• Loggea en las fronteras, no dentro de funciones — loggea cuando datos entran a tu sistema, cuando llamas sistemas externos, y cuando datos salen. Las llamadas internas rara vez necesitan logging.
• Usa logging estructurado desde el dia uno — console.log('Usuario creado:', userId) no es buscable. logger.info({ action: 'user.created', userId }) es filtrable y alertable.
• Los IDs de correlacion son innegociables — sin un request ID que hile cada log, correlacionar entradas entre servicios durante un incidente es buscar una aguja en un pajar.
• Loggea el POR QUE de las decisiones — “Request rechazado” es inutil. “Request rechazado: rate limit excedido, userId=42, requestCount=101, limit=100” te dice todo.