Logging: Por que e o quê? [fechadas]

35

Eu nunca escrevi programas que fazem uso significativo de log. O máximo que fiz foi capturar os rastreamentos de pilha quando as exceções acontecem.

Eu queria saber, o quanto as outras pessoas registram? Depende do tipo de aplicativo que você está escrevendo? Você acha os logs realmente úteis?

    
por Winston Ewert 16.01.2011 / 22:43
fonte

11 respostas

22

Para o trabalho que fiz em grande parte aplicativos incorporados, registrando uma ferramenta inestimável. No mínimo, os erros precisam ser registrados com informações suficientes para apontar para a linha de código. Em seguida, seriam os principais pontos de função em todo o aplicativo. Coisas como o administrador acessaram a máquina. Usamos um sistema que nos permite ativar o registro mais detalhado. Isso geralmente é específico do desenvolvedor. Ele pode ser usado para auxiliar o desenvolvedor durante o teste do recurso ou pode ajudar a diagnosticar um problema do cliente.

Eu pessoalmente usei o registro em todos os aplicativos que desenvolvi. Isso sempre levou a um melhor entendimento do fluxo de um aplicativo. Especialmente quando nas mãos de um cliente. Eles nunca (raramente) limitam seus casos de uso àqueles com os quais você testa.

    
por 16.01.2011 / 22:52
fonte
18

Eu não acho que isso depende do tipo de aplicativo: o registro é útil em todos os aplicativos (não-triviais). Certamente, eu acho, pode ser mais útil em algumas aplicações do que outras, mas eu não acho que seja inútil .

Em particular, no caso de um erro, um rastreamento de pilha informará o estado do programa no ponto de falha exato , mas você terá muito pouca pista sobre o estado < em> apenas para o erro. Essa informação pode ser muito útil para rastrear o problema, e o registro pode fornecer uma visão útil sobre isso. Eu acho que é algo que todos, exceto o mais trivial dos programas, podem se beneficiar.

Outro uso de registro, que pode não ser útil para todos os programas, está na análise estatística. Por exemplo, seu servidor da web normalmente registra todas as solicitações que chegam e, em seguida, há muitas ferramentas que podem analisar esses registros e produzir gráficos dos seus horários de maior movimento, das páginas mais populares e assim por diante. Você pode usar esses dados para planejar a capacidade ("preciso de um servidor maior?") E assim por diante.

    
por 16.01.2011 / 22:52
fonte
9

Existem dois motivos para a criação de log:

  1. Diagnóstico
  2. Auditoria

O log de diagnóstico já foi discutido por outras pessoas e não vou insistir muito mais nesse ponto. Eu vou apenas dizer que você deve pensar strongmente sobre o que acontece se houver uma falha no log? Você se importa o suficiente para lançar uma exceção através do aplicativo ou gerenciá-lo de outra maneira? Isso é um "depende", mas mensagens de nível de informações de log provavelmente devem ser ignoradas.

O log de auditoria é um requisito comercial. O log de auditoria captura eventos significativos no sistema e é o que o gerenciamento e as águias jurídicas estão interessadas. Isso é coisas como quem assinou algo, quem fez o que foi editado etc. Como administrador de sistemas ou solucionador de problemas do sistema, você provavelmente apenas ligeiramente interessado nestes. No entanto, em muitos casos, esse tipo de log é absolutamente parte da transação e deve falhar toda a transação, se não puder ser concluída.

Pensar sobre os dois separadamente é útil para mim não apenas porque um é "opcional" e o outro é obrigatório, mas porque, dependendo dos requisitos, posso realmente precisar implementá-los separadamente. Pode ser um caso (às vezes) que ambos sejam frutos, mas um é maçãs e as outras laranjas. Normalmente, uma única estrutura de registro pode manipular ambos.

    
por 17.01.2011 / 06:16
fonte
8

Na maioria das tarefas do servidor, o registro é crucial, já que o administrador geralmente não está lá quando as coisas acontecem, então ele precisa checar o fato.

