Diretrizes de registro

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 registo são de uso geral, deves decidir quais informações são apropriadas para registar. Geralmente, você deve registrar apenas informações que possam ser úteis no diagnóstico de um problema de hardware ou software. O registo de eventos não se destina a ser utilizado como uma ferramenta de rastreio.

Escolhendo eventos para registrar

Seguem-se exemplos de casos em que o registo 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 rede ou placa serial, o driver de dispositivo pode 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 pode ser capaz de ler ou gravar no setor depois de tentar novamente a operação, mas o setor ficará ruim eventualmente. Se o driver de disco puder continuar, ele deverá registrar um evento de Aviso; caso contrário, ele deve registrar um evento de erro. Se um driver de sistema de arquivos encontrar um grande número de setores defeituosos e corrigi-los, registrar eventos de Aviso pode ajudar um administrador a determinar que o disco pode estar prestes a falhar.
• Eventos de informação. 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 "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 continuar a 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 Error Message Guidelines.

Não use tabulações ou vírgulas no texto da mensagem, porque os registos de eventos podem ser guardados como ficheiros de texto separados por vírgulas ou tabulações. Muitas organizações importam esses arquivos para bancos de dados, e os caracteres de formatação extra 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 aponte 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 a uma página ASP que redireciona o usuário para o conteúdo relacionado à mensagem de erro. Ele analisaria parâmetros adicionais (passados quando a URL é clicada) para determinar para onde redirecionar o usuário.

Os argumentos passados para a função ReportEventdosão anexados à 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 DLL da mensagem para a fonte 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 das despesas gerais

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 para um aplicativo que registra eventos dependem da quantidade de informações que você escolher registrar. É por isso que é importante registrar apenas informações essenciais. Também é bom colocar chamadas de registo de eventos num percurso de erro no código em vez de no percurso de código principal, algo que pode impactar negativamente o desempenho.

A quantidade de espaço em disco necessária para cada registo de registo 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.