Práticas recomendadas para registrar ações do usuário na produção

Eu estava planejando registrar muitas coisas diferentes no meu ambiente de produção, como quando um usuário:

• Logins, Logoffs
• Mudar perfil
• Editar configurações da conta
• Alterar senha ... etc

Essa é uma boa prática a ser adotada em um ambiente de produção? Além disso, qual é uma boa maneira de registrar tudo isso. Atualmente, estou usando o seguinte bloco de código para fazer logon:

public void LogMessageToFile(string msg)
        {

            System.IO.StreamWriter sw = System.IO.File.AppendText(
                GetTempPath() + @"MyLogFile.txt");
            try
            {
                string logLine = System.String.Format(
                    "{0:G}: {1}.", System.DateTime.Now, msg);
                sw.WriteLine(logLine);
            }
            finally
            {
                sw.Close();
            }
        }

Isso será bom para a produção? Meu aplicativo é muito novo, por isso não estou esperando milhões de usuários imediatamente ou algo assim, procurando as melhores práticas para acompanhar as ações em um site ou, se é mesmo, as melhores práticas.

Esta não é uma resposta direta à pergunta, é mais uma expansão nela.

Quando você inicia um novo aplicativo, recomendo registrar tudo o que o usuário faz: faça login, efetue logout, risque seu a **, tudo. Se for baseado na Web, considere usar mapas de calor para saber o que o mouse estava fazendo.

Quando eu estava no projeto BravoX na Xerox, no final dos anos 70, gravamos movimentos de mouse pixel por pixel para descobrir como os usuários poderiam usar essa coisa estranha chamada editor WYSIWYG. Assistíamos a reproduções de sessões de usuários durante o almoço. Foi extremamente instrutivo. Descobrimos um padrão de uso que chamamos de Charlie Browning - o usuário selecionava algum texto e o tornava em itálico ... depois desfaziam ... depois refaziam ... e para trás e para frente e para trás. Acontece que eles estavam tentando entender essas coisas em um nível emocional. Então nós (Greg Kusnik fez o código, se a memória servir) colocamos algumas otimizações específicas para suportar exatamente esse comportamento.

Sem a gravação, nunca teríamos pensado em fazer isso.

Se eu fosse você e continuasse escrevendo um arquivo de texto, usaria o log4net e entraria em um arquivo "UserActions.log" específico. Dessa forma, não atrapalha seu registro normal. Ao usar o log4net (ou qualquer outra estrutura de registro), você pode evitar reinventar a roda e alavancar os anexadores de arquivos contínuos, os códigos de aviso / erro / depuração / informação, a gravação de arquivos em lotes etc. É sempre uma boa idéia criar um bom registro no qualquer aplicação em nível de produção.

Na realidade, porém, é provavelmente melhor armazenar todas essas informações em um banco de dados. O uso de um banco de dados permitirá classificá-lo, agregá-lo e fazer estatísticas mais fáceis

Os arquivos de log são usados ​​1. para obter informações sobre erros no sistema de depuração. 2. pesquisar a atividade do usuário por danos ou 3. entender como as pessoas usam o sistema quando você não pode vê-lo. Com aquilo em mente:

• Ambiente de log (por exemplo, vários ambientes, outras configurações, etc.) na inicialização do aplicativo. Isso é útil para problemas de depuração.
• Registre o usuário e a ação (a parte distinta da URL) para cada solicitação.
• Registre todos os parâmetros para cada solicitação, EXCETO as senhas. Eu gosto de colocar delimitadores em torno de cada parâmetro nos logs, por exemplo phone{(999)999-9999} email{aaa@aaa.com}. As senhas nunca devem ser gravadas em nenhum lugar, exceto no banco de dados de uma maneira, função de hash criptograficamente segura com sal exclusivo para cada usuário e várias rodadas de hash (consulte a nota de rodapé)
• Ao fazer login, você deve registrar o endereço IP, o ID do usuário, o nome, a contagem de logins com falha, talvez o navegador, talvez o ID da sessão de cookie, mas nunca a senha.
• Lembre-se de não registrar a senha na página de login E na página de alteração de senha, nem registrar a pergunta ou resposta secreta se tiver essa funcionalidade. Quaisquer outras senhas ou chaves de criptografia não devem ser registradas. É uma boa prática escrever algo como seis estrelas no log para esses parâmetros, para que você possa lembrar que suprimiu esses dados.
• Gosto de registrar o tempo total necessário para atender a cada solicitação: Done: 49ms
• Eu gosto de registrar alterações no estado da sessão. Estes devem ser raros.
• Como outros disseram, existem ótimas bibliotecas de registro disponíveis para o registro em arquivos, sem a certeza do registro em bancos de dados.
• Armazene logs com segurança. Mesmo sem senhas, existem leis estaduais, federais e internacionais sobre Informações de identificação pessoal (consulte Safe Harbor ) que tornam confidenciais os dados do registro.
• Faça backups. Se você permitir que eles fluam para um backup de unidade completa todas as noites, lembre-se de fazer o backup em outro lugar antes de atualizar para um novo servidor (não me pergunte como eu aprendi isso).

