Anunciamos NGINX Plus R19

Nos complace anunciar que NGINX Plus Release 19 (R19) ya está disponible. NGINX Plus es el único balanceador de carga, caché de contenido, servidor web y puerta de enlace API todo en uno . Basado en NGINX de código abierto, NGINX Plus incluye funciones mejoradas exclusivas y soporte galardonado. Un enfoque principal de esta versión es el monitoreo, con nuevas capacidades que lo hacen más granular y flexible, para una mayor confiabilidad de sus aplicações a escala.

Las nuevas características de NGINX Plus R19 incluyen:

• Monitoreo más flexible : hemos agregado nuevas capacidades para obtener información más precisa y un análisis más fácil de su ecosistema NGINX Plus, incluida la recopilación opcional de métricas separadas para bloques de ubicación , nuevas métricas sobre la actividad de búsqueda de DNS y soporte para exportación en formato Prometheus y JSON. El panel de NGINX Plus muestra las nuevas métricas por ubicación y tiene nuevas pestañas para las métricas de DNS y las métricas sobre los clústeres de NGINX Plus.
• Modo de ejecución en seco para probar los límites de velocidad : establecer los límites de velocidad correctos para el tráfico de producción es difícil y muy riesgoso; si se equivoca, podría afectar gravemente la experiencia de usuario de una gran proporción de sus usuarios. Con el nuevo modo de ejecución en seco, puede comprender el efecto de sus límites de velocidad en el tráfico de producción sin tener que aplicarlos realmente.
• Mejoras en el almacén de clave-valor : ahora puede almacenar rangos de direcciones IP en el almacén de clave-valor junto con direcciones individuales y establecer tiempos de vencimiento en entradas individuales.
• Control dinámico de ancho de banda : al configurar los límites de ancho de banda, ahora puede establecer la velocidad como una variable, lo que le permite aplicar diferentes límites en función de cualquier atributo del tráfico entrante.

Cambios importantes en el comportamiento

• API obsoletas : NGINX Plus R13 (lanzado en agosto de 2017) introdujo la nueva API NGINX Plus para la recopilación de métricas y la reconfiguración dinámica de grupos ascendentes, reemplazando las API de estado y configuración ascendente que anteriormente implementaban esas funciones. Como se anunció en ese momento, las API obsoletas continuaron estando disponibles y recibiendo soporte durante un período de tiempo significativo, que finalizó con NGINX Plus R16 . Si su configuración incluye las directivas status y/o upstream_conf , debe reemplazarlas con la directiva api como parte de la actualización a R19.

  Para obtener asesoramiento y asistencia para migrar a la nueva API NGINX Plus , consulte la guía de transición en nuestro blog o comuníquese con nuestro equipo de soporte.

• Nuevos sistemas operativos compatibles –

  • Alpino 3.10
  • Debian 10 (“Buster”)
  • Ubuntu 19.04 (“Disco”)

• Los sistemas operativos más antiguos ya no son compatibles

  • Debian 8 (“Jessie”)
  • Ubuntu 14.04 (“Trusty”)
  • Ubuntu 18.10 (“Cósmico”)

Para obtener más información sobre las plataformas compatibles, consulte las especificaciones técnicas de NGINX Plus y los módulos dinámicos .

Nuevas funciones en detalle

Las nuevas funciones hacen que el monitoreo sea aún más flexible

NGINX Plus R19 hace que el monitoreo sea aún más flexible, ampliando tanto los tipos de métricas que puede recopilar como las formas en que puede analizarlas.

Métricas por ubicación

La API NGINX Plus proporciona una amplia gama de métricas de monitoreo en tiempo real, incluidos varios contadores sobre un servidor virtual cuando incluye la directiva status_zone en su bloque server{} . Con NGINX Plus R19 ahora puede recopilar métricas para bloques de ubicación individuales además de (o en lugar de) el bloque server{} principal, agregando la directiva status_zone a esos bloques de ubicación . Esta monitorización más detallada le permite detectar más rápidamente las partes exactas de su sitio web que están generando errores, para una resolución de problemas más efectiva.

La siguiente configuración permite la recopilación de métricas para un sitio web completo y, además, para todas las solicitudes a URI que comienzan con /admin/ .

