Protokollierungsrichtlinien

Ereignisprotokolle speichern Datensätze wichtiger Ereignisse im Auftrag des Systems und der Anwendungen, die auf dem System ausgeführt werden. Da die Protokollierungsfunktionen universell sind, müssen Sie entscheiden, welche Informationen zum Protokollieren geeignet sind. Im Allgemeinen sollten Sie nur Informationen protokollieren, die bei der Diagnose eines Hardware- oder Softwareproblems hilfreich sein könnten. Die Ereignisprotokollierung soll nicht als Ablaufverfolgungstool verwendet werden.

Auswählen von zu protokollierenden Ereignissen

Im Folgenden finden Sie Beispiele für Fälle, in denen die Ereignisprotokollierung hilfreich sein kann:

• Ressourcenprobleme. Das Protokollieren eines Warnungsereignisses, wenn die Speicherzuweisung fehlschlägt, kann helfen, die Ursache für eine Situation mit geringem Arbeitsspeicher anzugeben.
• Hardwareprobleme. Wenn ein Gerätetreiber auf einen Timeout eines Datenträgercontrollers, einen Stromausfall in einem parallelen Port oder einen Datenfehler von einer Netzwerk- oder seriellen Karte stößt, kann der Gerätetreiber Informationen zu diesen Ereignissen protokollieren, um dem Systemadministrator bei der Diagnose von Hardwareproblemen zu helfen.
• Es liegen beschädigte Sektoren vor. Wenn ein Datenträgertreiber auf einen fehlerhaften Sektor stößt, kann er zwar nach einem erneuten Versuch den Sektor lesen oder beschreiben, aber der Sektor wird schließlich fehlerhaft. Wenn der Datenträgertreiber fortfahren kann, sollte ein Warnereignis protokolliert werden. Andernfalls sollte ein Fehlerereignis protokolliert werden. Wenn ein Dateisystemtreiber eine große Anzahl fehlerhafter Sektoren findet und diese behebt, kann das Protokollieren von Warnungsereignissen einem Administrator helfen, festzustellen, dass der Datenträger möglicherweise fehlschlägt.
• Informationsereignisse. Eine Serveranwendung (z. B. ein Datenbankserver) zeichnet eine Benutzeranmeldung auf, öffnet eine Datenbank oder startet eine Dateiübertragung. Der Server kann auch andere Ereignisse protokollieren, z. B. Fehler (Zugriff auf Datei nicht möglich, Hostprozess unterbrochen usw.), Beschädigung der Datenbank oder ob eine Dateiübertragung erfolgreich war.

Schreiben von Nachrichten

Die Meldungen sollten für Administratoren und Benutzer, die versuchen, ein Problem zu beheben, sinnvoll sein. Eine Meldung sollte alle Informationen enthalten, die erforderlich sind, um zu verstehen, was das Problem verursacht hat und wie es korrigiert werden kann.

Vermeiden Sie das Schreiben einer verschlüsselten Meldung, z. B. „Ein vom E/A-Subsystem empfangenes Treiberpaket war ungültig. Die Daten sind das Paket.” Eine bessere Meldung würde darauf hinweisen, dass der betreffende Treiber ordnungsgemäß funktioniert, aber falsch formatierte Pakete protokolliert. Es könnte auch heißen, dass eine Unicode-Version des Treibers erforderlich ist, um das Problem zu beheben. Weitere Informationen zum Schreiben guter Fehlermeldungen finden Sie in den Richtlinien für Fehlermeldungen.

Verwenden Sie keine Registerkarten oder Kommas im Meldungstext, da Ereignisprotokolle als Komma- oder tabstopptrennte Textdateien gespeichert werden können. Viele Organisationen importieren diese Dateien in Datenbanken, und die zusätzlichen Formatierungszeichen erfordern manuelle Manipulationen.

Wenn Sie UNC-Namen oder andere Links verwenden, die Leerzeichen enthalten, schließen Sie den Namen in spitze Klammern ein. Beispiel: <\\sharename\servername>. Sie können eine URL an das Ende der Meldung schreiben, die den Benutzer zu weiterführendem Hilfematerial führt. Die URL muss ein vollqualifizierter DNS-Hostname sein. Sie können z. B. den folgenden Text an Ihre Meldungen anfügen: „Weitere Informationen zu dieser Meldung finden Sie auf unserer Supportwebsite unter https://www.microsoft.com/Support/ProdRedirect/ContentSearch.asp” Der Link würde zu einer ASP-Seite führen, die den Benutzer zu Inhalten im Zusammenhang mit der Fehlermeldung umleitet. Es würde zusätzliche Parameter analysieren (übergeben, wenn auf die URL geklickt wird), um zu bestimmen, wo der Benutzer umgeleitet werden soll.

Die an die ReportEvent-Funktion übergebenen Argumente werden wie folgt an die URL angefügt:

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;

Wenn der Firmenname, der Produktname, die Produktversion, der Dateiname und die Dateiversion aus dem Nachrichten-DLL-Header für die Ereignisquelle gültig sind, werden sie auch an die URL angefügt:

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);

Reduzieren des Verwaltungsaufwands

Die Ereignisprotokollierung verbraucht Ressourcen wie Speicherplatz und Prozessorzeit. Der Speicherplatz, den ein Ereignisprotokoll benötigt, und der Aufwand für eine Anwendung, die Ereignisse protokolliert, hängt davon ab, wie viele Informationen Sie protokollieren möchten. Deshalb ist es wichtig, nur wichtige Informationen zu protokollieren. Es empfiehlt sich auch, Ereignisprotokollierungsaufrufe in einem Fehlerpfad im Code anstatt im Hauptcodepfad zu platzieren, wodurch die Leistung verringert wird.

Der für jeden Ereignisprotokolldatensatz erforderliche Speicherplatz enthält die Mitglieder der EVENTLOGRECORD-Struktur. Dies ist eine variable Längenstruktur; Zeichenfolgen und Binärdaten werden nach der Struktur gespeichert.