NGINX Stub Status: monitorizar em tempo real a atividade do servidor Web

O que indica o estado «Stub» do NGINX

Estado do Stub do NGINX fornece métricas básicas do servidor Web em formato de texto através de um ponto de extremidade HTTP configurado. A resposta descreve a atividade do conjunto de processos NGINX consultado: nomeadamente, as ligações dos clientes e o total de pedidos contabilizados. Podes aceder a esta informação localmente e compará-la repetidamente, sem necessidade de recorrer a um sistema de monitorização completo.

Nesse contexto, tens de distinguir dois tipos de valores: um Instantâneo mostra, por exemplo, quantas ligações de cliente estão ativas no momento da consulta. Contadores globais como requests por outro lado, indicam o número total de consultas registadas. Só a comparação de vários valores de contagem em intervalos de tempo conhecidos permite tirar conclusões sobre a taxa de consultas.

Os valores não constituem uma medição direta da utilização da CPU ou da memória, nem representam uma percentagem da capacidade disponível do servidor web. A existência de muitas ligações abertas pode ter diversas causas e implicações em termos de custos. Por isso, para avaliar a carga real, é necessário recorrer adicionalmente a métricas de recursos e a informações sobre tempos de resposta e erros.

O «Stub Status» não desagrega os números por site virtual ou URL solicitada. Se uma instalação gerir vários sites, não é possível determinar, apenas a partir do ponto final, qual deles é responsável por um aumento. No caso de existirem várias instâncias do NGINX, deve registar os respetivos valores separadamente e atribuí-los de forma inequívoca.

A própria consulta à página de estado constitui, por si só, um pedido HTTP e influencia ligeiramente os contadores observados. Este facto deve ser tido em conta na interpretação de volumes de pedidos reduzidos ou de consultas muito frequentes. Uma única consulta fornece, de qualquer forma, apenas um instantâneo; só a evolução ao longo do tempo revela se a atividade se alterou.

Distinguir ligações e pedidos

O valor Ligações ativas inclui ligações ativas do cliente, incluindo as ligações em espera. Por isso, não conta apenas as ligações através das quais está a ser transmitida uma resposta nesse momento. Os estados «Reading», «Writing» e «Waiting» ajudam a contextualizar este número total, mas não descrevem nem o consumo da CPU nem o número de aplicações em execução.

Quando uma solicitação é recebida, a ligação fica no estado «Reading», enquanto o NGINX lê o cabeçalho da solicitação. Posteriormente, pode passar para o estado «Writing» quando o NGINX processa ou escreve a resposta. Isso não significa que, durante todo esse tempo, haja efetivamente um fluxo de bytes para o cliente: a espera por uma resposta do servidor upstream também pode fazer parte desse processo.

Se uma ligação permanecer aberta após uma resposta a outras consultas, pode ser considerada como Em espera aparecer. Este estado inclui ligações de cliente inativas que aguardam um próximo pedido. Por isso, um valor elevado de «Waiting», por si só, não prova que haja sobrecarga; pode também corresponder a um ambiente com muitas ligações reutilizáveis.

As ligações e os pedidos são grandezas diferentes: através de uma ligação Keepalive podem ser processados vários pedidos sucessivamente. No HTTP/2, é possível transmitir várias solicitações através de uma única ligação. Por isso, não é possível deduzir um número fixo de solicitações a partir do número de ligações abertas, e o contador de solicitações não tem de aumentar na mesma proporção que os contadores de ligações.

Para uma avaliação prática, vale a pena comparar vários pedidos: se o «Waiting» aumentar, enquanto os tempos de resposta e os erros se mantêm normais, trata-se, numa primeira fase, de uma observação e não de um sinal de alarme. A forma como a reutilização e os seus limites podem ser configurados é explicada no artigo sobre Pedidos Keepalive do NGINX.

Verificar o módulo e a versão

Para utilizar o Stub Status, é necessária uma instalação do NGINX com o módulo ngx_http_stub_status_module, acesso à sua configuração e, posteriormente, a possibilidade de consultar o ponto final protegido a partir do espaço de rede previsto. O módulo não é incluído por predefinição na compilação do NGINX. A sua inclusão num pacote de distribuição depende do pacote em questão e deve ser verificada localmente.

Verifique no terminal a versão e os parâmetros de configuração do ficheiro binário do NGINX efetivamente utilizado pelo serviço. O comando seguinte apresenta estas informações; entre os parâmetros, destaca-se --with-http_stub_status_module para a opção de compilação correspondente.