Luego puede acceder a las métricas en el punto final http/location_zones .

$ curl http://localhost:8080/api/5/http/location_zones { "www_admin": { "solicitudes": 3393, "respuestas": { "1xx": 0, "2xx": 3307, "3xx": 81, "4xx": 5, "5xx": 0, "total": 3393 }, "descartado": 0, "recibido": 15403, "enviado": 835227 } }

También es posible colocar la directiva status_zone dentro de un bloque if , pero tenga en cuenta que las métricas solo se cuentan una vez para una ubicación determinada y desde la última directiva status_zone que se encontró durante el procesamiento de la solicitud. La siguiente configuración extiende el ejemplo anterior al recopilar métricas separadas cada vez que una solicitud a la ubicación /admin/ incluye una cadena de consulta.

Métricas del solucionador de DNS

La API NGINX Plus también se ha ampliado con métricas para rastrear la actividad de búsqueda de DNS, en particular sobre los tipos de solicitud de DNS y los estados de respuesta. Para recopilar métricas sobre un grupo de servidores DNS que NGINX Plus consulta para búsquedas de nombres, agregue el parámetro status_zone a la directiva del resolver .

Luego, puede acceder a las métricas en el punto final de los solucionadores .

$ curl http://localhost:8080/api/5/resolvers { "internal_dns": { "solicitudes": { "nombre": 132, "servidor": 0, "dirección": 0 }, "respuestas": { "sin error": 130, "formerr": 0, "fallo de servicio": 0, "nxdominio": 0, "no impulsivo": 0, "rechazado": 0, "tiempo de espera": 2, "desconocido": 0 } } }

Actualizaciones del panel de monitoreo de actividad en vivo

El panel de control de actividad en vivo de NGINX Plus ofrece una ubicación centralizada y práctica para el seguimiento de las métricas recopiladas por la API de NGINX Plus . El panel se ha ampliado en NGINX Plus R19 para incluir las nuevas métricas de resolución y por ubicación mencionadas anteriormente. Además, ahora informa métricas relacionadas con el uso compartido del estado de tiempo de ejecución en un clúster (como se habilita con el módulo de sincronización de zona ), a las que anteriormente solo se podía acceder a través de la API NGINX Plus .

Hay dos pestañas renombradas y dos pestañas nuevas:

• Zonas HTTP es el nuevo nombre de la pestaña Zonas del servidor . La pestaña ahora muestra métricas sobre los bloques de ubicación y los bloques de servidor .
• HTTP Upstreams es el nuevo nombre de la pestaña Upstreams . Esto proporciona claridad cuando se configuran los módulos HTTP y TCP/UDP.
• La nueva pestaña Clúster muestra métricas sobre el uso compartido de estados en los clústeres NGINX Plus.
• La nueva pestaña Resolvers muestra métricas sobre la actividad de búsqueda de DNS.

Para explorar el nuevo panel, visita https://demo.nginx.com/ .

Nuevo módulo para la monitorización de Prometheus

La API NGINX Plus devuelve métricas en formato JSON, que es un formato común y conveniente para la integración con soluciones de monitoreo externo y gestión del rendimiento de aplicação (APM). Ahora también puedes exportar métricas en formato Prometheus, que es particularmente popular en entornos de Kubernetes.

El módulo Prometheus-njs expone las métricas de Prometheus. Para habilitar las métricas exportadas:

1. Instalar el módulo Prometheus-njs .
2. Configurar la API de NGINX Plus .

3. Configure una ubicación dedicada para la recopilación de métricas de Prometheus en el archivo de configuración de NGINX Plus.

4. Configure Prometheus para obtener métricas de NGINX Plus especificando la dirección de red de la instancia de NGINX Plus en una sección scrape_config en el archivo de configuración de Prometheus.

Límites de velocidad de prueba en modo de ejecución en seco

NGINX Plus proporciona un enfoque muy flexible para la limitación de velocidad. Se pueden rastrear y aplicar múltiples límites de velocidad a la vez. La aplicación en sí se presenta en cinco formas diferentes, entre ellas retrasar solicitudes excesivas, rechazarlas por completo y permitir una ráfaga de solicitudes sin restricciones antes de la aplicación, además de combinaciones de esos comportamientos. Para una explicación detallada, consulte nuestro blog .

