Registro de tráfico entre NGINX y servidores ascendentes en CDN77

Independientemente de la plataforma que utilice, el registro suele ser un requisito fundamental para el procesamiento de big data, estadísticas, auditorías, informes de clientes y transacciones, así como para depurar la comunicación cliente-servidor y posibles problemas.

En este blog, abordamos el papel del registro en la depuración, donde proporciona la herramienta definitiva para localizar los diversos problemas tan comunes en las comunicaciones por Internet.

El registro de la comunicación entre el cliente y el servidor web ayuda en gran medida a depurar posibles problemas relacionados con la versión del navegador, la red del cliente y los archivos a los que se accede. Pero no termina ahí. Hay infinitas posibilidades de qué registrar, dependiendo completamente de su plataforma y requisitos.

Arquitectura de registro de NGINX

Cuando ejecuta un proxy inverso, un equilibrador de carga o una red de distribución de contenido (CDN), está agregando otro nodo al flujo de comunicación entre el cliente y el servidor. Un servidor intermedio que manipula datos, como un proxy inverso, a menudo introduce problemas inesperados.

Como proxy inverso, NGINX convierte la conexión del cliente al servidor web (u otro servidor de aplicaciones) en dos conexiones separadas finalizando la conexión del cliente y creando una nueva al servidor. La “división” en dos conexiones también crea dos contextos separados para el registro, y NGINX admite el registro para ellos de forma algo diferente.

• Para el tráfico entre el cliente y el proxy inverso, NGINX proporciona un registro de errores y un registro de acceso , que registra eventos de procesamiento y acciones que no son errores.

  Puede habilitar el registro de errores con la directiva error_log y establecer el nivel de gravedad de los errores que se registrarán.

  El registro de acceso se habilita con la directiva access_log . La directiva log_format asociada le permite personalizar el tipo de información incluida en los registros y el formato de las entradas del registro. Puede escribir los registros en un archivo, en syslog o en ambos.

• Para el tráfico entre el proxy inverso y el servidor web o de aplicaciones (al que NGINX denomina servidor ascendente ), NGINX admite el registro de errores. Sin embargo, no admite el registro de acceso para este tráfico.

  La única forma de ver eventos que no sean de error entre el servidor proxy y un servidor ascendente es establecer el nivel de gravedad en el registro de errores en depurar . La desventaja de esta configuración es que se registran enormes cantidades de datos. Esto ralentiza el procesamiento de solicitudes y crea archivos muy grandes que pueden llenar rápidamente el almacenamiento. (Tenga en cuenta que también debe volver a compilar NGINX con el argumento --with-debug en el comando de configuración , ya que la compatibilidad con la depuración no está habilitada de manera predeterminada).

Nuestra solución de registro ascendente

Como proveedor de CDN, a menudo nos encontramos con servidores ascendentes que no se comunican correctamente con nuestros servidores proxy inversos y clientes. Los mensajes de nivel de depuración en el registro de errores no siempre brindan el tipo de información que necesitamos para solucionar un problema con el servidor ascendente.

La solución pronto se hizo evidente: generar un registro de acceso ascendente agregando una función que recopila solo la información esencial de la comunicación entre el proxy inverso y los servidores ascendentes.

La idea general es que NGINX llame a nuestra función cada vez que se realiza una solicitud a un servidor ascendente. Esto nos permite programar toda la lógica relacionada con el registro ascendente en la propia función.

El módulo estándar ngx_http_upstream_module maneja las solicitudes ascendentes y necesitamos que llame a la función por nosotros. El módulo actualmente no admite dicha funcionalidad, por lo que lo parcheamos para habilitar la devolución de llamada cuando sea necesario.

El registro en sí se maneja en un módulo separado que escribimos, que utiliza la capacidad de devolución de llamada de registro que agregamos en el módulo upstream parcheado. El nuevo módulo define una nueva directiva upstream_log para configurar la funcionalidad de registro. La directiva utiliza el mismo analizador que la directiva access_log , por lo que los datos pueden escribirse en un archivo o enviarse a un servidor syslog mediante un socket.

Cuando NGINX lee la directiva upstream_log en nginx.conf durante el inicio, se llaman dos funciones:

