Anunciando o NGINX Plus R19

Liam CrillyDiretor Sênior de Gestão de Produtos

Temos o prazer de anunciar que o NGINX Plus Release 19 (R19) já está disponível. O NGINX Plus é a única solução completa que reúne balanceador de carga, cache de conteúdo, servidor web e gateway de API. Baseado no NGINX Open Source, o NGINX Plus inclui recursos avançados exclusivos e suporte premiado. Um dos principais focos desta versão é o monitoramento, com novos recursos que o tornam mais granular e flexível, aumentando a confiabilidade das suas aplicações em grande escala.

Os novos recursos do NGINX Plus R19 incluem:

• Monitoramento mais flexível – Adicionamos novos recursos para oferecer insights mais detalhados e facilitar a análise do seu ecossistema NGINX Plus, incluindo a coleta separada e opcional de métricas para blocos location, novas métricas sobre a atividade de consulta de DNS e suporte à exportação nos formatos Prometheus e JSON. O painel do NGINX Plus exibe as novas métricas por localização e conta com novas guias para métricas de DNS e métricas sobre clusters do NGINX Plus.
• Modo de simulação para testar limites de taxa – Definir os limites de taxa corretos para o tráfego de produção é difícil e muito arriscado – um erro pode afetar seriamente a experiência de uma grande parcela dos seus usuários. Com o novo modo de simulação, você pode entender o efeito dos seus limites de taxa sobre o tráfego de produção sem de fato aplicá-los.
• Aprimoramentos no armazenamento de chave-valor – Agora você pode armazenar intervalos de endereços IP no armazenamento de chave-valor, além de endereços individuais, e definir prazos de expiração para entradas individuais.
• Controle dinâmico de largura de banda – Ao configurar limites de largura de banda, agora você pode definir a taxa como uma variável, o que permite aplicar limites diferentes com base em qualquer atributo do tráfego de entrada.

Mudanças importantes de comportamento

• APIs obsoletas – O NGINX Plus R13 (lançado em agosto de 2017) apresentou a nova API do NGINX Plus para coleta de métricas e reconfiguração dinâmica de grupos upstream, substituindo as APIs Status e Upstream Conf, que anteriormente implementavam essas funções. Conforme anunciado na época, as APIs descontinuadas continuaram disponíveis e com suporte por um período significativo, que terminou com o NGINX Plus R16. Se a sua configuração incluir as diretivas status e/ou upstream_conf, você deverá substituí-las pela diretiva api como parte da atualização para a R19. Para obter orientações e assistência na migração para a nova API do NGINX Plus, consulte o guia de transição em nosso blog ou entre em contato com nossa equipe de suporte.
• Novos sistemas operacionais compatíveis –
  • Alpine 3.10
  • Debian 10 (“Buster”)
  • Ubuntu 19.04 (“Disco”)
• Sistemas operacionais mais antigos não são mais compatíveis –
  • Debian 8 (“Jessie”)
  • Ubuntu 14.04 (“Trusty”)
  • Ubuntu 18.10 (“Cosmic”)

Para obter mais informações sobre as plataformas compatíveis, consulte as especificações técnicas do NGINX Plus e dos módulos dinâmicos.

Novos recursos em detalhes

Novos recursos tornam o monitoramento ainda mais flexível

O NGINX Plus R19 torna o monitoramento ainda mais flexível, ampliando tanto os tipos de métricas que você pode coletar quanto as formas de analisá-las.

Métricas por local

A API do NGINX Plus fornece uma ampla variedade de métricas de monitoramento em tempo real, incluindo vários contadores referentes a um servidor virtual quando você inclui a diretiva status_zone no bloco server{} correspondente. Com o NGINX Plus R19, agora você pode coletar métricas para blocos location individuais, além do bloco server{} pai (ou em vez dele), adicionando a diretiva status_zone a esses blocos location. Esse monitoramento mais granular permite identificar mais rapidamente as partes exatas do seu site que estão gerando erros, tornando a solução de problemas mais eficaz.

A configuração a seguir habilita a coleta de métricas para um site inteiro e também para todas as solicitações a URIs que começam com /admin/.

Carregando exemplo de código…

Em seguida, você pode acessar as métricas no 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
  }
}

Também é possível inserir a diretiva status_zone em um bloco if, mas observe que as métricas são contabilizadas apenas uma vez para um determinado local e com base na última diretiva status_zone encontrada durante o processamento da solicitação. A configuração a seguir amplia o exemplo anterior, coletando métricas separadas sempre que uma solicitação ao local /admin/ inclui uma string de consulta.

Carregando exemplo de código…

Métricas do resolvedor de DNS

A API do NGINX Plus também foi ampliada com métricas para monitorar a atividade de consultas DNS, especialmente os tipos de solicitações DNS e os status das respostas. Para coletar métricas sobre um grupo de servidores DNS que o NGINX Plus consulta para resolver nomes, adicione o parâmetro status_zone à diretiva resolver.

Carregando exemplo de código…

Em seguida, você pode acessar as métricas no 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
    }
  }
}

Atualizações no painel de monitoramento de atividades em tempo real