Outras dicas

Nota de rodapé: Para conectar alguém, faça o hash da senha fornecida com o mesmo algoritmo de hash e o sal do hash original para esse usuário. Se o hash da senha fornecida corresponder ao hash da senha armazenado no banco de dados, eles serão conectados. Para que isso funcione, você deve definir o conjunto de caracteres da sua senha, desaprovar o caractere de substituição Unicode e quaisquer outros caracteres fora do seu conjunto.

Você não especifica se está usando um banco de dados, mas se estiver e esse banco de dados é o SQL Server, poderá adicionar algo chamado AutoAudit e registrar automaticamente todas as interações com seus dados. Apenas certifique-se de especificar apenas os objetos que você deseja auditar.

De qualquer forma, eu não tentaria codificar manualmente meu rastreamento, pois isso acabaria sendo um pesadelo para a manutenção.

Além disso, para o registro, não faça o seu próprio, use o Enterprise Library Logging ou Log4Net ou similar.

Apenas um conselho geral. Pode não estar diretamente relacionado à sua pergunta.

Depende do que você usará os logs. Principalmente, os logs são usados ​​na produção para detectar as operações que causam os erros. Se você os mantém para rastrear as ações do usuário, isso não faz parte do log. Esse deve ser o recurso do lado do servidor do produto. Definitivamente, essas coisas precisam entrar no banco de dados para estudos posteriores. Mas os logs do lado do servidor, como "Ocorreu um erro, pois algum texto está vazio", não fazem parte do recurso. Essas coisas precisam estar no sistema de arquivos. Eles devem ter o seguinte conteúdo com eles: - user_id, error_number, error_text, file_name, function_name, thread_id, system_date_time e qualquer outro contexto.

Agora estou falando apenas dos logs nos arquivos.

1) Mantenha-os assíncronos. A operação de E / S é cara.

2) Projete-os como classe e função. Mudanças futuras serão fáceis.

3) Mantenha-os únicos, se possível. Singleton é difícil em multiencadeamento, portanto, projete corretamente.

4) Também é melhor manter a interação entre o logger e o loggee simples. Na maioria das vezes, envie o número da mensagem que o texto da mensagem real e permita que o criador de logs receba a mensagem do número. Isso ajudará se mais tarde desejarmos fazer alterações nos formatos genéricos de log.

Normalmente, o logger e também as coisas que precisamos registrar devem fazer parte do design. Vi casos em que houve alterações no design apenas para garantir que todas as informações relevantes sejam registradas corretamente.

Experimente o Log4Net. Ele permite que você efetue login em arquivos ou banco de dados. Aqui está o tutorial !

Usamos o Log4Net em todos os nossos projetos.

O uso de um arquivo de log apresenta alguns problemas. Primeiro, você pode receber erros quando vários processos tentam acessar o arquivo. Você também pode ter problemas ao tentar alternar ou limpar o arquivo enquanto o sistema está em execução. A maneira de contornar isso é usar um banco de dados.

Portanto, a etapa 1 é criar uma tabela de banco de dados. Sugiro os seguintes campos:
* ID do usuário
* Ação (por exemplo, logon, excluir foo)
* Algum texto descritivo (permita nulos aqui)
* carimbo de data / hora

Etapa 2, crie um procedimento armazenado com entrada para ID do usuário, ação e texto descritivo. Basta usar a hora atual para criar o carimbo de hora.

Etapa 3, escreva um método de registro em uma biblioteca compartilhada conveniente para facilitar a inclusão em qualquer lugar e entrar na prática de chamar esse método conforme necessário. Você também pode ter uma lógica de sinalizador de nível de log para alterar o que é registrado.

Etapa 4, crie uma rotina de manutenção para limpar as mensagens antigas da tabela de log de tempos em tempos. Talvez exclua quando tiver mais de X, execute cada semana mais ou menos como parte da manutenção regular do banco de dados (reconstrução do índice, etc.).

Depois de criar isso uma vez, você poderá usar o código envolvido em outros projetos.