Presentamos NGINX Plus R19

Liam CrillyDirector sénior de Gestión de Producto

Nos complace anunciar que NGINX Plus Release 19 (R19) ya está disponible. NGINX Plus es la única solución todo en uno que combina equilibrador de carga, caché de contenido, servidor web y puerta de enlace de API. Basado en NGINX Open Source, NGINX Plus incluye funciones avanzadas exclusivas y un servicio de soporte galardonado. Uno de los principales objetivos de esta versión es la monitorización, con nuevas prestaciones que aportan mayor granularidad y flexibilidad para mejorar la fiabilidad de sus aplicaciones a gran escala.

Entre las nuevas funciones de NGINX Plus R19 se incluyen:

• Monitorización más flexible – Hemos añadido nuevas funciones que permiten obtener información más detallada y analizar más fácilmente su ecosistema NGINX Plus, incluida la recopilación independiente opcional de métricas para los bloques location, nuevas métricas sobre la actividad de búsqueda de DNS y la posibilidad de exportar los datos tanto en formato Prometheus como JSON. El panel de NGINX Plus muestra las nuevas métricas por ubicación e incluye nuevas pestañas para las métricas de DNS y las métricas de los clústeres de NGINX Plus.
• Modo de prueba para comprobar los límites de velocidad – Establecer los límites de velocidad adecuados para el tráfico de producción es difícil y entraña muchos riesgos: si se equivoca, podría perjudicar gravemente la experiencia de una gran parte de sus usuarios. Con el nuevo modo de prueba, puede conocer el efecto que tendrían sus límites de velocidad sobre el tráfico de producción sin llegar a aplicarlos.
• Mejoras en el almacén de clave-valor – Ahora puede almacenar rangos de direcciones IP en el almacén de clave-valor, además de direcciones individuales, y establecer tiempos de caducidad para cada entrada.
• Control dinámico del 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 distintos límites en función de cualquier atributo del tráfico entrante.

Cambios importantes en el comportamiento

• API obsoletas – NGINX Plus R13 (publicado en agosto de 2017) introdujo la API de NGINX Plus completamente nueva para recopilar métricas y reconfigurar dinámicamente los grupos de servidores ascendentes, en sustitución de las API Status y Upstream Conf, que anteriormente realizaban esas funciones. Como se anunció en su momento, las API obsoletas siguieron estando disponibles y recibiendo soporte durante un periodo considerable, que finalizó con NGINX Plus R16. Si su configuración incluye las directivas status o upstream_conf, debe sustituirlas por la directiva api como parte de la actualización a R19. Para obtener asesoramiento y ayuda para migrar a la nueva API de NGINX Plus, consulte la guía de transición en nuestro blog o póngase en contacto con nuestro equipo de soporte.
• Nuevos sistemas operativos compatibles –
  • Alpine 3.10
  • Debian 10 («Buster»)
  • Ubuntu 19.04 («Disco»)
• Sistemas operativos antiguos que ya no son compatibles –
  • Debian 8 («Jessie»)
  • Ubuntu 14.04 («Trusty»)
  • Ubuntu 18.10 («Cosmic»)

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 la monitorización sea aún más flexible

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

Métricas por ubicación

La API de NGINX Plus proporciona una amplia gama de métricas de monitorización en tiempo real, incluidos varios contadores relativos a un servidor virtual cuando se incluye la directiva status_zone en su bloque server{}. Con NGINX Plus R19, ahora se pueden recopilar métricas de bloques location individuales, además de las del bloque server{} principal (o en su lugar), añadiendo la directiva status_zone a dichos bloques location. Esta monitorización más detallada permite detectar con mayor rapidez las partes exactas del sitio web que generan errores, lo que facilita una resolución de problemas más eficaz.

La siguiente configuración permite recopilar métricas de todo un sitio web, así como de todas las solicitudes a URI que comiencen por /admin/.

Cargando ejemplo de código…

A continuación, puedes acceder a las métricas en el endpoint http/location_zones.

$ curl http://localhost:8080/api/5/http/location_zones{
  "www_admin": {
    "requests": 3393,
    "responses": {
      "1xx": 0,
      "2xx": 3307,
      "3xx": 81,
      "4xx": 5,
      "5xx": 0,
      "total": 3393
    },
    "discarded": 0,
    "received": 15403,
    "sent": 835227
  }
}

