Eu nunca escrevi programas que fazem uso significativo do log. O máximo que fiz foi capturar rastreamentos de pilha quando ocorrerem exceções.
Fiquei me perguntando, quanto as outras pessoas registram? Depende do tipo de aplicativo que você está escrevendo? Você acha os logs realmente úteis?
Respostas:
Pelo trabalho que fiz em grande parte dos aplicativos incorporados, registrei 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 no aplicativo. Coisas como o administrador acessaram a máquina. Usamos um sistema que nos permite ativar logs mais detalhados. Isso geralmente é específico do desenvolvedor. Pode ser usado para ajudar o desenvolvedor durante o teste do recurso ou para diagnosticar um problema do cliente.
Eu pessoalmente usei o logon em todos os aplicativos que desenvolvi. Sempre levou a uma melhor compreensão do fluxo de um aplicativo. Especialmente quando está nas mãos de um cliente. Eles nunca (raramente) limitam seus casos de uso àqueles contra os quais você testa.
Eu não acho que depende do tipo de aplicativo: o log é útil em todos os aplicativos (não triviais). Certamente, eu acho, pode ser mais útil em alguns aplicativos do que em outros, mas 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 exato da falha, mas você tem muito pouca pista sobre o estado imediatamente antes do erro. Essas informações podem ser muito úteis para rastrear o problema, e o log pode fornecer uma visão útil sobre isso. Eu acho que é algo que todos os programas, exceto o mais trivial, podem se beneficiar.
Outro uso do log, que pode não ser útil para todos os programas, está na análise estatística. Por exemplo, seu servidor da Web geralmente registra todas as solicitações recebidas e, em seguida, existem muitas ferramentas que podem analisar esses registros e produzir gráficos dos 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.
Há dois motivos pelos quais o log é realizado:
O log de diagnóstico já foi discutido por outras pessoas e não abordarei muito mais o assunto. Vou apenas dizer que você deve pensar fortemente 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á-la de outra maneira? Este é um "depende", mas as mensagens no nível das 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 interessa à gerência e às pessoas jurídicas. São coisas como quem assinou algo, quem fez o que edita etc. Como administrador de sistemas ou desenvolvedor que soluciona problemas no sistema, provavelmente apenas levemente interessado neles. No entanto, em muitos casos, esse tipo de log é absolutamente parte da transação e deve falhar em toda a transação, caso não possa ser concluída.
Pensar nos dois separadamente é útil para mim, não apenas porque um é "opcional" e o outro obrigatório, mas porque, dependendo dos requisitos, talvez eu precise implementá-los separadamente. Pode ser que algumas vezes sejam frutas, mas uma é maçãs e as outras laranjas. Normalmente, uma única estrutura de log pode lidar com ambos.
Na maioria das tarefas do servidor, o registro é crucial, já que o administrador geralmente não está presente quando as coisas acontecem, portanto, ele precisa verificar posteriormente.
Mas um cara do Google me disse uma vez que os processos do servidor não fazem log; 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 isso", "buscar isso"; eles obtêm coisas como "45.453 arquivos abertos", "653 clientes do serviço X", "resposta média de 344 ms para a consulta Y"
Certamente é uma abordagem diferente, e que eu tenho em mente ao cuidar dos meus sistemas, mesmo que sejam algumas ordens de magnitude menores.
Eu vim de um aplicativo N-Tiered do winforms que registrava tudo.
Não foi muito útil.
Claro, as exceções de log são ótimas; mas por que registrá-los na máquina do cliente quando você pode simplesmente enviar a exceção por e-mail para a equipe de desenvolvimento?
Registrar informações facilmente se transforma em um vício cujo valor raramente é justificado. Para todas as situações em que você pode fazer login gratuitamente, é melhor coletar informações direcionadas e enviá-las para onde você precisar.
A captura de informações de exceção é essencial, pois pode ser muito útil até certo ponto. Às vezes, porém, as 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 as informações apropriadas.
O registro é limitado apenas à captura de informações de erro?
No meu caso (aplicativo da Web), eu sempre registro qual página é visitada, quando, em que clicam, onde o ip e o navegador etc. Até registro o tempo total de carregamento de cada visita, para saber quais páginas estão lentas e precisa de otimização. para que eu possa dizer que logo o máximo possível.
a princípio, eu não tinha ideia de quão significativo será. mas aparentemente é muito útil em muitas coisas (além da depuração):
Penso que o registro pode se tornar mais significativo se gostarmos de extrair informações estatísticas nele.
Sou desenvolvedor de uma empresa cujos produtos são implantados no exterior. Quando uma equipe de suporte pergunta sobre a definição de um 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 registro os dados recebidos no meu módulo e as ações relacionadas. Se eu conseguir reproduzir o erro com a ajuda dos dados coletados, posso corrigi-lo com a depuração. Se eu não tivesse arquivos de log, teria que depender da descrição do cliente ou da equipe de suporte do que acontece em que caso (o que tem uma grande chance de enganar).
Em segundo lugar, o registro me dá a chance de detectar os gargalos do meu módulo no site implantado, pois registro a data e a hora de determinadas ações e, em seguida, posso ver qual ação consome quanto tempo.
Além disso, suponha que nossa solução seja composta por 6 módulos e eu esteja vendo logs de erro nos meus arquivos de log sobre tempos limite do banco de dados. Se esses erros também estiverem registrados em 5 dos outros módulos, a probabilidade de que este seja um problema relacionado ao servidor SQL aumenta. Se isso for registrado apenas no meu módulo, a probabilidade de minhas consultas serem com erros aumentará. Eu acho que esses tipos de coisas são indicadores úteis.
O tipo de dados que 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. Porém, quando aprimoramos 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.
O registro é útil para as informações que você não pode obter por outros programas:
Nota: Você deseja pelo menos DOIS arquivos de log.
O INFO está sempre ativado. O DEBUG está ativado quando necessário.
Escreva o código de log antecipando que um dia você precisará depurar uma situação em que TUDO o que você tem é o arquivo de log e fazer o que é correto pode ser a diferença entre ser demitido e promovido.
Para 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 aprimora essencialmente sua pilha de chamadas com valores de parâmetros e pode permitir que você analise a situação apenas com o rastreamento da pilha e sem precisar ver os arquivos de log.
Eu também recomendaria que todos os aplicativos não triviais utilizem log em vários níveis.
Pelas razões apontadas por outros, é uma ferramenta inestimável para resolver problemas com o aplicativo.
Em alguns casos, o log é essencial, por exemplo, em aplicativos financeiros e outros domínios que exigem logs de atividades, para segurança, métricas de uso e auditoria.
Certamente depende do tipo de sistema que você está construindo.
Se você estiver escrevendo um aplicativo de área de trabalho independente, como um processador de texto, provavelmente não precisará de nenhum log.
Se você estiver escrevendo um sistema incorporado, não poderá viver sem o log. Caso contrário, quando o dispositivo incorporado congelar, você não fará ideia do porquê. Você também precisa fazer logon sempre que seu sistema envolver vários processos ou várias máquinas físicas se comunicando. Novamente, quando o sistema trava, você precisa saber qual parte dele morreu quando e por que. Você precisa comparar os logs para determinar se os dados chegaram ou não de um processo para o outro. Da mesma forma, você precisa fazer logon sempre que seu sistema for executado por longos períodos de tempo sem muita interação direta do usuário.
O registro é sempre útil. Mas, ao implementar, esteja ciente de que não é necessariamente você quem irá ler os logs. Talvez seja algum tipo de administrador, usuário final, cliente, equipe de suporte, ...
Portanto, não apenas registre traços de pilha, mas também algumas informações adicionais que podem ser interpretadas por não desenvolvedores. Quando seu aplicativo é mantido por alguns outros grupos, também é útil escrever alguns códigos de erro exclusivos em seus logs. Isso pode facilitar o suporte, automação, ...
Outro ponto da perspectiva do administrador: pense na rotação de logs.