Diretrizes de registro em log

Os logs de eventos armazenam registros de eventos significativos em nome do sistema e dos aplicativos em execução no sistema. Como as funções de log são de uso geral, você deve decidir quais informações são apropriadas. Geralmente, você deve registrar apenas informações que possam ser úteis no diagnóstico de um problema de hardware ou software. O registro de eventos não deve ser usado como ferramenta de rastreamento.

Escolhendo eventos para registrar

Veja a seguir exemplos de casos em que o log de eventos pode ser útil:

• Problemas de recursos. Registrar um evento de aviso quando a alocação de memória falha, pode ajudar a indicar a causa de uma situação de pouca memória.
• Problemas de hardware. Se um driver de dispositivo encontrar um tempo limite do controlador de disco, uma falha de energia em uma porta paralela ou um erro de dados de uma placa de rede ou serial, o driver de dispositivo poderá registrar informações sobre esses eventos para ajudar o administrador do sistema a diagnosticar problemas de hardware.
• Setores defeituosos. Se um driver de disco encontrar um setor defeituoso, ele poderá ler ou gravar no setor depois de repetir a operação, mas o setor ficará defeituoso eventualmente. Se o driver de disco puder continuar, ele deverá registrar um evento de aviso, caso contrário, ele deve registrar um evento Error. Se um driver do sistema de arquivos encontrar um grande número de setores defeituosos e corrigi-los, o registro de eventos de aviso poderá ajudar um administrador a determinar que o disco pode estar prestes a falhar.
• Informação de eventos. Um aplicativo de servidor (como um servidor de banco de dados) registra um usuário fazendo logon, abrindo um banco de dados ou iniciando uma transferência de arquivo. O servidor também pode registrar outros eventos, como erros (não é possível acessar o arquivo, processo de host desconectado e assim por diante), corrupção do banco de dados ou se uma transferência de arquivo foi bem-sucedida.

Escrevendo mensagens

As mensagens devem fazer sentido para administradores e usuários que estão tentando solucionar um problema. Uma mensagem deve conter todas as informações necessárias para entender o que causou o problema e como corrigi-lo.

Evite escrever uma mensagem enigmática como por exemplo: um pacote de driver recebido do subsistema de E/S era inválido. Os dados são o pacote. Uma mensagem melhor indicaria que o driver em questão está funcionando corretamente, mas está registrando pacotes formatados incorretamente. Poderia dizer que uma versão Unicode do driver é necessária para corrigir o problema. Para obter mais informações sobre como escrever boas mensagens de erro, consulte Diretrizes de mensagens de erro.

Não use tabulações ou vírgulas no texto da mensagem, pois os logs de eventos podem ser salvos como arquivos de texto separados por vírgula ou tabulação. Muitas organizações importam esses arquivos para bancos de dados e os caracteres de formatação extras exigirão manipulação manual.

Ao usar nomes UNC ou outros links que contenham espaços, coloque o nome entre colchetes angulares. Por exemplo, <\\sharename\servername.>. Você pode escrever uma URL no final da mensagem que direcione o usuário para o material de ajuda relacionado. A URL deve ser um nome de host DNS totalmente qualificado. Por exemplo, você pode anexar o seguinte texto às suas mensagens: para obter informações adicionais sobre esta mensagem, visite nosso site de suporte em https://www.microsoft.com/Support/ProdRedirect/ContentSearch.asp. O link levaria para uma página ASP que redireciona o usuário para o conteúdo relacionado à mensagem de erro. Ele analisaria parâmetros adicionais (passados quando o URL é clicado) para determinar para onde redirecionar o usuário.

Os argumentos passados para a função ReportEvent são acrescentados à URL da seguinte maneira:

strHTTPQuery += L"?EvtSrc=" + _strEscapedSource;
strHTTPQuery += L"&EvtCat=" + _strEscapedCategory;
strHTTPQuery += L"&EvtID=" + _strEscapedEventID;
strHTTPQuery += L"&EvtCatID=" + _strEscapedCategoryID;
strHTTPQuery += L"&EvtType=" + _strEscapedType;
strHTTPQuery += L"&EvtTypeID=" + _strEscapedTypeID;
strHTTPQuery += L"&EvtRptTime=" + _strEscapedDateAndTime;
strHTTPQuery += L"&EvtTZBias=" + _strEscapedTimeZoneBias;

Se o nome da empresa, o nome do produto, a versão do produto, o nome do arquivo e a versão do arquivo do cabeçalho da DLL da mensagem para a origem do evento forem válidos, eles também serão anexados à URL:

ADD_VER_STR(L"CoName",   _strEscapedCompanyName);
ADD_VER_STR(L"ProdName", _strEscapedProductName);
ADD_VER_STR(L"ProdVer",  _strEscapedProductVersion);
ADD_VER_STR(L"FileName", _strEscapedFileName);
ADD_VER_STR(L"FileVer",  _strEscapedFileVersion);

Redução da sobrecarga

O log de eventos consome recursos como espaço em disco e tempo do processador. A quantidade de espaço em disco que um log de eventos requer e a sobrecarga de um aplicativo que registra eventos, dependem da quantidade de informações que você escolhe registrar. É por isso que é importante registrar apenas as informações essenciais. Também é bom colocar as chamadas de registro de eventos em um caminho de erro no código, em vez de no caminho principal do código, o que reduziria o desempenho.

A quantidade de espaço em disco necessária para cada registro de log de eventos inclui os membros da estrutura EVENTLOGRECORD. Esta é uma estrutura de comprimento variável. Strings e dados binários são armazenados seguindo a estrutura.