Skip to content
NeuralSkills
Despliegue

Arquitecto de Agregacion de Logs

Diseña sistemas de logging centralizados que hacen realmente posible encontrar la aguja en el pajar de logs.

Avanzado Gratis Publicado: 15 de abril de 2026
Herramientas Compatibles claude-codechatgptgeminicopilotcursorwindsurfuniversal

El Problema

Tus logs estan dispersos en 15 servidores, cada uno con formatos diferentes, periodos de retencion diferentes y sin forma de correlacionar eventos entre servicios. Cuando ocurre un incidente, te conectas por SSH a las maquinas una por una, buscas con grep en gigabytes de texto no estructurado e intentas armar lo que paso. Una solicitud que toca 5 servicios genera 5 entradas de log separadas sin identificador compartido para conectarlas.

El Prompt

Eres un arquitecto de logging y observabilidad. Diseña un sistema de logging centralizado para mi infraestructura.

INFRAESTRUCTURA:
- Servicios: [ej., 3 APIs Node.js, 1 worker Python, 2 microservicios Go]
- Despliegue: [ej., Kubernetes, Docker Compose, EC2, serverless]
- Volumen actual de logs: [ej., ~10GB/dia, desconocido]
- Enfoque actual: [ej., console.log a stdout, archivos en disco, CloudWatch]
- Presupuesto: [ej., self-hosted, servicio gestionado hasta $X/mes]

Diseña la arquitectura de logging:
1. **Estandar de formato de log**: Define un formato estructurado (JSON) con campos obligatorios — timestamp, level, service, traceId, message, context.
2. **Pipeline de recoleccion**: Como fluyen los logs de aplicacion → recolector → almacenamiento.
3. **Almacenamiento y retencion**: Donde almacenar logs, cuanto tiempo conservarlos, estrategia de almacenamiento escalonado.
4. **Correlacion**: Como rastrear una solicitud unica a traves de multiples servicios usando IDs de correlacion.
5. **Busqueda y consulta**: Como buscar efectivamente — indices, filtros, consultas guardadas para investigaciones comunes.
6. **Alertas basadas en logs**: Alertas basadas en patrones — detectar picos de errores, mensajes de error especificos, eventos de seguridad.
7. **Recomendacion de herramientas**: ELK vs Loki+Grafana vs CloudWatch vs Datadog para mi escala y presupuesto.

Ejemplo de Salida

Formato de log (todos los servicios):
{"timestamp":"2026-04-15T10:30:00Z","level":"error","service":"user-api","traceId":"abc-123","message":"Timeout de conexion a base de datos","context":{"query":"SELECT * FROM users","duration_ms":5000,"pool_size":10,"active_connections":10}}

Pipeline: App (stdout JSON) → Fluentd DaemonSet → Loki → Grafana
Retencion: 30 dias caliente (Loki), 90 dias frio (S3), eliminacion despues de 1 año
Correlacion: Header X-Request-ID propagado a traves de todos los servicios, logueado como traceId
Alerta: Regla de alerta Loki si count_over_time({level="error"}[5m]) > 50

Cuando Usarlo

Usa este skill cuando administres mas de 2 servicios, cuando depurar requiera conectarse por SSH a servidores, o despues de un incidente donde no pudiste encontrar los logs relevantes. Esencial antes de escalar a microservicios donde el distributed tracing se vuelve una necesidad.

Consejos Pro

  • Logs JSON estructurados desde el dia uno — adaptar logging estructurado a una aplicacion existente es doloroso. Inicia cada servicio nuevo con logs estructurados en JSON.
  • Siempre incluye un trace/correlation ID — genera un UUID en el borde (API gateway, primer servicio) y propagalo a traves de cada llamada downstream. Sin el, la depuracion distribuida es imposible.
  • Loguea en el nivel correcto — DEBUG solo para desarrollo, INFO para operaciones normales, WARN para problemas recuperables, ERROR para fallos que requieren atencion. Sobre-loguear en nivel INFO es costoso.
  • Establece politicas de retencion desde el inicio — los logs crecen rapido. Sin politicas, los costos de almacenamiento te sorprenderan. 30 dias para busqueda activa, 90 dias comprimidos, eliminar despues de un año es un default razonable.