login com NGINX-como configurá-lo e o que observar para

NGINX é um servidor web de alto desempenho e confiável, capaz de lidar com enormes quantidades de tráfego para os sites mais movimentados da internet. Ao resolver problemas, você precisa de uma maneira de fazer sentido do tráfego e NGINX fornece recursos de registro flexíveis para capturar detalhes valiosos e ajudá-lo a entender o comportamento do seu servidor web.

NGINX oferece dois arquivos diferentes para registrar dados valiosos do servidor web., Esses dois arquivos são error_log e access_log. access_log é usado para armazenar informações sobre os pedidos dos clientes web e o error_log armazena outras mensagens inesperadas ou informativas.

configurar o access_log

o ficheiro access_log recolhe todos os pedidos dos clientes imediatamente após o processamento do pedido, proporcionando uma óptima forma de registar as páginas que os utilizadores estão a pedir ao seu servidor web., Você pode escolher onde o acess_log de dados é escrito usando o arquivo de configuração seguinte sintaxe:

access_log path ] ];access_log off;

Specifyingformat permite que você usar um formato personalizado em seus logs usando variáveis como o número de bytessent para o cliente ($bytes_sent) orthe pedido de comprimento ($request_length).

Normalmente, a NGINX irá registar cada processo de transacção no access_ log. O parâmetro if=condição fornece uma powerfulway para realizar o logg condicional para que ele apenas logar as mensagens de log de acesso se alguma condição for verdadeira., Por exemplo, se youonly quer para os pedidos de registro de retornar um código de status HTTP 404 você pode usar thefollowing trecho:

map $status $should_log {404 1;default 0;}access_log logs/access.log combined if=$should_log;

Com esta alteração quaisquer pedidos completedsuccessfully (2xx), redirecionado para outra página (3xx) ou encontrou um servererror (5xx) não serão registradas em logs de acesso.log-only404 erros serão registrados.

Se tiver mais do que uma máquina virtual ou multi-exemplo http, servidor ou directivasde localização, por vezes é útil desactivar o registo no nível actual da directiva, e o valor desligado especial foi criado para este fim.,A seguinte linha de configuração mostra como você pode impedir que o NGINX de writingaccess informações para qualquer access_log targetat o nível atual:

access_log off;

Para uma explicação mais completa do configurationoptions, confira o NGINX access_log documentação.

NGINX Log Severity Levels

NGINX supports a wide range of severity level to make it easy to log the information you care about. Cada um destes níveis pode ser usado com o error_log directivopara definir o nível mínimo no qual as mensagens são registadas., Aqui estão os níveis supported na ordem mais baixa a mais alta, juntamente com um guia sobre como eles são usados:

  • mensagens de depuração que não são úteis na maioria das vezes.
  • Info – mensagens informacionais que podem ser boas de saber.nota: algo normal, mas significativo aconteceu e deve ser notado.Aviso-algo inesperado aconteceu, mas não é motivo de preocupação.
  • erro – algo falhou.
  • Crit-uma condição crítica ocorreu.alerta-é necessária acção imediata.
  • Emerg – o sistema é inutilizável.,

configurando error_log

por omissão, o ficheiro error_log captura todas as mensagens de Registo ao nível de gravidade do erro, o que significa que é usado principalmente para compreender as mensagens fatais ou críticas para ajudar na resolução do problema. A localização por omissão dos registos/erros do error_ Logis.log. A forma como a NGINXstores mensagens de erro é flexível e—juntamente com permitir—lhe escrever mensagens para um ficheiro-também suporta o envio de mensagens de erro para o stderr ou para o servidor do syslog. Se estiver a correr NGINXopen Fonte 1.5.,2 ou mais recente, você também pode enviar mensagens error_log para mais de um lugar de cada vez, especificando muitas diretivas error_log no mesmo nível de configuração.

Se você deseja fazer todas as mensagens ou abovethe avisar gravidade de registo de fazer thefollowing alteração de configuração:

error_log logs/error.log warn;

o Log do Syslog Com NGINX

Tanto o access_log e error_log diretivas de suporte de envio de mensagens para um syslog daemon usando o syslog: string na sua configuração., O trecho a seguir mostra a sintaxe para utilizar qualquer uma das diretivas com um syslog daemon:

http {error_log syslog:server;…}

Por exemplo, se você deseja direcionar todo o error_log mensagens com advertir ou maior gravidade para o syslogdaemon usar esta directiva linha:

error_log syslog:server=192.168.1.1 severity=warn;

Você pode personalizar ainda mais o syslogconfiguration para se adequar ao seu ambiente utilizando o syslog parâmetro describedin o NGINXsyslog documentação.

Gestão de registos sem frustração. É uma coisa.,)

agregar, organizar e gerir os seus registos com o Papertrail

coisas a ter em atenção para

a flexibilidade do registo NGINX oferece comesat a um custo, e existem algumas coisas a ter em atenção ao escrever o seu ficheiro de configuração. Já cobrimos a capacidade da NGINX de anular as configurações de logging ao nível da diretiva, e Esta característica é extremamente útil para logging extra Informação sempre que os usuários acessam caminhos específicos, por exemplo, loggingextra informações de tráfego para qualquer usuário que acesse o URI /privado., No entanto, o uso de logs de acesso aninhados pode rapidamente tornar-se complexo e você deve ter cuidado para não usar este recurso muito.

escrevendo access_ logentries para um arquivo no disco pode degradar o desempenho do servidor e aumentar a latência de resposta para pedidos do Usuário. Para servidores web que precisam manter alto desempenho, NGINX fornece uma maneira de escrever mensagens de log para um buffer Cíclico, contornando completamente o disco. Extrair esses logs é mais envolvido do que ler um arquivo, então você só deve usar isso se o desempenho é fundamental para a sua carga de trabalho.,

para usar esta funcionalidade, a sua versão do NGINX precisa de ser configurada com a opção—com-depuração. Você pode verificar se este é o caso, por fazer isso:

$ nginx -V 2>&1 | grep—‘—with-debug’configure arguments: --with-debug

Dentro do arquivo de configuração você poderá habilitar a escrever as entradas de log de memória com o trecho a seguir:

error_log memory:32m debug;...http {...}

Isso irá gravar todas as mensagens de log do nível de depuração. Extrair as mensagens de registo da memória envolve usar o gdb para se ligar ao processo NGINX e copiar e colar o seguinte programa na linha de comandos:

set $log = ngx_cycle->logwhile $log->writer != ngx_log_memory_writerset $log = $log->nextendset $buf = (ngx_log_memory_buf_t *) $log->wdatadump binary memory debug_log.txt $buf->start $buf->end

depois sair do GDB usando o Ctrl-D., O script acima irá escrever o conteúdo da memória para o debug_ log.txtfile onde você pode lê-lo como normal.

conclusão

NGINX permite-lhe recolher registos de acessos e erros inesperados em ficheiros separados para análise posterior e resolução de problemas. O formato do access_logfile pode ser extensivamente personalizado para incluir informações detalhadas sobre os pedidos,tais como o número de bytes enviados para o cliente ou o comprimento do pedido, e a diretiva error_log permite que você controle o nível mínimo de gravidade exigido para as mensagens serem registradas.,Ambas as diretivas access_log e error_log podem transmitir logentries para um servidor syslog, o que pode ser extremamente útil para desenvolvedores que trabalham com vários servidores web.

E se todas essas funcionalidades não forem suficientes para você, você pode até mesmo escrever error_ logentries para um buffer de memória para evitar escrever no disco e reduzir o impacto de performance para servidores ocupados.

Leave a Comment