Si bien esta flexibilidad puede permitir una limitación de velocidad muy refinada, ¿cómo determinar en primer lugar el límite de velocidad adecuado para su tráfico? ¿Cómo puede saber con anticipación si el límite de velocidad planificado es demasiado alto (en cuyo caso sus servidores pueden verse sobrecargados) o demasiado bajo (en cuyo caso la experiencia del usuario puede verse afectada)?

La mejor fuente de información es el registro de errores de NGINX Plus, donde se crea una entrada detallada como la siguiente cuando NGINX Plus retrasa o rechaza una solicitud:

03/09/2019 11:42:12 [error] 57#57: *339 limitando solicitudes, exceso: 0.600 por zona "my_limit", cliente: 172.17.0.1, servidor: www.example.com, solicitud: "GET / HTTP/1.1", host: "www.ejemplo.com:80"

La entrada le indica cosas útiles como cuántas solicitudes por milisegundo sobre la tasa configurada representa esta solicitud (el campo de exceso ), el límite particular que se excedió (el campo de zona ) y la dirección IP del cliente (el campo de cliente ). Pero la información sigue siendo útil para fines de planificación solo si se puede obtener antes de aplicar los límites al tráfico.

NGINX Plus R19 agrega esta capacidad predictiva con un modo de “ejecución en seco” para limitar la velocidad. Las entradas de registro se crean de forma normal, pero no se aplican los límites de velocidad. Para habilitar el modo de ejecución en seco, incluya la nueva directiva limit_req_dry_run en el mismo bloque que la directiva o directivas limit_req .

En el siguiente ejemplo, las directivas limit_req_zone definen cuatro límites de velocidad diferentes, desde 10 000 solicitudes por segundo hasta 10 solicitudes por segundo. Aplicamos esas tasas con las directivas limit_req en el bloque de ubicación raíz (líneas 9 a 12), junto con la directiva limit_req_dry_run para deshabilitar la aplicación.

NGINX Plus escribe una entrada de registro, marcada claramente con dry run , para cada solicitud que exceda un límite de velocidad determinado. En nuestro análisis del registro podemos filtrar las entradas por el campo de zona para determinar cuál de los límites de velocidad nos brinda el comportamiento deseado.

03/09/2019 11:56:26 [error] 142#142: *22282 limitando solicitudes, ejecución en seco , exceso: 1.000 por zona "1000rs", cliente: 172.17.0.1, servidor: www.example.com, solicitud: "GET / HTTP/1.1", host: "www.ejemplo.com:80"

Mejoras en el almacén de valores clave

Con el almacén de valores clave en memoria para NGINX Plus, puede usar la API de NGINX Plus para configurar dinámicamente la gestión del tráfico en función de los atributos de la solicitud. Algunos ejemplos de casos de uso incluyen listas de denegación dinámicas de direcciones IP , limitación dinámica del ancho de banda y almacenamiento en caché de tokens de autenticación .

Compatibilidad con rangos de red

NGINX Plus R19 amplía el almacén de valores clave al agregar soporte para rangos de redes IP (subredes) al soporte existente para direcciones IP individuales. Esto significa que una sola entrada en el almacén de valores clave puede coincidir con todas las direcciones IP de un rango de red, lo que simplifica la configuración y le ahorra tiempo porque no tiene que agregar individualmente las direcciones que componen un rango. El almacén de valores clave utiliza la notación CIDR para representar rangos de red. Por ejemplo, 192.168.13.0/24 representa las direcciones 192.168.13.0 a 192.168.13.255. Se admiten direcciones y rangos tanto IPv4 como IPv6.

Para habilitar rangos de red, incluya el nuevo parámetro type=ip en la directiva keyval_zone , como en la siguiente configuración para la lista negra dinámica de direcciones IP. Cuando NGINX Plus realiza una búsqueda, cualquier dirección IP dentro de un rango de red almacenado en el almacén de clave-valor devuelve una coincidencia.

La línea 2 especifica que la variable $in_denylist se evalúa realizando una búsqueda en el almacén de valores clave de la lista de denegados , utilizando $remote_addr (la dirección IP del cliente) como clave. Luego, el bloque if simple (líneas 8 a 10) rechaza una solicitud cuando la dirección IP del cliente está en la lista de bloqueados.