También es posible incluir la directiva status_zone dentro de un bloque if, pero tenga en cuenta que las métricas solo se contabilizan una vez para una ubicación determinada y se atribuyen a la última directiva status_zone encontrada durante el procesamiento de la solicitud. La siguiente configuración amplía el ejemplo anterior recopilando métricas por separado cuando una solicitud a la ubicación /admin/ incluye una cadena de consulta.

Cargando ejemplo de código…

Métricas del solucionador DNS

La API de NGINX Plus también se ha ampliado con métricas para supervisar la actividad de las búsquedas de DNS, en particular los tipos de solicitudes DNS y los estados de las respuestas. Para recopilar métricas sobre un grupo de servidores DNS que NGINX Plus consulta para resolver nombres, añada el parámetro «status_zone» a la directiva «resolver».

Cargando ejemplo de código…

A continuación, puedes acceder a las métricas en el endpoint resolvers.

$ curl http://localhost:8080/api/5/resolvers{
  "internal_dns": {
    "requests": {
      "name": 132,
      "srv": 0,
      "addr": 0
    },
    "responses": {
      "noerror": 130,
      "formerr": 0,
      "servfail": 0,
      "nxdomain": 0,
      "notimp": 0,
      "refused": 0,
      "timedout": 2,
      "unknown": 0
    }
  }
}

Actualizaciones del panel de supervisión de la actividad en tiempo real

El panel de monitorización de la actividad en tiempo real de NGINX Plus proporciona una ubicación centralizada y práctica para realizar 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 del solucionador y por ubicación mencionadas anteriormente. Además, ahora muestra métricas relacionadas con el uso compartido del estado en tiempo de ejecución en un clúster (habilitado mediante el módulo Sincronización de zonas), que anteriormente solo estaban disponibles a través de la API de NGINX Plus.

Hay dos pestañas con nombres nuevos y dos pestañas nuevas:

• Zonas HTTP es el nuevo nombre de la pestaña Zonas de servidores. La pestaña ahora muestra métricas sobre los bloques location y también sobre los bloques server.
• Upstreams HTTP es el nuevo nombre de la pestaña Upstreams. Esto aporta claridad cuando están configurados tanto los módulos HTTP como los módulos TCP/UDP.
• La nueva pestaña «Clúster» muestra métricas sobre el uso compartido del estado en los clústeres de NGINX Plus.
• La nueva pestaña Resolutores muestra métricas sobre la actividad de las consultas DNS.

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

Nuevo módulo para la monitorización con Prometheus

La API de NGINX Plus devuelve métricas en formato JSON, un formato habitual y práctico para la integración con soluciones externas de monitorización y gestión del rendimiento de aplicaciones (APM). Ahora también puede exportar métricas en formato Prometheus, especialmente popular en entornos Kubernetes.

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

1. Instale el módulo Prometheus-njs.
2. Configure la API de NGINX Plus.
3. Configure una ubicación específica para recopilar métricas de Prometheus en el archivo de configuración de NGINX Plus.

   Cargando ejemplo de código…

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 del archivo de configuración de Prometheus.

Prueba de límites de velocidad en modo de simulación

NGINX Plus ofrece un enfoque muy flexible para limitar la tasa de solicitudes. Es posible supervisar y aplicar varios límites de tasa simultáneamente. La aplicación de estos límites admite cinco modalidades diferentes, entre ellas retrasar las solicitudes excesivas, rechazarlas directamente y permitir una ráfaga de solicitudes sin restricciones antes de aplicar los límites, además de combinaciones de estos comportamientos. Para obtener una explicación detallada, consulte nuestro blog.