nginx -V

O fator decisivo é a ficheiro binário correto: Um programa iniciado através do caminho de pesquisa nginx pode ser uma instalação diferente daquela em que o serviço está a ser executado. Em caso de dúvida, verifica a configuração do serviço e o comando de execução utilizado na mesma. Em seguida, se for caso disso, executa explicitamente o ficheiro binário em questão, em vez de deduzir o serviço em produção a partir da saída de outra instalação.

A versão também influencia a forma como a diretiva é escrita. A partir do NGINX 1.7.5, é stub_status utilizada sem argumentos; as versões mais antigas exigiam um argumento qualquer, como, por exemplo, on. O limite de versão é uma informação de compatibilidade, não uma suposição sobre qual a versão que está instalada no teu sistema.

Se a opção de compilação não estiver presente na instalação verificada, deve esclarecer, antes de efetuar qualquer alteração na configuração, qual o pacote ou compilação adequado previsto para o seu ambiente. Um local de estado, por si só, não substitui um módulo em falta. As alterações aos pacotes e à configuração dos serviços devem ser submetidas ao procedimento de operação e aprovação aplicável.

Configurar o ponto final de estado como protegido

Para consultar o estado local, podes utilizar um Ouvinte de loopback configurar. O exemplo seguinte é um ficheiro de configuração para o existente http-Contexto, não é um comando de terminal. Pressupõe que o módulo de estado «stub» esteja disponível e que a porta de exemplo 8088, na morada em questão, não esteja já ocupada por outro serviço.

server {
    listen 127.0.0.1:8088;
    server_name localhost;

    location = /stub_status {
        stub_status;
        allow 127.0.0.1;
        deny all;
    }
}

A ligação a 127.0.0.1 limita este ouvinte à interface de loopback IPv4 local. A localização exata apenas atribui o caminho especificado; a diretiva stub_status fornece aí os dados de estado. Assim, o listener não fica acessível através de outras interfaces IPv4, independentemente de os restantes sites serem públicos ou não.

O Regras de acesso complementam a regra de ligação: o NGINX verifica-as sequencialmente até encontrar a primeira correspondência. O endereço IPv4 local é permitido; todos os outros endereços são rejeitados. Como esta localização contém regras próprias, as regras de acesso de um contexto superior não são herdadas adicionalmente. Por isso, verifica a configuração completa antes de aplicares este exemplo.

No caso dos contentores, o espaço de rede é determinante: um exportador num contentor separado acede, através do seu próprio localhost Normalmente, não é a interface de loopback do contentor NGINX. Para uma consulta remota, é necessário um caminho de ligação privado cuidadosamente planeado e controlos de acesso adequados. Não tornes a página de estado publicamente acessível; esta contém informações operacionais.

Verificar a configuração e consultar o estado

Após a introdução, verifica primeiro a configuração no terminal. O comando seguinte verifica a sintaxe e tenta abrir os ficheiros referenciados. Para tal, utiliza o ficheiro binário do NGINX específico para o serviço e, se for o caso, o seu caminho de configuração diferente; uma verificação bem-sucedida ainda não ativa a alteração.

nginx -t

A Reload aprovado é um passo produtivo independente. Execute-o apenas após aprovação e de acordo com os procedimentos operacionais do seu ambiente. Ao executar o «reload», o NGINX recarrega a configuração, inicia novos workers com a nova configuração e encerra os antigos de forma ordenada. Verifica posteriormente o sucesso da operação e os registos, em vez de deduzir que a alteração está ativa apenas com base na verificação de sintaxe bem-sucedida.

Após a ativação ter sido aprovada, podes aceder localmente ao ponto final na mesma rede com curl consultar. O botão -i mostra, além do corpo da resposta, também o estado HTTP e os cabeçalhos. O exemplo seguinte pressupõe que o ouvinte e o caminho já estejam definidos na configuração do ficheiro.

curl -i http://127.0.0.1:8088/stub_status

Espera-se uma resposta HTTP bem-sucedida com dados de estado como Texto, e não como JSON. Em caso de erro, o código de estado e os registos do NGINX ajudam a identificar a origem do problema. No entanto, uma consulta local bem-sucedida apenas demonstra que esta via de acesso funciona: não prova que nenhuma outra configuração torne o ponto final acessível a partir do exterior.

Ler valores de estado e calcular taxas

