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:
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.APIs obsoletas – O 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 –
Sistemas operacionais mais antigos não são mais suportados –
Para obter mais informações sobre as plataformas suportadas, consulte as especificações técnicas do NGINX Plus e dos módulos dinâmicos .
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.
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.
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 } } }
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:
de localização
e também blocos de servidor
.Para explorar o novo painel, visite https://demo.nginx.com/ .
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:
Configure um local dedicado para a coleta de métricas do Prometheus no arquivo de configuração do NGINX Plus.
scrape_config
no arquivo de configuração do Prometheus.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"
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 .
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
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 expiraO 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
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.
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:
de processo
global (especialmente útil para ler variáveis de ambiente)String.prototype.trim
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."