Mas, um cara do Google me disse uma vez que seus processos de servidor não fazem logging; em vez disso, eles são "instrumentados"; Isso significa que todo processo tem ganchos ou portas (ele não especificou a mecânica) onde outros processos podem travar para solicitar parâmetros e estatísticas. São esses processos de monitoramento que armazenam muitas coisas nos logs, a vantagem é que as informações obtidas não são "abrir um arquivo", "escrever isto", "buscar isso"; eles obtêm coisas como "45.453 arquivos abertos", "653 clientes do serviço X", "344ms de resposta média para a consulta Y"

Certamente é uma abordagem diferente, e uma que eu tenho em mente quando cuido de meus sistemas, mesmo que sejam de alguma magnitude menor.

    
por 17.01.2011 / 04:19
fonte
4

Eu vim de um aplicativo N-camadas do WinForms que registrava tudo.

Não foi muito útil.

Claro, as exceções de registro são ótimas; mas por que registrá-los na máquina do cliente quando você pode simplesmente enviar a exceção para a equipe de desenvolvimento?

As informações de registro se transformam facilmente em um vício cujo valor raramente é justificado. Para cada situação em que você pode registrar-se gratuitamente, é melhor coletar informações direcionadas e enviá-las para onde você precisar.

    
por 16.01.2011 / 23:58
fonte
4

Capturar informações de exceção é uma necessidade, pois pode ser muito útil até certo ponto. Mas, às vezes, informações de exceção não são suficientes, especialmente se o usuário / cliente do aplicativo não puder relatar um erro com informações adequadas.

O registro está limitado apenas à captura de informações de erro?

No meu caso (aplicação web), eu sempre registro qual página é visitada, quando, o que eles clicam, onde o ip & Eu registro o tempo total de carregamento para cada visita à página, para que eu possa saber quais páginas são lentas e precisam de otimização. então eu posso dizer que eu registro o máximo possível.

no começo, eu não fazia ideia de quão significativo seria. mas aparentemente é muito útil em muitas coisas (além da depuração):

  • compreendendo o comportamento do usuário
  • avaliando a aceitação de novos recursos
  • distinguir entre adotantes iniciais, golpistas ou clientes em potencial

Eu acho que o registro pode se tornar mais significativo se nós gostamos de extrair informações estatísticas nele.

    
por 17.01.2011 / 01:08
fonte
2

Sou desenvolvedor em uma empresa cujos produtos são implantados no exterior. Quando uma equipe de suporte pergunta sobre uma definição de problema, minhas únicas ferramentas para diagnóstico são meus arquivos de log e uma cópia do banco de dados do cliente. Usando o banco de dados e meu ambiente de desenvolvimento, tenho a oportunidade de reproduzir o caso incorreto, porque eu registro os dados recebidos no meu módulo e as ações relacionadas. Se eu conseguir reproduzir o erro com a ajuda dos dados que reunir, posso corrigi-lo com a depuração. Se eu não tivesse nenhum arquivo de log, eu teria que depender da descrição do cliente ou da equipe de suporte sobre o que acontece em cada caso (que tem uma grande chance de enganar).

Em segundo lugar, o registro em log me dá a chance de detectar os gargalos do meu módulo no site implantado, pois registro a data e o horário de determinadas ações e depois posso ver qual ação consome quanto tempo.

Além disso, suponha que nossa solução consiste em 6 módulos e estou vendo logs de erros em meus arquivos de log sobre tempos limite do banco de dados. Se esses erros forem registrados em 5 dos outros módulos também, a probabilidade de que isso seja um problema relacionado ao servidor SQL será maior. Se isso for registrado apenas no meu módulo, a probabilidade de que minhas consultas fiquem com erros fique maior. Eu acho que esses tipos de coisas são indicadores úteis.

Sobre que tipo de dados eu vejo nos meus arquivos de log depende da configuração do nível de log. Se este for um produto novo, definimos o nível de log como "Todos" para reunir o máximo de dados possível. Mas quando melhoramos o produto, podemos preferir manter o nível de log em "Erro" para registrar apenas o erro, mas não os logs de nível de informação, etc ...

    
por 16.01.2011 / 23:57
fonte
2