O painel de monitoramento de atividades em tempo real do NGINX Plus oferece um local centralizado e conveniente para acompanhar as métricas coletadas pela API do NGINX Plus. O painel foi ampliado no NGINX Plus R19 para incluir as novas métricas do resolvedor e por localização mencionadas acima. Além disso, agora ele apresenta métricas relacionadas ao compartilhamento do estado de execução em um cluster (conforme habilitado pelo módulo Sincronização de Zonas), que antes só podiam ser acessadas por meio da API do NGINX Plus.

Há duas guias renomeadas e duas novas guias:

• Zonas HTTP é o novo nome da guia Zonas de servidor. Agora, a guia exibe métricas sobre blocos location, além de blocos server.
• Upstreams HTTP é o novo nome da guia Upstreams (upstreams). Isso facilita a identificação quando os módulos HTTP e TCP/UDP estão configurados.
• A nova guia Cluster exibe métricas sobre o compartilhamento de estado em clusters do NGINX Plus.
• A nova guia Resolvedores exibe métricas sobre a atividade de consulta de DNS.

Para explorar o novo painel, acesse https://demo.nginx.com/.

Novo módulo para monitoramento com o Prometheus

A API do NGINX Plus retorna métricas no formato JSON, que é um formato comum e conveniente para integração com soluções externas de monitoramento e gerenciamento de desempenho de aplicações (APM). Agora, você também pode exportar métricas no formato Prometheus, que é particularmente popular em ambientes Kubernetes.

O módulo Prometheus-njs disponibiliza as métricas do Prometheus. Para habilitar as métricas exportadas:

1. Instale o módulo Prometheus-njs.
2. Configure a API do NGINX Plus.
3. Configure um local dedicado para a coleta de métricas do Prometheus no arquivo de configuração do NGINX Plus.

   Carregando exemplo de código…

4. Configure o Prometheus para obter métricas do NGINX Plus especificando o endereço de rede da instância do NGINX Plus em uma seção scrape_config no arquivo de configuração do Prometheus.

Testando limites de taxa no modo de simulação

O NGINX Plus oferece uma abordagem muito flexível para a limitação de taxa. É possível monitorar e aplicar vários limites de taxa simultaneamente. A aplicação desses limites pode ocorrer de cinco maneiras diferentes, incluindo atrasar solicitações excessivas, rejeitá-las imediatamente e permitir uma rajada de solicitações sem restrições antes de aplicar os limites, além de combinações desses comportamentos. Para obter uma explicação detalhada, consulte nosso blog.

Embora essa flexibilidade permita um controle de taxa altamente refinado, como determinar, em primeiro lugar, o limite de taxa adequado para o seu tráfego? Como saber antecipadamente se o limite de taxa planejado é alto demais (caso em que seus servidores podem ficar sobrecarregados) ou baixo demais (caso em que a experiência do usuário pode ser prejudicada)?

A melhor fonte de informações é o log de erros do NGINX Plus, no qual uma entrada detalhada como a seguinte é criada quando o NGINX Plus atrasa ou rejeita uma solicitação:

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"

A entrada fornece informações úteis, como quantas solicitações por milissegundo acima da taxa configurada esta solicitação representa (o campo excess), o limite específico que foi excedido (o campo zone) e o endereço IP do cliente (o campo client). No entanto, essas informações só são úteis para fins de planejamento se você puder obtê-las antes de efetivamente aplicar os limites ao seu tráfego.

O NGINX Plus R19 adiciona esse recurso de previsão com um modo de “simulação” para limitação de taxa. As entradas de log são criadas normalmente, mas os limites de taxa não são aplicados. Para habilitar o modo de simulação, inclua a nova diretiva limit_req_dry_run no mesmo bloco que a diretiva ou as diretivas limit_req.

No exemplo a seguir, as diretivas limit_req_zone definem quatro limites de taxa diferentes, variando de 10.000 solicitações por segundo a 10 solicitações por segundo. Aplicamos essas taxas com as diretivas limit_req no bloco location raiz (linhas 9–12), juntamente com a diretiva limit_req_dry_run para desabilitar a aplicação dos limites.

Carregando exemplo de código…

O NGINX Plus grava uma entrada de log, claramente identificada com dry run, para cada solicitação que excederia um determinado limite de taxa. Em nossa análise do log, podemos então filtrar as entradas pelo campo zone para determinar qual dos limites de taxa produz o comportamento desejado.

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"

Aprimoramentos no armazenamento de chave-valor

Com o armazenamento de chave-valor em memória do NGINX Plus, você pode usar a API do NGINX Plus para configurar dinamicamente o gerenciamento de tráfego com base nos atributos da solicitação. Alguns exemplos de casos de uso incluem inclusão dinâmica de endereços IP em listas de bloqueio, limitação dinâmica de largura de banda, e armazenamento em cache de tokens de autenticação.

Suporte a intervalos de rede

