BLOG | NGINX

Anunciando o NGINX Plus R19

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Miniatura de Liam Crilly
Liam Crilly
Publicado em 03 de setembro de 2019


Temos o prazer de anunciar que o NGINX Plus Release 19 (R19) já está disponível. O NGINX Plus é o único balanceador de carga, cache de conteúdo, servidor web e gateway de API tudo-em-um . Baseado no NGINX Open Source, o NGINX Plus inclui recursos aprimorados exclusivos e suporte premiado. O foco principal do lançamento é o monitoramento, com novos recursos que o tornam mais granular e flexível, para maior confiabilidade de seus aplicativos em escala.

Os novos recursos do NGINX Plus R19 incluem:

  • Monitoramento mais flexível – Adicionamos novos recursos para insights mais detalhados e análises mais fáceis do seu ecossistema NGINX Plus, incluindo coleta opcional de métricas separadas para blocos de localização , novas métricas sobre atividade de pesquisa de DNS e suporte para exportação no formato Prometheus e JSON. O painel do NGINX Plus exibe as novas métricas por local e tem novas guias para as métricas de DNS e métricas sobre clusters do NGINX Plus.
  • Modo de teste para testar limites de taxa – Definir os limites de taxa corretos para tráfego de produção é difícil e muito arriscado – se errar, você poderá impactar seriamente a experiência do usuário de uma grande proporção de seus usuários. Com o novo modo de teste, você pode entender o efeito dos seus limites de taxa no tráfego de produção sem realmente aplicá-los.
  • Melhorias no armazenamento de chave-valor – Agora você pode armazenar intervalos de endereços IP no armazenamento de chave-valor junto com endereços individuais e definir tempos de expiração em 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, permitindo aplicar limites diferentes com base em qualquer atributo do tráfego de entrada.

Mudanças importantes no comportamento

  • APIs obsoletasO NGINX Plus R13 (lançado em agosto de 2017) introduziu a novíssima API NGINX Plus para coleta de métricas e reconfiguração dinâmica de grupos upstream, substituindo as APIs Status e Upstream Conf que implementavam essas funções anteriormente. Conforme anunciado na época, as APIs obsoletas continuaram disponíveis e com suporte por um período significativo de tempo, que terminou com o NGINX Plus R16 . Se sua configuração incluir as diretivas status e/ou upstream_conf , você deverá substituí-las pela diretiva api como parte da atualização para o R19.

    Para obter orientação e assistência na migração para a nova API NGINX Plus , consulte o guia de transição em nosso blog ou entre em contato com nossa equipe de suporte.

  • Novos sistemas operacionais suportados

    • Alpino 3.10
    • Debian 10 (“Buster”)
    • Ubuntu 19.04 (“Disco”)
  • Sistemas operacionais mais antigos não são mais suportados

    • Debian 8 (“Jessie”)
    • Ubuntu 14.04 (“Confiável”)
    • Ubuntu 18.10 (“Cósmico”)

Para obter mais informações sobre as plataformas suportadas, 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 os tipos de métricas que você pode coletar e as maneiras de analisá-las.

Métricas por localização

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

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

Você pode então acessar as métricas no endpoint http/location_zones .

$ curl http://localhost:8080/api/5/http/location_zones { "www_admin": { "solicitações": 3393, "respostas": { "1xx": 0, "2xx": 3307, "3xx": 81, "4xx": 5, "5xx": 0, "total": 3393 }, "descartado": 0, "recebido": 15403, "enviado": 835227 } }

Também é possível colocar a diretiva status_zone dentro de um bloco if , mas observe que as métricas são contadas apenas uma vez para um determinado local e a partir da última diretiva status_zone encontrada durante o processamento da solicitação. A configuração a seguir estende o exemplo anterior coletando métricas separadas sempre que uma solicitação para o local /admin/ inclui uma string de consulta.

Métricas do DNS Resolver

A API NGINX Plus também foi ampliada com métricas para rastrear atividades de pesquisa de DNS, em particular sobre tipos de solicitações de DNS e status de resposta. Para coletar métricas sobre um grupo de servidores DNS que o NGINX Plus consulta para pesquisas de nomes, adicione o parâmetro status_zone à diretiva resolver .

Você pode então acessar as métricas no ponto de extremidade dos resolvedores .

$ curl http://localhost:8080/api/5/resolvers { "internal_dns": { "solicitações": { "nome": 132, "serviço": 0, "endereço": 0 }, "respostas": { "noerror": 130, "antigo": 0, "falha de serviço": 0, "nxdomain": 0, "notimp": 0, "recusado": 0, "tempo limite": 2, "desconhecido": 0 } } }

Atualizações no Painel de Monitoramento de Atividades ao Vivo

O painel de monitoramento de atividade ao vivo do NGINX Plus fornece um local centralizado conveniente para rastrear métricas coletadas pela API do NGINX Plus . O painel foi estendido no NGINX Plus R19 para incluir o novo resolvedor e as métricas por local discutidas acima. Além disso, ele agora relata métricas relacionadas ao compartilhamento de estado de tempo de execução em um cluster (conforme habilitado com o módulo Zone Synchronization ), que antes eram acessíveis apenas por meio da API NGINX Plus .

Há duas abas renomeadas e duas novas abas:

  • Zonas HTTP é o novo nome para a aba Zonas do servidor . A guia agora exibe métricas sobre blocos de localização e também blocos de servidor .
  • HTTP Upstreams é o novo nome para a aba Upstreams . Isso fornece clareza quando os módulos HTTP e TCP/UDP são configurados.
  • A nova guia Cluster exibe métricas sobre compartilhamento de estado em clusters NGINX Plus.
  • A nova guia Resolvedores exibe métricas sobre a atividade de pesquisa de DNS.

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