• ngx_http_upstream_log_set_log , que analiza la directiva y prepara la estructura del registro en sí ( ngx_log_t ) utilizando ngx_log_set_log internamente
• ngx_http_upstream_log_init (en un paso posterior a la configuración), que registra nuestra función de registro principal con el módulo ascendente

De esta manera, cuando es necesario enviar una solicitud por proxy, todo está listo. El módulo ascendente inicia una conexión con el servidor ascendente y nuestro parche se asegura de que se llame a la función de registro para registrar los detalles de la solicitud.

El formato del registro está integrado en el módulo ascendente. Todavía tenemos la opción de agregar soporte para la configuración usando la directiva log_format , pero no es necesario para nuestro caso de uso.

Valores registrados desde el upstream

La función de registro se llama inmediatamente después de que se cierra la conexión con el servidor ascendente. Su argumento es un puntero a una solicitud procesada actualmente (la estructura ngx_http_request_t ), que permite que la función acceda y registre todos los datos en la estructura. El campo ascendente (puntero a ngx_http_upstream_t ) es de particular interés ya que contiene datos sobre la solicitud ascendente. Estamos particularmente interesados en:

• El código de estado de respuesta de origen
• La duración de la solicitud
• El valor de un encabezado HTTP en la respuesta o el encabezado del host

El acceso a toda la estructura de la solicitud es lo que le da flexibilidad al módulo, porque se puede registrar una amplia variedad de información.

Problemas que encontramos

Inicialmente implementamos la funcionalidad en ngx_http_core_module . Esto era suficiente para un prototipo, pero no era una solución muy limpia, ya que podría complicar futuras actualizaciones y modificaciones. Finalmente, separamos la función de registro ascendente en un módulo independiente como se describe en Nuestra solución de registro ascendente .

Por supuesto, hubo algunos problemas de implementación. En particular, en algunos lugares manejamos incorrectamente las cadenas ngx_str_t , por ejemplo, al utilizar la función de la biblioteca C sprintf en lugar de ngx_snprintf . Esto puede provocar la escritura de datos no definidos en el registro ascendente o incluso un error de segmentación en el hilo de trabajo. Estos problemas se resolvieron después de una exhaustiva depuración y pruebas utilizando herramientas como Valgrind y AddressSanitizer.

Características de NGINX utilizadas en CDN77

La razón principal por la que CDN77 utiliza NGINX es por sus capacidades de almacenamiento en caché. El servidor CDN es un nodo introducido entre el cliente y el servidor web (servidor ascendente), que pasa solicitudes del cliente y solicita archivos apropiados del servidor ascendente. Cuando el archivo se almacena en caché, se envía a otros usuarios que solicitan el mismo archivo desde la misma ubicación.

“Archivos servidos localmente” es una de las características que utilizamos para que NGINX proporcione un archivo desde el disco del servidor cuando recibe una solicitud.

Algunas características y configuraciones adicionales son necesarias para el almacenamiento en caché seguro. Utilizamos SSL (TLS 1.3 con 0‑RTT) o tokens seguros que se pueden generar para una dirección IP específica para proteger el contenido adecuadamente.

Otras características que utilizamos incluyen páginas de error personalizadas para nuestros clientes, la implementación NGINX predeterminada de grapado OCSP y FastCGI para PHP para reducir la cantidad de procesos PHP requeridos.

CONCLUSIÓN

El registro ascendente no solo nos ayudó y continúa ayudando a depurar varios problemas, sino que también proporcionó una excelente oportunidad para profundizar más en la funcionalidad principal de NGINX y simplificó muchos otros proyectos que hemos emprendido.

Acerca de CDN77

CDN77 hace que la distribución de contenidos sea mejor y más cómoda en todo el mundo. Con más de 30 centros de datos, somos capaces de almacenar en caché y entregar contenido de manera eficaz en todo el mundo. Esto incluye contenido estático en su sitio web, distribución de software, video a pedido (VoD) y transmisión en vivo a través de varios protocolos, como HLS o MPEG-DASH utilizando un motor de transmisión dedicado.

Comenzar a utilizar CDN77 es muy fácil, rápido y sencillo. Regístrese para una prueba gratuita , cree un recurso CDN y utilice la URL de CDN generada o el registro CNAME personalizado para integrarlo con su sitio web o solución de transmisión. Todas las características, configuraciones y posibles soluciones personalizadas garantizan que CDN77 cumpla con sus requisitos.