O NGINX Plus R19 amplia o armazenamento de chave-valor, adicionando suporte a intervalos de rede IP (sub-redes) ao suporte existente para endereços IP individuais. Isso significa que uma única entrada no armazenamento de chave-valor pode corresponder a todos os endereços IP de um intervalo de rede, simplificando a configuração e economizando seu tempo, pois não é necessário adicionar individualmente os endereços que compõem um intervalo. O armazenamento de chave-valor usa a notação CIDR para representar intervalos de rede. Por exemplo, 192.168.13.0/24 representa os endereços de 192.168.13.0 a 192.168.13.255. Há suporte para endereços e intervalos IPv4 e IPv6.

Para habilitar intervalos de rede, inclua o novo parâmetro type=ip na diretiva keyval_zone, como na configuração a seguir para a inclusão dinâmica de endereços IP em uma lista de bloqueio. Quando o NGINX Plus realiza uma consulta, qualquer endereço IP dentro de um intervalo de rede armazenado no repositório de chave-valor resulta em uma correspondência.

Carregando exemplo de código…

A linha 2 especifica que a variável $in_denylist é avaliada por meio de uma consulta ao armazenamento de chave-valor denylist, usando $remote_addr (o endereço IP do cliente) como chave. Em seguida, o bloco simples if (linhas 8–10) rejeita uma solicitação quando o endereço IP do cliente está na lista de bloqueio.

O comando curl a seguir invoca a API do NGINX Plus para criar uma entrada no armazenamento de chave-valor para o intervalo de rede mencionado acima.

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

Tempos limite de expiração por entrada

Na seção anterior, o parâmetro timeout=24h da diretiva keyval_zone na linha 1 de denylist.conf significa que cada entrada no armazenamento de chave-valor da lista de bloqueio expira (e é removida do armazenamento) 24 horas após sua criação.

Com o NGINX Plus R19, você pode substituir o tempo limite padrão (definido para todo o armazenamento de chave-valor pelo parâmetro timeout) por um tempo limite diferente para qualquer entrada individual. Os tempos limite individuais podem ser maiores ou menores que o padrão.

Para criar uma entrada com um tempo limite diferente do padrão, forneça o valor como um objeto JSON com dois campos:

• value – Defina como o valor desejado, neste caso, 1 para preencher a variável $in_denylist variable
• expire – Defina como o número de milissegundos após a criação até que o valor expire

O JSON a seguir representa uma entrada na lista de bloqueio para localhost (127.0.0.1) que expira em 1 hora (3.600.000 milissegundos).

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

O comando curl a seguir cria essa entrada no armazenamento de chave-valor:

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

Controle dinâmico de largura de banda

A diretiva limit_rate define a taxa (número de bytes por segundo) na qual o NGINX Plus envia a resposta a uma solicitação HTTP, e a diretiva limit_rate_after define o número de bytes que o NGINX Plus envia antes que esse limite seja aplicado. Com o NGINX Plus R19, o parâmetro de cada diretiva pode ser uma variável em vez de um valor estático, permitindo o controle dinâmico do uso da largura de banda com base nos atributos da solicitação.

A configuração de exemplo a seguir define a largura de banda de acordo com a versão do TLS usada pelo cliente, oferecendo, na prática, respostas mais rápidas aos navegadores mais modernos.

Carregando exemplo de código…

Em versões anteriores do NGINX Plus, era possível limitar a largura de banda definindo a variável $limit_rate; recomendamos usar este método mais simples. Para obter detalhes, consulte a documentação da diretiva limit_rate.

As diretivas proxy_download_rate e proxy_upload_rate para tráfego TCP/UDP agora também aceitam um parâmetro variável.

Para uma limitação de largura de banda ainda mais sofisticada, você pode usar extensões de script, como o módulo JavaScript do NGINX (njs) para implementar uma lógica personalizada e avançada que determine o limite de largura de banda adequado para uma determinada conexão.

Atualizações do ecossistema NGINX Plus

Módulo JavaScript do NGINX

O módulo JavaScript do NGINX (njs) foi atualizado para a versão 0.3.5. As melhorias mais relevantes (acumuladas desde as versões anteriores) são:

• Suporte a funções de seta (agradecimentos a 洪志道 [Hong Zhi Dao] e Artem S. Povalyukhin)
• Um objeto process global (especialmente útil para ler variáveis de ambiente)
• String.prototype.trim funções

Faça upgrade ou experimente o NGINX Plus

Se você estiver usando o NGINX Plus, recomendamos enfaticamente que faça a atualização para o NGINX Plus R19 o mais rápido possível. Você também terá acesso a diversas correções e melhorias adicionais, além de facilitar o suporte da NGINX quando precisar abrir um chamado.

Antes de prosseguir com a atualização, analise atentamente os novos recursos e as mudanças de comportamento descritos nesta publicação do blog.

Se você ainda não experimentou o NGINX Plus, recomendamos que faça um teste – seja para segurança, balanceamento de carga e gateway de API, seja como um servidor web com suporte completo e APIs avançadas de monitoramento e gerenciamento. Comece hoje mesmo com uma avaliação gratuita de 30 dias. Veja por si mesmo como o NGINX Plus pode ajudar você a disponibilizar e escalar suas aplicações.

Sobre o autor

Liam CrillyDiretor Sênior de Gestão de Produtos

Mais publicações de Liam Crilly