|
O registro de acesso à web (access_log) registra o comportamento de acesso de todos os clientes externos ao servidor web, incluindo informações importantes como IP do cliente, data de acesso, recurso URL acessado, código de status HTTP retornado pelo servidor, entre outros. Um registro típico de acesso à web é o seguinte: 112.97.37.90 - - [14/Set 2013:14:37:39 +0800] "GET / HTTP/1.1" 301 5 "-" "Mozilla/5.0 (Linux; U; Android 2.3.6; zh-cn; Lenovo A326 Build/GRK39F) AppleWebKit/533.1 (KHTML, como Gecko) Versão/4.0 Mobile Safari/533.1 MicroMessenger/4.5.1.259" -
Planejamento: 1. Para resolver o problema: Quando o site tem um grande número de visitas, haverá muitos dados de log, e se tudo for escrito em um arquivo de log, o arquivo ficará cada vez maior. A velocidade de arquivos grandes diminui, como centenas de megabytes de um arquivo. Ao escrever logs, isso afeta a velocidade de operação. Além disso, se eu quiser olhar os logs de acesso, um arquivo com várias centenas de megabits demora para baixar e abrir. Usando uma ferramenta gratuita de análise de logs de terceiros - Log Treasure, você pode enviar arquivos de log do nginx, apache e iis, que ajudam a analisar aspectos de segurança do site. Afinal, especializar-se é mais profissional. O Log Bao também possui um limite de tamanho para arquivos enviados, no máximo 50 milhões.
2. O Nignx não possui um mecanismo para separar automaticamente arquivos e armazenar logs. Já que o nginx não salva automaticamente os arquivos para você. Portanto, você precisa escrever seu próprio script para implementá-lo.
O arquivo de script shell nginx_log_division.sh o seguinte conteúdo:
# /lixo/batida logs_path="/data/wwwlogs/" #以前的日志文件. log_name="xxx.log" pid_path="/usr/local/nginx/logs/nginx.pid"
mv ${logs_path}${log_name} ${logs_path}${log_name}_$(data --data="SEMANA PASSADA" +"%Y-%m-d").log
matar -USR1 'gato ${pid_path}'
O princípio do script shell acima é primeiro mover e renomear o arquivo de log anterior para um, o objetivo é fazer backup. De acordo com o nome da última segunda-feira, quando o script é executado no horário "2013-09-16", o nome do arquivo gerado é "xxx.log_ 20130909.log". Mesmo que o comando mv tenha sido executado no arquivo antes de kill -USR1 'cat ${{pid_path}' ser executadoNome do arquivo alterado, o nginx ainda gravará os dados de log no arquivo recém-nomeado "xxx.log_20130909" como de costume. O motivo é que, em sistemas Linux, o kernel busca arquivos com base em descritores de arquivo.
---------------- compreensão dos descritores de arquivos do Linux
Um descritor de arquivo é um identificador inteiro que o kernel Linux nomeia para cada arquivo aberto. O kernel Linux gera (ou mantém) um "Tabela de Descritores de ArquivoEsta tabela de descritores de arquivos registra "o arquivo aberto por este processo (identificado)". Nesse ambiente, nginx é um processo em execução que já abriu um arquivo de log e registra o arquivo na tabela de descritores do arquivo. Mesmo que o caminho do arquivo de log tenha mudado, ele ainda pode ser encontrado (pode ser localizado de acordo com a tabela de descritores do arquivo). ---------------------------------------------- Ao executar o comando "kill -USR1 'cat ${pid_path}'", o salvo no arquivo nginx.pid é na verdade um número (você pode abri-lo e dar uma olhada, estou no 894 aqui), e nginx escreve o pid (número do processo) do processo principal no arquivo nginx.pid, então você pode obter diretamente o número do processo principal pelo comando cat e operar diretamente o número de processo especificado.
kill -USR1 'gato ${pid_path}' é equivalente a kill –USR1 894 #指定发信号 (USR1) para numerar esse processo.
Em sistemas Linux, o Linux se comunica com "processos em execução" por meio de sinais. Em sistemas Linux, também existem muitos sinais pré-definidos, como o SIGHUP. USR1 é um sinal definido pelo usuário. Pode ser entendido como o próprio processo definindo o que fazer quando recebe esse sinal (ou seja, o próprio autor do processo decide se recebe esse sinal ou não faz nada, deixando totalmente para o desenvolvedor decidir). No nginx, ele escreve seu próprio código para lidar com o gerenciamento de fazer o nginx reabrir o arquivo de log quando recebo um sinal USR1. O princípio específico é o seguinte: 1. O processo principal do nginx recebe o sinal USR1 e reabre o arquivo de log (nomeado pelo nome do log no arquivo de configuração nginx, que é o valor definido pelo item access_log no arquivo de configuração, e se o arquivo não existir, um novo xxx.log de arquivo será criado automaticamente).
2. Depois, mudar o proprietário do arquivo de log para "processo trabalhador", para que o processo trabalhador tenha permissões de leitura e gravação no arquivo de log (mestre e trabalhador geralmente rodam como usuários diferentes, então o proprietário precisa ser alterado).
3. O processo principal nginx fechará o arquivo log duplicado (ou seja, o arquivo que foi renomeado para xxx.log_ 20130909.log usando o comando mv agora),e notifica o processo worker para usar o arquivo de log recém-aberto(xxx.log o arquivo aberto pelo processo principal agora há pouco). A implementação específica é mais detalhada, o processo principal envia o sinal USR1 para o trabalhador e, após receber esse sinal, o trabalhador reabre o arquivo de log (ou seja, o xxx.log acordado no arquivo de configuração)
=================================== Executar scripts em intervalos regulares
Defina o arquivo de script shell acima para ser adicionado à tarefa agendada. crontab é um processo de tarefa agendada no Linux. Esse processo começa quando você o ativa, e ele vai até a lista de vez em quando para ver se há alguma tarefa que precisa ser realizada.
crontab -e
* 04 * * 1 /data/wwwlogs/nginx_log_division.sh
Um arquivo será aberto com o código acima adicionado O formato é "Caminho do arquivo shell a ser executado". * pode ser entendido como "a todo", a cada minuto, a cada hora, a cada mês, etc. Configurei um script para rodar nginx_log_division.sh às 4h da manhã de segunda-feira, e o conteúdo do script é para regenerar um novo arquivo de log.
Anexado:PrepararnginxComo os registros são configurados
log_format site '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_enviados "$http_referente" ' '"$http_agente_usuário" $http_x_encaminhado_for';
access_log /data/wwwlogs/xxxx.com.log site #第二个参数表示使用那个日志格式, um nome é identificado para cada formato de log, e o site corresponde ao nome do log_format
O que foi dito acima envolve o uso do gerenciador de tarefas agendadas crontab.
Também há lugares onde não há uma compreensão completa e erros são errados. Espero atualizar no futuro.
|