Eu trabalho com sistemas críticos de segurança em tempo real, e a criação de logs geralmente é a única maneira de detectar bugs raros que aparecem uma vez na lua azul a cada 53ª terça-feira quando é lua cheia, se você entender minha tendência. Isso meio que deixa você obsessivo com o assunto, então peço desculpas agora se começar a espuma na boca. O seguinte foi escrito para logs de depuração de código nativo, mas a maioria também é aplicável ao mundo gerenciado ...
Use arquivos de log de texto. Parece óbvio, mas algumas pessoas tentam gerar arquivos de log binários: isso é idiota, porque eu não preciso procurar uma ferramenta de leitura quando estou em campo. Além disso, se for texto e a depuração for detalhada, há uma boa chance de o engenheiro de campo ler o arquivo e diagnosticar o problema sem nunca voltar para mim. Todo mundo ganha.
Projecto sistemas capazes de registrar praticamente tudo, mas por padrão não ligo tudo. As informações de depuração são enviadas para uma caixa de diálogo de depuração oculta, que as marca e as envia para uma caixa de listagem (limitada a cerca de 500 linhas antes da exclusão), e a caixa de diálogo permite que eu pare, salve-a automaticamente em um arquivo de log ou desvie-a para um depurador conectado. Esse desvio me permite ver a saída de depuração de vários aplicativos, tudo serializado ordenadamente, que às vezes pode salvar vidas. Eu costumava usar níveis de registro numérico (quanto mais alto você define o nível, mais captura):
off
errors only
basic
detailed
everything
mas isso é muito inflexível - à medida que você trabalha em direção a um bug, é muito mais eficiente concentrar-se em fazer exatamente o que você precisa sem precisar percorrer toneladas de detritos e pode ser um tipo específico de transação ou operação Isso causa o erro. Se isso exigir que você ligue tudo, você está apenas dificultando seu próprio trabalho. Você precisa de algo mais refinado.
Então agora estou no processo de mudar para o log com base em um sistema de sinalização. Tudo o que é registrado tem um sinalizador detalhando que tipo de operação é, e há um conjunto de caixas de seleção que permitem definir o que é registrado. Normalmente, essa lista fica assim:
#define DEBUG_ERROR 1
#define DEBUG_BASIC 2
#define DEBUG_DETAIL 4
#define DEBUG_MSG_BASIC 8
#define DEBUG_MSG_POLL 16
#define DEBUG_MSG_STATUS 32
#define DEBUG_METRICS 64
#define DEBUG_EXCEPTION 128
#define DEBUG_STATE_CHANGE 256
#define DEBUG_DB_READ 512
#define DEBUG_DB_WRITE 1024
#define DEBUG_SQL_TEXT 2048
#define DEBUG_MSG_CONTENTS 4096
Esse sistema de registro é fornecido com a compilação do release , ativada e salva em arquivo por padrão. É muito tarde para descobrir que você deveria estar registrando APÓS o bug ter ocorrido, se esse bug ocorrer apenas uma vez a cada seis meses em média e você não tiver como reproduzi-lo. O registro que funciona apenas com compilações de depuração é justo. avião. idiota.
O software normalmente é fornecido com ERROR, BASIC, STATE_CHANGE e EXCEPTION ativado, mas isso pode ser alterado no campo através da caixa de diálogo de depuração (ou uma configuração de registro / ini / cfg, onde essas coisas são salvas).
Ah, e uma coisa - meu sistema de depuração gera um arquivo por dia. Seus requisitos podem ser diferentes. Mas verifique se o seu código de depuração inicia todos os arquivos com a data, a versão do código que você está executando e, se possível, com algum marcador para o ID do cliente, a localização do sistema ou o que for. Você pode obter uma mistura de arquivos de log vindo do campo e precisa de algum registro do que veio de onde e qual versão do sistema eles estavam executando, que está realmente nos próprios dados e não pode confiar no cliente / engenheiro de campo para dizer qual versão eles têm - eles podem apenas dizer qual versão eles pensam que têm. Pior, eles podem relatar a versão exe que está no disco, mas a versão antiga ainda está em execução porque se esqueceu de reiniciar após a substituição. Faça com que seu código diga a si mesmo.
Por fim, você não deseja que seu código gere seus próprios problemas; portanto, coloque uma função de timer para limpar os arquivos de log após tantos dias ou semanas (basta verificar a diferença entre a hora atual e a hora da criação do arquivo). Isso é bom para um aplicativo de servidor que é executado o tempo todo; em um aplicativo do lado do cliente, você pode limpar todos os dados antigos ao iniciar. Normalmente, limpamos após 30 dias ou mais, em um sistema sem visitas frequentes ao engenheiro, talvez você queira deixá-lo por mais tempo. Obviamente, isso também depende do tamanho dos seus arquivos de log.