Cuando despliegas una aplicación Python en producción, los logs separados por aplicación en NGINX y uWSGI se vuelven tu mejor herramienta de debugging. Te permiten detectar fallos rápido sin mezclar información entre sitios y entender qué pasa cuando algo se rompe tras un deploy.

¿Por qué necesitas separar los logs por aplicación?

Un servidor suele alojar varios sitios. Si todos escriben en el mismo archivo, encontrar el error específico de tu app se vuelve una pesadilla.

Cuando agrupas los logs por location, ganas tres cosas concretas:

• Aíslas los errores de cada aplicación en archivos propios.
• Reduces el tiempo de diagnóstico cuando un deploy falla.
• Evitas exponer información sensible al usuario final.

¿Qué es un log en NGINX? Es un archivo donde el servidor registra cada request recibido y cada error generado. NGINX maneja dos tipos: access log (peticiones exitosas) y error log (fallos).

¿Cómo detectar un error tras un deploy con uWSGI? [01:58]

Imagina que cambias de la rama main a develop y al reiniciar uWSGI con sudo service uwsgi restart la aplicación deja de responder. Aquí entran los logs.

En Linux, los logs viven en /var/log. Como suelen ser propiedad de root, los abres con:

bash sudo cat /var/log/uwsgi/app/deploy_with_python_production.log

Si al recargar la página ves un error 400 repetido en el log de uWSGI, el problema está del lado de Python, no del servidor web. Para ver el detalle exacto, puedes habilitar temporalmente DEBUG = True en el settings.py de Django, recargar uWSGI y leer el mensaje completo en el navegador.

En el caso del transcript, el error fue claro: faltaba deploywithpython.com en ALLOWED_HOSTS. Al cambiar de rama, la configuración había perdido el .com.

¿Por qué no dejar DEBUG activo en producción?

Porque expone IP del servidor, certificados y variables internas. Cualquiera con acceso al navegador puede usar esa información en tu contra. Actívalo solo para validar y desactívalo apenas termines.

¿Cómo configurar access log y error log en NGINX por aplicación?

La configuración vive en /etc/nginx/sites-enabled/. Edita el archivo de tu sitio con sudo para tener permisos de escritura:

bash sudo vim /etc/nginx/sites-enabled/tu-sitio

Dentro del bloque server, agrega dos directivas que apuntan a archivos exclusivos de la aplicación:

nginx access_log /var/log/nginx/deploywithpython_access.log; error_log /var/log/nginx/deploywithpython_error.log;

Cada línea termina con punto y coma. El nombre incluye el identificador de la app para que no se mezcle con otros sitios alojados en el mismo NGINX.

¿Qué hace la directiva access_log en NGINX? Define la ruta donde se guardará cada request que recibe el servidor, incluyendo user agent, código de respuesta y origen del tráfico.

¿Cómo validar la configuración antes de reiniciar?

NGINX trae un comando de verificación que te ahorra romper producción:

bash sudo nginx -t

Si todo está correcto, reinicia el servicio:

bash sudo service nginx restart

Al acceder al sitio, los archivos deploywithpython_access.log y deploywithpython_error.log aparecerán automáticamente en /var/log/nginx/.

¿Cómo monitorear logs en tiempo real con tail -f? [08:45]

Aquí viene el truco más útil del flujo de debugging. El comando tail muestra la cola de un archivo, y con la bandera -f (de follow) sigue imprimiendo cada línea nueva que se escriba.

bash sudo tail -f /var/log/nginx/deploywithpython_access.log

Mientras dejas esa terminal abierta, recarga la aplicación en el navegador. Verás en vivo el user agent que hizo el request y la respuesta del servidor, por ejemplo un 200 cuando todo funciona.

Algunos elementos que aparecen en cada línea del access log:

1. La IP del cliente que hizo la petición.
2. La fecha y hora del request.
3. El método HTTP y la ruta solicitada.
4. El código de respuesta (200, 400, 500).
5. El user agent del navegador o cliente.

Con esta información puedes reconstruir qué pasó, cuándo y desde dónde, sin necesidad de reproducir el error tú mismo.

¿Qué tener en cuenta al cambiar de rama en Django?

Un deploy entre ramas no es solo git pull. Hay tres cosas que revisar siempre:

• Migraciones nuevas que requieran python manage.py migrate.
• Cambios en requirements.txt que obliguen a correr pip install -r requirements.txt con el entorno virtual activado.
• Modificaciones en settings.py, especialmente en ALLOWED_HOSTS y variables .env.

El uso de archivos .env en lugar de valores quemados en el código es una práctica que protege credenciales y permite cambiar configuración sin tocar el repositorio.

Ahora tienes el flujo completo: separas logs por aplicación, validas la configuración, reinicias el servicio y monitoreas en tiempo real con tail -f. Como reto, configura uWSGI para que también escriba en un archivo dedicado de la aplicación y cuéntame en los comentarios qué ruta usaste.