Compartir a través de

Indicaciones y pautas sobre los registros

  • Artículo

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 la 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

Consulte los siguientes ejemplos de casos en los que el registro de eventos puede resultar útil:

  • Problemas de recursos. Registrar un evento de advertencia cuando se produce un error en la asignación de memoria puede indicar la causa de una situación de memoria baja.
  • Problemas de hardware. Si un controlador de dispositivo detecta 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 en serie, el controlador del dispositivo puede registrar información sobre estos eventos para que el administrador del sistema pueda diagnosticar problemas de hardware.
  • Sectores defectuosos. Si un controlador de disco detecta un sector defectuoso, es posible que pueda leer o escribir en el sector después de reintentar la operación, pero el sector seguirá dando error. Si el controlador de disco puede continuar, debe registrar un evento de advertencia; de lo contrario, debe registrar un evento de error. Si un controlador del sistema de archivos detecta un gran número de sectores defectuosos y los subsana, el registro de eventos de advertencia puede ayudar a un administrador a determinar que el disco está a punto de generar 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 acceder al archivo, proceso del host desconectado, etc.), daños en la base de datos o si una transferencia de archivos se ha realizado correctamente.

Escribir los mensajes

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

Evite escribir un mensaje críptico, como "El paquete del controlador recibido del subsistema de E/S no era válido. Los datos son el paquete". Un mensaje mejor redactado indicaría que el controlador en cuestión funciona correctamente, pero registra los paquetes con formato incorrecto. Podría decirse 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, consulte Recomendaciones sobre 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 con formatos adicionales se deben manipular manualmente.

Al usar nombres UNC u otros vínculos con espacios, incluya el nombre entre paréntesis angulares. Por ejemplo, <\\sharename\servername>. Puede escribir una dirección URL al final del mensaje que dirija al usuario al material de ayuda relacionado. La dirección URL debe ser un nombre de host DNS válido y completo. Por ejemplo, puede agregar el texto siguiente a los mensajes: "Para obtener información adicional sobre este mensaje, visite el sitio de soporte técnico en https://www.microsoft.com/Support/ProdRedirect/ContentSearch.asp". El vínculo le llevaría a una página ASP que redirige al usuario al contenido relacionado con el mensaje de error. Esto analizaría parámetros adicionales (que se pasan al hacer 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 del archivo y la versión del archivo del encabezado DLL del mensaje en 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);

Reducir sobrecarga

El registro de eventos consume recursos, como el espacio en disco y los tiempos del procesador. El volumen de espacio en disco que necesita un registro de eventos y la sobrecarga de una aplicación que registra eventos dependen de la cantidad de información que decida registrar. Este es el motivo por el que es importante registrar solo la información esencial. También es conveniente colocar llamadas de registro de eventos en la ruta de una error en el código y no en la ruta del código principal, ya 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.