Rastreamento de aplicativos com NGINX e NGINX Plus

Usando variáveis para gerenciamento de desempenho de aplicativos

Variáveis são um aspecto importante e às vezes esquecido da configuração do NGINX. Com aproximadamente 150 variáveis disponíveis, há variáveis para aprimorar cada parte da sua configuração. Nesta postagem do blog, discutimos como usar variáveis NGINX para rastreamento de aplicativos e gerenciamento de desempenho de aplicativos (APM), com foco na descoberta de gargalos de desempenho em seu aplicativo. Esta postagem se aplica tanto ao NGINX Open Source quanto ao NGINX Plus. Para resumir, nos referiremos ao NGINX Plus neste documento, exceto quando houver diferença entre as duas versões.

O ambiente de entrega do aplicativo

Em nosso ambiente de entrega de aplicativo de exemplo, o NGINX Plus está funcionando como um proxy reverso para nosso aplicativo. O aplicativo em si é composto por um frontend web por trás do qual ficam vários microsserviços.

Rastreamento de solicitações de ponta a ponta

O NGINX Plus R10 (e o NGINX 1.11.0) introduz a variável $request_id , que é uma sequência gerada aleatoriamente de 32 caracteres hexadecimais atribuídos automaticamente a cada solicitação HTTP conforme ela chega (por exemplo, 444535f9378a3dfa1b8604bc9e05a303 ). Esse mecanismo aparentemente simples desbloqueia uma ferramenta poderosa para rastreamento e solução de problemas. Ao configurar o NGINX Plus e todos os serviços de backend para passar o valor $request_id , você pode rastrear cada solicitação de ponta a ponta. Esta configuração de exemplo é para nosso servidor frontend NGINX Plus.

upstream app_server { server 10.0.0.1:80;
}

server {
listen 80;
add_header X-Request-ID $request_id; # Retornar ao cliente
location / {
proxy_pass http://app_server;
proxy_set_header X-Request-ID $request_id; # Passar para o servidor de aplicativo
}
}

Para configurar o NGINX Plus para rastreamento de solicitações, primeiro definimos o local de rede do servidor de aplicativos no bloco upstream . Para simplificar, mostramos apenas um único servidor de aplicativos aqui, mas normalmente usaríamos vários para fins de alta disponibilidade e balanceamento de carga.

O bloco do servidor de aplicativos define como o NGINX Plus lida com solicitações HTTP de entrada. A diretiva listen informa ao NGINX Plus para escutar na porta 80 – o padrão para tráfego HTTP, mas uma configuração de produção normalmente usa SSL/TLS para proteger dados em trânsito .

A diretiva add_header envia o valor $request_id de volta ao cliente como um cabeçalho personalizado na resposta. Isso é útil para testes e também para aplicativos clientes que geram seus próprios logs, como aplicativos móveis, para que um erro do lado do cliente possa ser correspondido precisamente aos logs do servidor.

Por fim, o bloco de localização se aplica a todo o espaço do aplicativo ( / ) e a diretiva proxy_pass simplesmente envia todas as solicitações para o servidor do aplicativo. A diretiva proxy_set_header modifica a solicitação com proxy adicionando um cabeçalho HTTP que é passado ao aplicativo. Neste caso, criamos um novo cabeçalho chamado X-Request-ID e atribuímos a ele o valor da variável $request_id . Então nosso aplicativo recebe o ID de solicitação que foi gerado pelo NGINX Plus.

Registrando $request_id de ponta a ponta

Nosso objetivo com o rastreamento de aplicativos é identificar gargalos de desempenho no ciclo de vida do processamento de solicitações como parte do gerenciamento de desempenho do aplicativo. Fazemos isso registrando eventos significativos durante o processamento para que possamos analisá-los posteriormente em busca de atrasos inesperados ou injustificados.

Configurando o NGINX Plus

Começamos configurando o servidor frontend NGINX Plus para incluir $request_id em um formato de registro personalizado, trace , que é usado para o arquivo access_trace.log .