A saída combina os estados atuais das ligações com valores acumulados. Para a interpretação, esta distinção é mais importante do que o valor absoluto de um único valor: Um valor atual descreve o estado no momento da consulta; um contador total indica os eventos contabilizados até esse momento. A tabela apresenta os campos individuais e os erros típicos.

Do contador requests é possível calcular uma média Taxa de consultas Calcular para um intervalo: subtrai o primeiro valor do segundo e divide a diferença pelos segundos decorridos. Exemplo ilustrativo de cálculo, não se trata de uma medição: se o valor aumentar de 12 000 para 12 600 em 60 segundos, 600 dividido por 60 resulta numa média de 10 pedidos por segundo.

Esta média não indica nem o pico mais elevado a curto prazo nem quais as URLs que foram acedidas. Anota, para cada acesso, a hora e a instância consultada. Se o contador diminuir ou se alternares entre instâncias, não deves interpretar a diferença simples como taxa sem a verificar; inicia uma nova série de comparação para a instância em questão.

Se estiveres a comparar intervalos de duração diferente, utiliza sempre o tempo efetivamente decorrido, em vez do intervalo de consulta previsto. Por exemplo, uma consulta atrasada de dois minutos requer um divisor diferente do de uma consulta após um minuto. Um período de análise mais longo suaviza mais as flutuações de curto prazo; os intervalos curtos tornam as alterações mais visíveis, mas aumentam a proporção de consultas de estado.

A própria consulta de estado é também um pedido HTTP e tem um impacto ligeiro nos contadores monitorizados. Isto torna-se particularmente significativo quando o tráfego é muito baixo ou quando as consultas são frequentes. Um intervalo de consulta regular e documentado facilita a consideração desses fatores de monitorização na interpretação dos resultados.

No caso de várias instâncias, calcula-se primeiro a taxa a partir dos valores sucessivos de cada instância individual. Só depois é que as taxas para períodos comparáveis podem ser agrupadas. Se faltar um registo ou se a atribuição de uma instância se alterar, a lacuna resultante deve permanecer visível, em vez de se simular uma evolução aparentemente contínua.

Analisar erros e limites

Se o ponto final de estado responder com um código HTTP 403, verifique primeiro o endereço de origem que chega efetivamente ao NGINX e as regras de acesso da localização. allow e deny são avaliadas por ordem, até à primeira correspondência. As regras próprias do local substituem, se for o caso, as regras herdadas; não as complementam automaticamente.

No caso de um erro HTTP 404, a investigação deve começar noutro ponto: a porta e o listener, o caminho solicitado e o bloco de servidor selecionado estão corretos? Verifique também se a configuração pretendida está efetivamente ativa após a atualização. Uma chamada local bem-sucedida numa porta ou caminho diferente não prova que a localização pretendida tenha sido acedida.

Se não for obtida qualquer resposta HTTP, distingue a acessibilidade do listener de uma resposta com estado de erro. Verifique, em primeiro lugar, o endereço, a porta e o espaço de rede do processo que está a efetuar a consulta, bem como o estado do serviço. Só quando for estabelecida uma ligação ao listener correto é que o estado HTTP e a localização selecionada ajudam a restringir ainda mais a análise.

Para a análise contínua de erros, vale a pena comparar os contadores globais aceita e trata. Normalmente, são iguais. Se a diferença entre eles aumentar, pode estar em causa um limite de recursos atingido; no entanto, a comparação dos contadores, por si só, não revela nem a causa concreta nem o número de pedidos HTTP rejeitados. Por isso, inclua os registos de erros e a configuração na investigação.

Uma diferença já existente indica, numa primeira fase, apenas a diferença entre os dois contadores totais. Para avaliar se a situação se alterou durante o período de observação, compara essa diferença ao consultar a mesma instância várias vezes. Regista o período em questão, para que possas procurar as entradas de registo e os eventos operacionais relevantes.

A diretiva worker_connections limita as ligações por trabalhador, não apenas as ligações de cliente. Isto inclui, por exemplo, também as ligações a servidores proxy; além disso, os limites dos descritores de ficheiros podem impor restrições. O número de ligações ativas dividido pelo número de trabalhadores vezes worker_connections Por conseguinte, não é possível obter uma avaliação fiável da utilização da capacidade. Em vez disso, verifica os limites reais e o restante consumo de recursos no contexto.

Uma alteração dos limites de ligação não deve basear-se apenas num valor de estado elevado. Verifique primeiro se um limite foi efetivamente atingido e quais os outros recursos ou ligações a montante envolvidos. Planeie eventuais alterações em conjunto com a monitorização de erros e tempos de resposta e verifique-as de acordo com o procedimento operacional previsto.

