Directrices de registro

Los registros de eventos almacenan registros de eventos significativos en nombre del sistema y las aplicaciones que se ejecutan en el sistema. Dado que las funciones de registro son de uso general, debe decidir qué información es adecuada para registrar. Por lo general, solo debe registrar información que pueda ser útil para diagnosticar un problema de hardware o software. El registro de eventos no está pensado para usarse como herramienta de seguimiento.

Elección de eventos para registrar

A continuación se muestran ejemplos de casos en los que el registro de eventos puede resultar útil:

• Problemas de recursos. El registro de un evento de advertencia cuando se produce un error en la asignación de memoria puede ayudar a indicar la causa de una situación de poca memoria.
• Problemas de hardware. Si un controlador de dispositivo encuentra un tiempo de espera del controlador de disco, un error de alimentación en un puerto paralelo o un error de datos de una red o una tarjeta serie, el controlador de dispositivo puede registrar información sobre estos eventos para ayudar al administrador del sistema a diagnosticar problemas de hardware.
• Sectores malos. Si un controlador de disco encuentra un sector incorrecto, es posible que pueda leer o escribir en el sector después de reintentar la operación, pero el sector acabará mal. Si el controlador de disco puede continuar, debe registrar un evento warning; de lo contrario, debería registrar un evento error. Si un controlador del sistema de archivos encuentra un gran número de sectores incorrectos y los corrige, el registro de eventos de advertencia puede ayudar a un administrador a determinar que el disco puede estar a punto de producir un error.
• Eventos de información. Una aplicación de servidor (como un servidor de bases de datos) registra un usuario iniciando sesión, abriendo una base de datos o iniciando una transferencia de archivos. El servidor también puede registrar otros eventos, como errores (no se puede tener acceso a archivos, procesos de host desconectados, etc.), daños en la base de datos o si una transferencia de archivos se realizó correctamente.

Escribir los mensajes

Los mensajes deben tener sentido para los administradores y los usuarios que intentan solucionar un problema. Un mensaje debe contener toda la información necesaria para comprender lo que causó el problema y cómo corregirlo.

Evite escribir un mensaje críptico como "Un paquete de controlador recibido del subsistema de E/S no era válido. Los datos son el paquete". Un mensaje mejor indicaría que el controlador en cuestión funciona correctamente, pero registra paquetes con formato incorrecto. Podría continuar diciendo que se necesita una versión Unicode del controlador para corregir el problema. Para obtener más información sobre cómo escribir mensajes de error correctos, vea Directrices para mensajes de error.

No use tabulaciones ni comas en el texto del mensaje, ya que los registros de eventos se pueden guardar como archivos de texto separados por comas o tabulaciones. Muchas organizaciones importan estos archivos en bases de datos y los caracteres de formato adicionales requerirán manipulación manual.

Al usar nombres UNC u otros vínculos que contengan espacios, incluya el nombre entre corchetes angulares. Por ejemplo, <\\sharename\servername>. Puede escribir una dirección URL al final del mensaje que apunte al usuario al material de ayuda relacionado. La dirección URL debe ser un nombre de host DNS completo. Por ejemplo, podría anexar el texto siguiente a sus mensajes: "Para obtener información adicional sobre este mensaje, visite nuestro sitio de soporte técnico en https://www.microsoft.com/Support/ProdRedirect/ContentSearch.asp." El vínculo conduciría a una página ASP que redirige al usuario al contenido relacionado con el mensaje de error. Analizaría parámetros adicionales (pasados cuando se hace clic en la dirección URL) para determinar dónde redirigir al usuario.

Los argumentos pasados a la función ReportEvent se anexan a la dirección URL de la siguiente manera:

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;

Si el nombre de la empresa, el nombre del producto, la versión del producto, el nombre de archivo y la versión del archivo del encabezado dll del mensaje para el origen del evento son válidos, también se anexan a la dirección 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);

Reducción de la sobrecarga

El registro de eventos consume recursos como el espacio en disco y el tiempo del procesador. La cantidad de espacio en disco que requiere un registro de eventos y la sobrecarga de una aplicación que registra eventos depende de la cantidad de información que elija registrar. Este es el motivo por el que es importante registrar solo información esencial. También es conveniente colocar llamadas de registro de eventos en una ruta de acceso de error en el código en lugar de en la ruta de acceso del código principal, lo que reduciría el rendimiento.

La cantidad de espacio en disco necesario para cada registro de eventos incluye los miembros de la estructura EVENTLOGRECORD . Se trata de una estructura de longitud variable; Las cadenas y los datos binarios se almacenan siguiendo la estructura .