El siguiente comando curl invoca la API NGINX Plus para crear una entrada en el almacén de clave-valor para el rango de red mencionado anteriormente.

$ curl -X POST -d '{"192.168.13.0/24":"1"}' http://localhost:8080/api/5/http/keyvals/denylist

Tiempos de espera de expiración por entrada

En la sección anterior, el parámetro timeout=24h de la directiva keyval_zone en la línea 1 de denylist.conf significa que cada entrada en el almacén de clave-valor de la lista de denegación vence (y se elimina del almacén) 24 horas después de su creación.

Con NGINX Plus R19 , puede anular el tiempo de espera predeterminado (establecido para todo el almacén de clave-valor mediante el parámetro de tiempo de espera ) con un tiempo de espera diferente para cualquier entrada individual. Los tiempos de espera individuales pueden ser mayores o menores que los predeterminados.

Para crear una entrada con un tiempo de espera no predeterminado, proporcione el valor como un objeto JSON con dos campos:

• valor – Establezca el valor deseado, en este caso1 para rellenar la variable $in_denylist
• expire – Establezca el número de milisegundos después de la creación en que expira el valor

El siguiente JSON representa una entrada de lista de bloqueados para localhost (127.0.0.1) que expira en 1 hora (3.600.000 milisegundos).

{
"127.0.0.1": {
"valor": "1", "caducará": 3600000
}
}

El siguiente comando curl crea esa entrada en el almacén de clave-valor:

$ curl -X POST -d '{"127.0.0.1":{"valor":1","caducidad":3600000}}' http://localhost:8080/api/5/http/keyvals/denylist

Control dinámico del ancho de banda

La directiva limit_rate establece la velocidad (número de bytes por segundo) a la que NGINX Plus envía la respuesta a una solicitud HTTP, y la directiva limit_rate_after establece la cantidad de bytes que NGINX Plus envía antes de que se aplique ese límite. Con NGINX Plus R19 , el parámetro de cada directiva puede ser una variable en lugar de un valor estático, lo que permite un control dinámico del uso del ancho de banda en función de los atributos de la solicitud.

La siguiente configuración de ejemplo establece el ancho de banda según la versión de TLS utilizada por el cliente, recompensando efectivamente a los navegadores más modernos con respuestas más rápidas.

En versiones anteriores de NGINX Plus, podía limitar el ancho de banda configurando la variable $limit_rate ; le recomendamos que utilice este método más simplificado. Para obtener más detalles, consulte la documentación de la directiva limit_rate .

Las directivas proxy_download_rate y proxy_upload_rate para el tráfico TCP/UDP ahora también aceptan un parámetro variable.

Para una limitación de ancho de banda aún más sofisticada, puede utilizar extensiones de script como el módulo JavaScript NGINX (njs) para implementar una lógica personalizada avanzada para determinar el límite de ancho de banda apropiado para una conexión determinada.

Actualizaciones del ecosistema NGINX Plus

Módulo NGINX JavaScript

El módulo JavaScript de NGINX (njs) se ha actualizado a la versión 0.3.5 . Las mejoras más notables (acumulativas de versiones anteriores) son:

• Soporte para funciones de flecha (gracias a 洪志道 [Hong Zhi Dao] y Artem S. Povalyukhin)
• Un objeto de proceso global (especialmente útil para leer variables de entorno)
• Funciones String.prototype.trim

Actualice o pruebe NGINX Plus

Si está utilizando NGINX Plus, le recomendamos encarecidamente que actualice a NGINX Plus R19 lo antes posible. También recibirás una serie de correcciones y mejoras adicionales, y ayudará a NGINX a ayudarte cuando necesites generar un ticket de soporte.

Revise atentamente las nuevas características y los cambios de comportamiento descritos en esta publicación del blog antes de continuar con la actualización.

Si aún no ha probado NGINX Plus, le recomendamos que lo haga por cuestiones de seguridad, equilibrio de carga y puerta de enlace de API, o como servidor web totalmente compatible con API de administración y monitoreo mejoradas. Puede comenzar hoy con una evaluación gratuita de 30 días . Vea usted mismo cómo NGINX Plus puede ayudarle a entregar y escalar sus aplicações.