O registro em log é útil para as informações que você não pode obter por outros programas:

  • Capturar rastreamentos de pilha (você conseguiu esse)
  • Capture quais dados estavam sendo processados quando seu aplicativo falhou. Lembre-se de que os depuradores só ajudam se estiverem presentes quando o acidente acontecer.
  • Criação de perfil de informações. Se você não puder executar um gerenciador de perfis no ambiente de produção, o log extenso incluindo registros de data e hora pode ajudá-lo a descobrir onde o tempo foi gasto. Mesmo não sendo capaz de identificar, pode ajudá-lo a identificar que está fora do programa (por exemplo, coleta de lixo funcionando).
  • As estatísticas não são esperadas ao escrever o programa. Fui solicitado a fornecer gráficos de comportamento ao longo do tempo para intervalos interessantes por outros motivos. Os dados necessários podem ser extraídos dos arquivos de log com um pouco de truques grep + awk + perl ninja.

Nota: você deseja pelo menos DOIS arquivos de log.

  • Um no nível DEBUG - fornecendo todas as informações que você pode imaginar que precisará (incluindo INFO e acima). Se isso for demais, considere ter um nível de TRACE adicional.
  • Um no nível INFO - fornecendo a visão geral de 10000 metros do sistema. Marcos importantes estão aqui.

O INFO está sempre ligado. A DEPURAÇÃO está ligada quando necessário.

Grave o código de criação de log antecipando que você possa um dia depurar uma situação em que TODOS você tenha o arquivo de log, e fazer isso corretamente pode ser a diferença entre ser demitido e ser promovido.

Por uma milha extra, todas as chamadas de função adicionam seus parâmetros a qualquer rastreamento de pilha, em Java com

public void sendEmail(String sender, String recipient) {
try { 
...
} catch (Exception e) {
  throw new RuntimeException("sendEmail(sender="+sender+", recipient="+recipient+")");
}

Essa abordagem essencialmente aprimora sua pilha de chamadas com valores de parâmetro e pode permitir que você analise a situação apenas com o rastreamento de pilha e sem precisar ver os arquivos de log.

    
por 17.01.2011 / 00:44
fonte
1

Também recomendo que todos os aplicativos não triviais utilizem o registro em vários níveis.

Pelas razões pelas quais os outros afirmaram, é uma ferramenta inestimável para resolver problemas com o aplicativo.

Em alguns casos, o registro em log é essencial, por exemplo, em aplicativos financeiros e outros domínios que exigem registros de atividades, segurança, métricas de uso e auditoria.

    
por 16.01.2011 / 23:47
fonte
1

Certamente depende do tipo de sistema que você está construindo.

Se você estiver escrevendo um aplicativo de área de trabalho autônomo, como um processador de texto, provavelmente não precisará de registro em log.

Se você estiver escrevendo um sistema embarcado, não poderá viver sem registro. Caso contrário, quando o dispositivo incorporado congela, você não tem ideia do motivo. Você também precisa de registro sempre que seu sistema envolver vários processos ou várias máquinas físicas se comunicando umas com as outras. Novamente, quando o sistema trava, você precisa saber qual parte dele morreu quando e por quê. Você precisa poder comparar os registros para determinar se os dados foram ou não processados de um processo para o outro. Da mesma forma, você precisa de registro sempre que seu sistema for executado por longos períodos de tempo sem muita interação direta do usuário.

    
por 17.01.2011 / 05:23
fonte
1

O registro é sempre útil. Mas ao implementar, esteja ciente de que não é necessariamente você quem vai ler os logs. Talvez seja algum tipo de administrador, usuário final, cliente, equipe de suporte ...

Portanto, não registre apenas os stacktraces, mas também algumas informações adicionais que podem ser interpretadas por não desenvolvedores. Quando seu aplicativo é mantido por outros grupos, também é útil escrever alguns códigos de erro exclusivos em seus registros. Isso pode facilitar o suporte, a automação ...

Outro ponto de uma perspectiva administrativa: pense na rotação de log.

    
por 18.01.2011 / 08:49
fonte