log_format trace '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" "$http_user_agent" ' '"$http_x_forwarded_for" $request_id '; upstream app_server { server 10.0.0.1; } server { listen 80; add_header X-Request-ID $request_id; # Retorna ao local do cliente / { proxy_pass http://app_server; proxy_set_header X-Request-ID $request_id; # Passa para o servidor de aplicativos access_log /var/log/nginx/access_trace.log trace ; # Registrar $request_id } }

Configurando o aplicativo de backend

Passar o ID da solicitação para seu aplicativo é muito bom, mas não ajuda no rastreamento do aplicativo, a menos que o aplicativo faça algo com ele. Neste exemplo, temos um aplicativo Python gerenciado pelo uWSGI . Vamos modificar o ponto de entrada do aplicativo para capturar o Request ID como uma variável de log.

de uwsgi importar set_logvar def main (environ, start_response): set_logvar ( 'requestid' , environ[ 'X_REQUEST_ID' ])

Então podemos modificar a configuração do uWSGI para incluir o ID da solicitação no arquivo de log padrão.

log-format = %(addr) - %(user) [%(ltime)] "%(method) %(uri) %(proto)" %(status) %(size) "%(referer)" "%(uagent)" %(requestid)

Com essa configuração em vigor, agora estamos produzindo arquivos de log que podem ser vinculados a uma única solicitação em vários sistemas.

Entrada de log do NGINX:

172.17.0.1 - - [02/ago/2016:14:26:50 +0000] "OBTER / HTTP/1.1" 200 90 "-" "-" "-" 5f222ae5938482c32a822dbf15e19f0f

Entrada de log do aplicativo:

192.168.91.1 - - [02/ago/2016:14:26:50 +0000] "GET / HTTP/1.0" 200 123 "-" "-" 5f222ae5938482c32a822dbf15e19f0f

Ao comparar transações com os campos de ID da solicitação, ferramentas como Splunk e Kibana nos permitem identificar gargalos de desempenho no seu servidor de aplicativos. Por exemplo, podemos pesquisar solicitações que levaram mais de dois segundos para serem concluídas. Entretanto, a resolução de tempo padrão de um segundo em registros de data e hora regulares é insuficiente para a maioria das análises do mundo real.

Temporização de alta precisão

Para medir com precisão as solicitações de ponta a ponta, precisamos de registros de data e hora com precisão de milissegundos. Ao incluir a variável $msec nas entradas de log, obtemos uma resolução de milissegundos no registro de data e hora de cada entrada. Adicionar registros de data e hora em milissegundos ao log do nosso aplicativo nos permite procurar solicitações que levaram mais de 200 milissegundos para serem concluídas, em vez de 2 segundos.

Mas mesmo assim não estamos obtendo uma visão completa, porque o NGINX Plus grava o registro de data e hora $msec somente no final do processamento de cada solicitação. Felizmente, existem várias outras variáveis de tempo do NGINX Plus com precisão de milissegundos que nos dão mais informações sobre o processamento em si:

• $request_time – Tempo total da solicitação, começando quando o NGINX Plus lê o primeiro byte do cliente e terminando quando o NGINX Plus envia o último byte do corpo da resposta
• $upstream_connect_time – Tempo gasto estabelecendo uma conexão com o servidor upstream
• $upstream_header_time – Tempo entre o estabelecimento de uma conexão com o servidor upstream e o recebimento do primeiro byte do cabeçalho de resposta
• $upstream_response_time – Tempo entre o estabelecimento de uma conexão com o servidor upstream e o recebimento do último byte do corpo da resposta

Para obter informações detalhadas sobre essas variáveis de tempo, consulte Usando o registro do NGINX para monitoramento de desempenho de aplicativos .

Vamos estender nossa diretiva log_format para incluir todas essas variáveis de tempo de alta precisão em nosso formato de log de rastreamento .

log_format trace '$remote_addr - $remote_user [$time_local] "$request" $status ' '$body_bytes_sent "$http_referer" "$http_user_agent" ' '"$http_x_forwarded_for" $request_id $msec $request_time ' '$upstream_connect_time $upstream_header_time $upstream_response_time' ;

Usando nossa ferramenta de análise de log preferida, podemos extrair valores de variáveis e executar o seguinte cálculo para ver quanto tempo o NGINX Plus levou para processar a solicitação antes de se conectar ao servidor de aplicativos:

Tempo de processamento do NGINX Plus = $request_time - $upstream_connect_time - $upstream_response_time

Também podemos procurar os valores mais altos de $upstream_response_time para ver se eles estão associados a URIs ou servidores upstream específicos. E estes podem ser verificados posteriormente em relação às entradas de log do aplicativo que têm o mesmo ID de solicitação.

Conclusão

Utilizar a nova variável $request_id e algumas ou todas as variáveis de precisão de milissegundos pode fornecer uma ótima visão sobre os gargalos de desempenho do seu aplicativo, melhorando o gerenciamento de desempenho do aplicativo sem precisar recorrer a agentes e plug-ins pesados.

Experimente você mesmo o rastreamento de aplicativos com o NGINX Plus: comece seu teste gratuito de 30 dias hoje mesmo ou entre em contato conosco para discutir seus casos de uso .