Captura de tela do painel de monitoramento de atividade ao vivo do NGINX Plus

Novo módulo para monitoramento do Prometheus

A API 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 aplicativos (APM). Agora você também pode exportar métricas no formato Prometheus, que é particularmente popular em ambientes Kubernetes.

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

  1. Instale o módulo Prometheus-njs .
  2. Configurar 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.

  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 execução a seco

O NGINX Plus oferece uma abordagem muito flexível para limitação de taxa. Vários limites de taxa podem ser rastreados e aplicados ao mesmo tempo. A execução em si vem em cinco tipos diferentes – incluindo atrasar solicitações excessivas, rejeitá-las imediatamente e permitir uma explosão de solicitações irrestritas antes da execução – além de combinações desses comportamentos. Para uma explicação detalhada, veja nosso blog .

Embora essa flexibilidade possa resultar em uma limitação de taxa altamente refinada, como você determina o limite de taxa apropriado para seu tráfego em primeiro lugar? Como você pode saber com antecedência se o limite de taxa planejado está muito alto (caso em que seus servidores podem ficar sobrecarregados) ou muito baixo (caso em que a experiência do usuário pode ser afetada)?

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

2019/09/03 11:42:12 [erro] 57#57: *339 limitando solicitações, excesso: 0,600 por zona "my_limit", cliente: 172.17.0.1, servidor: www.example.com, solicitação: "OBTER / HTTP/1.1", host: "www.example.com:80"

A entrada informa coisas úteis, como quantas solicitações por milissegundo acima da taxa configurada essa solicitação representa (o campo de excesso ), o limite específico que foi excedido (o campo de zona ) e o endereço IP do cliente (o campo do cliente ). Mas as informações ainda serão úteis para fins de planejamento somente se você puder obtê-las antes de realmente impor os limites ao seu tráfego.

O NGINX Plus R19 adiciona essa capacidade preditiva 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 teste, inclua a nova diretiva limit_req_dry_run no mesmo bloco que a diretiva limit_req ou diretivas.

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

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

2019/09/03 11:56:26 [erro] 142#142: *22282 limitando solicitações, teste , excesso: 1.000 por zona "1000rs", cliente: 172.17.0.1, servidor: www.example.com, solicitação: "OBTER / HTTP/1.1", host: "www.example.com:80"

Melhorias no Key-Value Store

Com o armazenamento de chave-valor na memória para 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. Exemplos de casos de uso incluem lista de negação dinâmica de endereços IP , limitação dinâmica de largura de banda e armazenamento em cache de tokens de autenticação .

Suporte para intervalos de rede

O NGINX Plus R19 estende o armazenamento de chave-valor adicionando suporte para 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 em um intervalo de rede, simplificando a configuração e economizando tempo, porque você não precisa 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. Endereços e intervalos IPv4 e IPv6 são suportados.

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

A linha 2 especifica que a variável $in_denylist é avaliada executando uma pesquisa no armazenamento de chave-valor da lista de bloqueios , usando $remote_addr (o endereço IP do cliente) como a chave. O bloco if simples (linhas 8 a 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 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 para a diretiva keyval_zone na linha 1 de denylist.conf significa que cada entrada no armazenamento de chave-valor da lista de bloqueios expira (e é removida do armazenamento) 24 horas após ser criada.

Com o NGINX Plus R19 , você pode substituir o tempo limite padrão (definido para todo o armazenamento de chave-valor pelo parâmetro de tempo limite ) 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 não padrão, forneça o valor como um objeto JSON com dois campos:

  • valor – Defina o valor desejado, neste caso1 para preencher a variável $in_denylist
  • expire – Defina o número de milissegundos após a criação em que o valor expira

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

{
"127.0.0.1": {
"valor": "1",
"expira": 3600000
}
}

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

$ curl -X POST -d '{"127.0.0.1":{"valor":"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 para 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.

O exemplo de configuração a seguir define a largura de banda de acordo com a versão do TLS usada pelo cliente, recompensando efetivamente navegadores mais modernos com respostas mais rápidas.

Em versões anteriores do NGINX Plus, você podia limitar a largura de banda definindo a variável $limit_rate ; recomendamos que você use esse método mais simplificado. 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 NGINX (njs), para implementar lógica avançada e personalizada para determinar o limite de largura de banda apropriado para uma determinada conexão.

Atualizações do ecossistema NGINX Plus

Módulo JavaScript NGINX

O módulo JavaScript NGINX (njs) foi atualizado para a versão 0.3.5 . As melhorias mais notáveis (cumulativas de versões anteriores) são:

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

Atualize ou experimente o NGINX Plus

Se você estiver executando o NGINX Plus, recomendamos fortemente que atualize para o NGINX Plus R19 o mais rápido possível. Você também receberá uma série de correções e melhorias adicionais, e isso ajudará o NGINX a ajudar você quando precisar abrir um tíquete de suporte.

Revise cuidadosamente os novos recursos e mudanças de comportamento descritos nesta postagem do blog antes de prosseguir com a atualização.

Se você ainda não experimentou o NGINX Plus, recomendamos que experimente – para segurança, balanceamento de carga e gateway de API, ou como um servidor web totalmente suportado com APIs aprimoradas de monitoramento e gerenciamento. Você pode começar hoje mesmo com uma avaliação gratuita de 30 dias . Veja você mesmo como o NGINX Plus pode ajudar você a entregar e dimensionar seus aplicativos.


"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."