Aunque esta flexibilidad permite aplicar una limitación de solicitudes muy precisa, ¿cómo se determina en primer lugar el límite adecuado para el tráfico? ¿Cómo se puede saber de antemano si el límite previsto es demasiado alto (en cuyo caso los servidores podrían verse saturados) o demasiado bajo (en cuyo caso la experiencia de usuario podría 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:

2019/09/03 11:42:12 [error] 57#57: *339 limiting requests, excess: 0.600 by zone "my_limit", client: 172.17.0.1, server: www.example.com, request: "GET / HTTP/1.1", host: "www.example.com:80"

La entrada proporciona información útil, como cuántas solicitudes por milisegundo por encima de la tasa configurada representa esta solicitud (el campo «excess»), el límite concreto que se ha superado (el campo «zone») y la dirección IP del cliente (el campo «client»). Sin embargo, esta información solo resulta útil para la planificación si puede obtenerla antes de aplicar realmente los límites al tráfico.

NGINX Plus R19 incorpora esta capacidad predictiva mediante un modo de «simulación» para la limitación de la tasa de solicitudes. Las entradas de registro se crean con normalidad, pero los límites de tasa no se aplican. Para habilitar el modo de simulación, 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 esos límites mediante las directivas limit_req en el bloque location raíz (líneas 9–12), junto con la directiva limit_req_dry_run para desactivar su aplicación.

Cargando ejemplo de código…

NGINX Plus escribe una entrada en el registro, claramente marcada con dry run, por cada solicitud que superaría un límite de velocidad determinado. Al analizar el registro, podemos filtrar las entradas por el campo zone para determinar cuál de los límites de velocidad ofrece el comportamiento deseado.

2019/09/03 11:56:26 [error] 142#142: *22282 limiting requests, dry run, excess: 1.000 by zone "1000rs", client: 172.17.0.1, server: www.example.com, request: "GET / HTTP/1.1", host: "www.example.com:80"

Mejoras en el almacén de clave-valor

Con el almacén de clave-valor en memoria de NGINX Plus, puede utilizar 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 uso son la incorporación dinámica de direcciones IP a listas de denegación, la limitación dinámica del ancho de banda y el almacenamiento en caché de tokens de autenticación.

Compatibilidad con rangos de red

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

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

Cargando ejemplo de código…

La línea 2 especifica que la variable $in_denylist se evalúa realizando una búsqueda en el almacén de clave-valor denylist, utilizando $remote_addr (la dirección IP del cliente) como clave. A continuación, el sencillo bloque if (líneas 8–10) rechaza una solicitud cuando la dirección IP del cliente está en la lista de denegación.

El siguiente comando curl invoca la API de NGINX Plus para crear una entrada en el almacén de clave-valor para el intervalo 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 del almacén de clave-valor de la lista de denegación caduca (y se elimina del almacén) 24 horas después de su creación.

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

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

• value – Establézcalo en el valor deseado, en este caso 1 para asignar un valor a la variable $in_denylist variable
• expire – Establézcalo en el número de milisegundos que deben transcurrir desde la creación para que el valor caduque

El siguiente JSON representa una entrada de la lista de denegación para localhost (127.0.0.1) que caduca en 1 hora (3.600.000 milisegundos).

{
  "127.0.0.1": {
    "value": "1",
    "expire": 3600000
  }
}

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

$ curl -X POST -d '{"127.0.0.1":{"value":"1","expire":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 el número de bytes que NGINX Plus envía antes de que se aplique dicho 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 controlar dinámicamente el 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 en función de la versión de TLS utilizada por el cliente, lo que en la práctica favorece a los navegadores más modernos con respuestas más rápidas.

Cargando ejemplo de código…

En versiones anteriores de NGINX Plus, se podía limitar el ancho de banda configurando la variable $limit_rate; en su lugar, recomendamos utilizar este método más sencillo. Para obtener más información, 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 admiten un parámetro de variable.

Para aplicar una limitación del ancho de banda aún más sofisticada, puede utilizar extensiones de scripting como el módulo JavaScript de NGINX (njs) para implementar una lógica avanzada y personalizada que determine el límite de ancho de banda adecuado para una conexión concreta.

Actualizaciones del ecosistema de NGINX Plus

Módulo JavaScript de NGINX

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

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

Actualice o pruebe NGINX Plus

Si utiliza NGINX Plus, le recomendamos encarecidamente que actualice a NGINX Plus R19 lo antes posible. También obtendrá varias correcciones y mejoras adicionales, y facilitará que NGINX pueda ayudarle cuando necesite abrir una incidencia de soporte.

Revise detenidamente las nuevas funcionalidades y los cambios de comportamiento descritos en esta entrada del blog antes de proceder con la actualización.

Si aún no ha probado NGINX Plus, le animamos a hacerlo, ya sea para la seguridad, el balanceo de carga y la puerta de enlace de API, o como servidor web con soporte completo y API avanzadas de supervisión y gestión. Puede empezar hoy mismo con una evaluación gratuita de 30 días. Compruebe por sí mismo cómo NGINX Plus puede ayudarle a ofrecer y escalar sus aplicaciones.

Sobre el autor

Liam CrillyDirector sénior de Gestión de Producto

Más artículos de Liam Crilly