Classificar os processos e os problemas a montante

Uma única consulta de estado mostra apenas um momento específico. Por outro lado, consultas repetidas a intervalos fixos ajudam a identificar se os estados de ligação aumentam para além de um nível normal ou se voltam a diminuir após um pico. Registe várias instâncias do NGINX separadamente e identifique qual a instância correspondente a cada série temporal; caso contrário, as mudanças entre pontos finais podem distorcer a evolução.

Um alto Valor de espera descreve ligações de clientes em espera, atualmente inativas. Por si só, não constitui indício de sobrecarga: no caso de ligações reutilizadas, os clientes podem estar à espera de novas solicitações. Um aumento torna-se mais significativo quando o comparas com os tempos de resposta, erros e métricas de recursos relativos ao mesmo período.

Fica Escrita Se o tempo de resposta permanecer elevado durante um período prolongado, analise tanto os tempos de upstream como o comportamento dos clientes. Este estado não significa que estejam a ser enviados bytes de forma contínua; pode também incluir o tempo de espera por uma resposta de upstream. O estado «Stub» não identifica nem o serviço backend afetado nem a causa de um atraso.

Para a identificação, são úteis dados complementares: os registos de acesso e os tempos de upstream registados mostram quais as solicitações e os backends que se destacam; os registos de erros fornecem indicações sobre ligações falhadas. No caso de pressão na CPU ou na memória, são necessárias métricas de sistema adequadas. Se o estabelecimento repetido de ligações ao backend estiver a afetar a análise, o artigo sobre Keepalive do Upstream do NGINX a configuração de ligações upstream reutilizáveis.

Do estado à monitorização

Para um diagnóstico pontual, pode ser suficiente uma consulta de estado local protegida. Esta consulta indica quais os valores de base que a instância consultada está a reportar nesse momento, mas não guarda ela própria qualquer histórico. Se pretender comparar evoluções ou ser notificado em caso de anomalias persistentes, necessita de um registo regular e de um sistema para séries temporais e alertas.

O oficial Exportador do NGINX para o Prometheus Existe um componente separado para isso: ele recupera o estado do stub e disponibiliza os dados como métricas do Prometheus. O Prometheus acede, em seguida, ao ponto final do exportador. Planeia a acessibilidade e as restrições de acesso para ambos os caminhos, ou seja, tanto para o ponto final de estado como para a saída de métricas do exportador.

Durante a configuração, registe qual o exportador que acede a cada instância do NGINX e a partir de onde o Prometheus acede ao exportador. Especialmente no caso de contentores separados, trata-se de dois percursos de rede diferentes. Por isso, o facto de um ponto final do exportador estar acessível não substitui, por si só, a verificação de se o exportador consegue, por sua vez, aceder com sucesso à página de estado correta.

A recolha adicional não transforma os valores de base em métricas detalhadas sobre tempos de resposta ou classes de estado HTTP. Para análises relativas a URLs lentas, respostas de erro ou ligações a montante específicas, são necessários registos de acesso adequados e outros dados de telemetria. Também a análise mais abrangente API do NGINX Plus É necessário distinguir o «Stub Status» do NGINX Open Source; a sua disponibilidade e configuração não são intercambiáveis.

Seleciona dados adicionais de acordo com a questão específica: para uma taxa de pedidos crescente, basta, numa primeira fase, a comparação temporal do contador. Se, por outro lado, se tratar de respostas lentas ou de um determinado serviço de backend, precisas de dados de latência e de upstream correspondentes ao período em questão. A página de estado pode servir de ponto de partida para uma investigação, mas não é, por si só, suficiente para identificar a causa.

Os limiares de alarme devem basear-se no comportamento normal da respetiva instância e nos objetivos do serviço, e não num valor geral para «Waiting» ou «Writing». Compare as anomalias com as latências, os erros e os recursos disponíveis e verifique se um alarme é, de facto, motivo para agir. Desta forma, um único valor de contador torna-se um motivo para uma investigação específica, em vez de um diagnóstico precipitado.

Ao planear os alarmes, tem também em conta a falha na via de recolha de dados: a falta de dados não é o mesmo que zero pedidos ou zero ligações. Uma verificação separada da acessibilidade ajuda a distinguir uma consulta falhada de uma situação de atividade efetivamente baixa. Defina também quem deve tratar de um alarme e quais os dados adicionais que devem estar disponíveis para o diagnóstico.