Gestión de Errores y Niveles de Registro (error_log)

La directiva error_log permite definir dónde y con qué nivel de detalle se almacenarán los mensajes de error del servidor. Los niveles de severidad disponibles, ordenados de menor a mayor gravedad, son: debug, info, notice, warn, error y crit.

Nginx ofrece la flexibilidad de aislar los registros para diferentes servidores virtuales, facilitando la depuración en entornos complejos:

# Configuración global a nivel de contexto principal
error_log /var/log/nginx/global_errors.log warn;

http {
    server {
        listen 8080;
        server_name api.dominio.com;
        
        # Registros aislados específicamente para este servidor virtual
        access_log /var/log/nginx/api_access.log;
        error_log /var/log/nginx/api_errors.log error;
    }
    
    server {
        listen 8080;
        server_name web.dominio.com;
        
        access_log /var/log/nginx/web_access.log;
        error_log /var/log/nginx/web_errors.log notice;
    }
}

Nota importante: Es un error común utilizar error_log off; para desactivar el registro. Esto no deshabilita la función, sino que crea un archivo literalmente llamado "off". Para silenciar correctamente los registros de errores, se debe redirigir la salida al dispositivo nulo especificando el nivel más alto:

error_log /dev/null crit;

Inclusión de Archivos de Configuración (include)

Para mantener los archivos de configuración organizados y modulares, se utiliza la directiva include. Esto permite importar configuraciones externas, como tipos MIME o definiciones de servidores virtuales.

http {
    include /etc/nginx/mime.types;
    
    # Carga múltiple de configuraciones utilizando comodines
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/vhosts/*.conf;
}

Desde la versión 0.4.4, la directiva soporta el uso de comodines (wildcards). Es crucial tener en cuenta la resolución de rutas: en versiones anteriores a la 0.6.7, las rutas relativas dependían del directorio prefijo especificado durante la compilación (--prefix). A partir de la versión 0.6.7, las rutas relativas se resuelven tomando como base el directorio donde se encuentra el archivo principal nginx.conf. Si se requiere certeza absoluta, se recomienda utilizar rutas absolutas.

Personalización de Registros de Acceso

El módulo de registro permite estructurar la salida de los logs de acceso mediante log_format, asignando un alias que luego se referencia en la directiva access_log.

log_format detailed_format '{"client_ip": "$remote_addr", "time": "$time_local", '
                           '"method": "$request_method", "uri": "$request_uri", '
                           '"status": $status, "bytes_sent": $body_bytes_sent, '
                           '"response_time": $request_time}';

access_log /var/log/nginx/access_detailed.log detailed_format;

Modelo de Eventos y Concurrencia

El bloque events dicta el comportamiento del núcleo de Nginx respecto al manejo de conexiones de red. La directiva use permite seleccionar el modelo de eventos del sistema operativo (como epoll para Linux, kqueue para FreeBSD, o eventport para Solaris). Si no se especifica, Nginx seleccionará automáticamente el método más óptimo disponible en el sistema.

events {
    use epoll;
    worker_connections 4096;
}

La directiva worker_connections define cuántas conexiones simultáneas puede manejar cada proceso trabajador. El cálculo teórico del límite máximo de conexiones globales es:

Máximo de conexiones = worker_processes * worker_connections

En arquitecturas de proxy inverso, esta cifra teórica se reduce (frecuentemente dividiendo el total entre 2 o 4). Esto se debe a que Nginx consume descriptores de archivos (fds) del mismo pool del sistema para mantener tanto la conexión con el cliente como la conexión con el servidor backend.

Estructura Jerárquica del Contexto HTTP

La configuración del protocolo HTTP en Nginx se organiza en una estructura de bloques anidados. El contexto principal es http, que contiene los bloques server (definición de servidores virtuales), y a su vez, estos contienen los bloques location (enrutamiento de peticiones).

http {
    # Contexto de protocolo HTTP
    include mime.types;
    default_type application/octet-stream;
    sendfile on;
    keepalive_timeout 65;

    server {
        # Contexto de servidor virtual
        listen 80;
        server_name app.ejemplo.com;

        location / {
            # Contexto de ubicación (petición)
            root /var/www/html;
            index index.html index.htm;
        }

        location /api/ {
            proxy_pass http://127.0.0.1:3000;
            proxy_set_header Host $host;
        }
    }
}