Por qué necesitás logs realistas en testing
Los logs sintéticos son esenciales para probar herramientas de monitoreo, parsers, alertas y dashboards sin depender de producción. Casos de uso críticos: validar que tu sistema de alertas detecta patrones de error, testear agregadores como ELK Stack o Splunk con volumen realista, entrenar modelos de ML para detección de anomalías, y simular escenarios de troubleshooting en ambientes de capacitación.
Un error común es generar logs demasiado simples ('Error occurred', 'Success') que no representan la complejidad real. Los logs de producción incluyen stack traces, IDs de transacción, métricas de latencia, códigos de estado HTTP, nombres de servicios, y contexto específico. Un log realista como '[ERROR] Database connection pool exhausted. Max connections: 50' te permite testear reglas de alerta más precisas que uno genérico.
Niveles de severidad y cuándo usarlos
La jerarquía estándar de logs sigue un orden: DEBUG < INFO < WARN < ERROR < FATAL. En producción, DEBUG suele desactivarse por volumen, pero es vital en desarrollo para seguir el flujo de ejecución. INFO registra operaciones normales importantes (logins, transacciones completadas, deployments). WARN señala situaciones anómalas que no rompen la aplicación pero requieren atención (certificado próximo a vencer, cache miss rate alto, queries lentas).
ERROR indica fallos que impiden completar una operación específica pero no caen toda la aplicación (payment declined, database timeout, file not found). FATAL son errores irrecuperables que requieren restart. Un error clásico de logging: logear todo como ERROR. Si el 90% de tus logs son errores, perdés la capacidad de distinguir problemas reales. La regla práctica: si no requiere acción humana inmediata, probablemente sea WARN, no ERROR.
Para testing, generá distribuciones realistas: 70% INFO, 20% DEBUG, 8% WARN, 2% ERROR. En producción saludable, los errores son la excepción, no la norma.
Anatomía de un log estructurado
Los logs modernos siguen formatos estructurados (JSON preferiblemente) para facilitar parsing y búsqueda. Componentes esenciales:
- Timestamp: ISO 8601 con timezone (2024-01-15T14:23:45.123Z)
- Level: severidad del mensaje (ERROR, WARN, INFO, DEBUG)
- Message: descripción human-readable del evento
- Context: datos estructurados (user_id, request_id, service_name)
- Source: módulo o función que generó el log (UserService.login)
- Metadata: stack traces, duración, códigos de error
Ejemplo JSON: {"timestamp":"2024-01-15T14:23:45Z","level":"ERROR","message":"Payment failed","context":{"user_id":7821,"transaction_id":"txn_9f72","amount":49.99,"error_code":"card_declined"}}
Los logs en texto plano dificultan el análisis automatizado. Si tu sistema todavía genera logs tipo '[Mon Jan 15 14:23:45] Error in line 247', considerá migrar a JSON estructurado.
Prácticas para logs útiles y mantenibles
Regla de oro: logeá el contexto suficiente para reproducir el problema. No sirve '[ERROR] Payment failed' sin saber qué pago, de qué usuario, con qué método. Incluí siempre identificadores únicos (request_id, user_id, transaction_id) que permitan correlacionar eventos entre servicios.
Evitá logs sensibles: nunca logees contraseñas, tokens completos (truncá a primeros 8 chars), números de tarjeta, o PII sin enmascarar. En Europa, GDPR te puede multar fuertemente por logs no seguros. Usá '[REDACTED]' o hash cuando necesités referenciar datos sensibles.
Performance: logging excesivo mata aplicaciones. DEBUG en loops que procesan 10,000 items genera gigas de logs y frena I/O. Usá log levels apropiados y desactivá DEBUG en producción. Considerá log sampling: para operaciones de alto volumen, logeá 1 cada 100.
Rotación y retención: configurá rotación diaria o por tamaño (100MB). Retené logs críticos (ERROR/WARN) por 90 días, INFO por 30, DEBUG por 7. Archivá a S3/GCS para análisis histórico barato.