leandroico

Eu amo o Nginx, sério, amo! Mas tenho que admitir que o log_format padrão (combined) do Nginx é meio deficitário de algumas informações que julgo importantes. E elas são o tempo de duração do request e o domínio do request.

O domínio do request é bastante útil para aqueles casos onde você hospeda um serviço que opera através de vários domínios e/ou subdomínios. E ter essa informação em cada request no log pode ajudar bastante a identificar ataques e gargalos, além de te amparar quando for instalar ferramentas de monitoramento de sistema (como o Munin, Graphite ou Ganglia) para montar gráficos baseados por domínio.

O tempo de duração do request é importante para identificar quais são as páginas mais lentas e assim poder revelar os verdadeiros gargalos dentro dessas páginas, além de te dar uma noção de quantos Nginx workers e máquinas será necessário para que o serviço escale de forma a atender sua base de usuários sem incomodá-los. Bom, acho que estou falando o óbvio.

O log_format padrão no nginx quando você usa o access_log é o combined e a sua composição é a seguinte:

log_format combined '$remote_addr - $remote_user [$time_local]  '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';

Através do comando log_format no Nginx você pode definir seu próprio format de log. O que eu normalmente uso nos meus servidores é o seguinte formato:

log_format complete '[$time_local] [$request_time] {$remote_addr} ($host) '
                    '"$request_uri" st:$status sz:$bytes_sent '
                    '"$http_referer" "$http_user_agent"';

Repare que essas variáveis (termos começados com o ‘$’) são variáveis nativas que o Nginx fornece para você dentro do contexto de geração de logs. E nesse segundo formato eu adicionei duas variáveis que o Nginx provê: $host e $request_time, que são respectivamente o domínio do request (domínio para o qual o request foi feito) e o tempo de duração do request (tempo que o Nginx levou para devolver o request ao client).

Para maiores informações sobre o log_format e suas variáveis acesse o HttpLogModule do Nginx.

Digamos que você queira visualizar uma versão antiga de um arquivo usando o git. Você há de concordar comigo que deveria ser um comando de uma linha, não deveria?

Pois então, e é! Bom, é e não é. Depende de quão hacker você esteja se sentindo hoje. Caso esteja, resumo o seu desejo com a seguinte linha:

$ git cat-file -p $(git ls-tree $REV $file | cut -d " " -f 3 | cut -f 1)

Se você já entendeu tudo só de olhar para a linha de comando acima, você já está dispensado desta postagem. Para os demais, entendamos antes como funciona cada comando.

O git ls-tree precisa, nesse caso, de 2 parâmetros básicos: #1, o hash do commit em questão ($REV) e #2, o nome do arquivo desejado ($file).

O git ls-tree, exibe 4 colunas. Exemplo:

100644 blob 1b2f50c48e19d25b8e4600aa9b3f1341c32d17dc app/views/yada-yada.erb.html

Coluna 1: as permissões do arquivo
Coluna 2:  o tipo de arquivo, que no caso é um 'blob' (um pacote binário de dados ou vulgo 'arquivo')
Coluna 3: o mais importante, o identificador/referência do objeto/arquivo (arquivo na versão em questão) dentro do git
Coluna 4:  o nome do arquivo

Tudo o que você precisa é da terceira coluna para passar como argumento para o comando git cat-file. Recomendo FORTEMENTE que você sempre recorra às man pages nesse caso (git help cat-file) para ficar por dentro do que significa o -p e etc.

O -p faz um "pretty print" baseado no formato do arquivo. Se você não colocar o -p você é obrigado a preceder o paramêtro de hash (identificador) com o valor "blob", compondo um comando assim:

$ git cat-file blob 1b2f50c48e19d25b8e4600aa9b3f1341c32d17dc

Dito tudo isso, você está pronto para visualizar o conteúdo de versões anteriores de um dado arquivo dentro do seu repositório git.

Referência: Stack Overflow