Detectar errores en producción puede convertirse en una tarea compleja si no tienes tus logs organizados por aplicación. Cuando una app de Django falla después de un despliegue, saber exactamente dónde buscar marca la diferencia entre resolver el problema en minutos o perder horas revisando archivos mezclados.
¿Por qué es fundamental separar los logs en producción?
Las aplicaciones Python desplegadas con NGINX y UWSGI generan registros constantemente. Sin embargo, por defecto estos logs se almacenan en archivos genéricos compartidos por todos los sitios del servidor. Esto significa que, cuando algo falla, debes filtrar entre cientos de líneas que no corresponden a tu aplicación.
Agrupar los logs por aplicación permite:
- Identificar errores rápidamente sin mezclar información de otros sitios.
- Hacer debugging efectivo directamente desde la terminal.
- Mantener un historial limpio de cada aplicación desplegada.
¿Cómo simular un error y diagnosticarlo con logs?
Al cambiar de rama en un repositorio Git, por ejemplo de main a develop, es común que los nuevos cambios incluyan migraciones, nuevas dependencias en el archivo requirements o modificaciones en la configuración [01:37]. Después de hacer pull y cambiar de rama, es necesario verificar qué archivos cambiaron.
El flujo correcto al hacer un despliegue manual incluye:
- Activar el entorno virtual con
source .bin/activate.
- Ejecutar
pip install -r requirements.txt para instalar nuevas dependencias.
- Reiniciar UWSGI con
sudo service uwsgi restart.
Al recargar la aplicación en el navegador, puede aparecer un error 400 [03:15]. Para revisar qué ocurrió, se usa el comando cat sobre el archivo de log de UWSGI ubicado en /var/log/uwsgi/app/.
¿Cuándo activar el modo debug en Django?
Si el log de UWSGI solo muestra un código de error sin detalles, se puede habilitar temporalmente la variable DEBUG = True en el archivo settings de Django [03:55]. Esto expone información detallada del error en el navegador, como rutas faltantes o dominios no configurados en ALLOWED_HOSTS.
Importante: nunca dejes DEBUG = True en producción. Cuando está habilitado, cualquier usuario puede ver la IP del servidor, certificados, variables de entorno y rutas internas, información que podría usarse de forma maliciosa [05:22].
¿Cómo se resolvió el error en este caso?
El problema fue que al cambiar de rama, el archivo de configuración perdió el dominio en ALLOWED_HOSTS [04:35]. La solución fue editar nuevamente el archivo settings, agregar el dominio correcto, guardar y reiniciar UWSGI.
¿Cómo configurar logs separados en NGINX por aplicación?
Para agrupar los logs, se edita el archivo de configuración del sitio en /etc/nginx/sites-enabled/ con permisos de superusuario [06:15]. Dentro del bloque server se agregan dos directivas:
nginx
access_log /var/log/nginx/deploy_with_python_access.log;
error_log /var/log/nginx/deploy_with_python_error.log;
La directiva access_log registra todas las peticiones que recibe el servidor, incluyendo el user agent y el código de respuesta. La directiva error_log captura únicamente los errores [06:45].
Después de guardar, se valida la configuración con sudo nginx -t y se reinicia el servicio con sudo service nginx restart [07:35].
Al acceder a /var/log/nginx/, aparecen los dos nuevos archivos creados exclusivamente para la aplicación.
¿Qué es el comando tail y cómo usarlo para debugging en tiempo real?
El comando tail devuelve las últimas líneas de un archivo. Al combinarlo con la bandera -f (follow), se queda escuchando cambios en tiempo real [08:00]:
bash
tail -f /var/log/nginx/deploy_with_python_access.log
Cada vez que alguien hace una petición al sitio, la terminal muestra el request al instante, permitiendo monitorear la actividad del servidor sin necesidad de abrir el archivo completo.
Como reto, configura UWSGI para que también guarde sus logs en un archivo específico por aplicación, replicando la misma lógica de separación que aplicamos en NGINX. ¿Ya lo intentaste? Comparte tu experiencia en los comentarios.
