Consignes de journalisation
Les journaux d’événements stockent des enregistrements d’événements significatifs pour le système et les applications exécutées sur le système. Étant donné que les fonctions de journalisation sont à usage général, vous devez décider quelles informations sont appropriées à consigner. En général, vous ne devez consigner que les informations pouvant être utiles pour diagnostiquer un problème matériel ou logiciel. La journalisation des événements n’est pas destinée à être utilisée comme un outil de traçage.
Choisir les événements à consigner
Les exemples suivants illustrent des cas où la journalisation des événements peut être utile :
- Problèmes de ressources. Consigner un événement Avertissement lorsque l’allocation de mémoire échoue peut aider à indiquer la cause d’une situation de faible mémoire.
- Problèmes matériels. Si un pilote de périphérique rencontre un délai d’attente du contrôleur de disque, une panne de courant sur un port parallèle, ou une erreur de données provenant d’une carte réseau ou série, le pilote de périphérique peut consigner des informations sur ces événements pour aider l’administrateur système à diagnostiquer les problèmes matériels.
- Secteurs défectueux. Si un pilote de disque rencontre un secteur incorrect, il peut être en mesure de lire ou d’écrire dans le secteur après une nouvelle tentative de l’opération, mais le secteur finira mal tôt ou tard. Si le pilote de disque peut continuer, il doit consigner un événement Avertissement ; sinon, il doit consigner un événement Erreur. Si un pilote de système de fichiers trouve un grand nombre de secteurs défectueux et les corrige, la journalisation d’événements Avertissement peut aider un administrateur à déterminer que le disque est sur le point de tomber en panne.
- Événements d’information. Une application serveur (comme un serveur de base de données) enregistre la connexion d’un utilisateur, l’ouverture d’une base de données, ou le démarrage d’un transfert de fichier. Le serveur peut également consigner d’autres événements tels que des erreurs (impossibilité d’accéder au fichier, processus hôte déconnecté, etc.), la corruption de base de données, ou si un transfert de fichier a réussi.
Écriture de messages
Les messages doivent être compréhensibles pour les administrateurs et les utilisateurs qui essaient de résoudre un problème. Un message doit contenir toutes les informations nécessaires pour comprendre la cause du problème et comment le corriger.
Évitez d’écrire un message cryptique tel que « Un paquet de pilote reçu du sous-système d’E/S était invalide. Les données sont le paquet ». Un meilleur message indiquerait que le pilote en question fonctionne correctement, mais consigne des paquets mal formatés. Il pourrait ajouter qu’une version Unicode du pilote est nécessaire pour corriger le problème. Pour plus d’informations sur la rédaction de bons messages d’erreur, veuillez consulter la section Consignes de messages d’erreur.
N’utilisez pas de tabulations ou de virgules dans le texte du message, car les journaux d’événements peuvent être enregistrés sous forme de fichiers texte séparés par des virgules ou des tabulations. De nombreuses organisations importent ces fichiers dans des bases de données, et les caractères de formatage supplémentaires nécessiteront une manipulation manuelle.
Lors de l’utilisation de noms UNC, ou d’autres liens contenant des espaces, encadrez le nom entre chevrons. Par exemple, <\\nom_partage\nom_serveur>. Vous pouvez écrire une URL à la fin du message qui dirige l’utilisateur vers du matériel d’aide connexe. L’URL doit être un nom d’hôte DNS entièrement qualifié. Par exemple, vous pourriez ajouter le texte suivant à vos messages : « Pour des informations supplémentaires sur ce message, veuillez visiter notre site de support à https://www.microsoft.com/Support/ProdRedirect/ContentSearch.asp
». Le lien conduirait à une page ASP qui redirige l’utilisateur vers le contenu relatif au message d’erreur. Elle analyserait les paramètres supplémentaires (passés lorsque l’URL est cliquée) pour déterminer où rediriger l’utilisateur.
Les arguments passés à la fonction ReportEvent sont ajoutés à l’URL comme suit :
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 le nom de la société, le nom du produit, la version du produit, le nom du fichier, et la version du fichier de l’en-tête DLL du message pour la source de l’événement sont valides, ils sont également ajoutés à l’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);
Réduire les frais généraux
La journalisation des événements consomme des ressources telles que l’espace disque et le temps processeur. La quantité d’espace disque requise par un journal d’événements et les frais généraux pour une application qui consigne des événements dépendent de la quantité d’informations que vous choisissez de consigner. C’est pourquoi il est important de ne consigner que les informations essentielles. Il est également bon de placer les appels de journalisation d’événements dans un chemin d’erreur dans le code plutôt que dans le chemin de code principal, ce qui réduirait les performances.
La quantité d’espace disque requise pour chaque enregistrement de journal d’événements inclut les membres de la structure EVENTLOGRECORD. C’est une structure de longueur variable ; les chaînes et les données binaires sont stockées après la structure.