Udostępnij za pośrednictwem

Wytyczne dotyczące rejestrowania

  • Artykuł

Dzienniki zdarzeń przechowują rekordy znaczących zdarzeń w imieniu systemu i aplikacji uruchomionych w systemie. Ponieważ funkcje rejestrowania są ogólnego przeznaczenia, musisz zdecydować, jakie informacje są odpowiednie do rejestrowania. Ogólnie rzecz biorąc, należy rejestrować tylko informacje, które mogą być przydatne podczas diagnozowania problemu ze sprzętem lub oprogramowaniem. Rejestrowanie zdarzeń nie jest przeznaczone do użycia jako narzędzie do śledzenia.

Wybieranie zdarzeń do rejestrowania

Poniżej przedstawiono przykłady przypadków, w których rejestrowanie zdarzeń może być przydatne:

  • Problemy z zasobami. Rejestrowanie zdarzenia ostrzegawczego, gdy alokacja pamięci kończy się niepowodzeniem, może pomóc wskazać przyczynę sytuacji z małą ilością pamięci.
  • Problemy sprzętowe. Jeśli sterownik urządzenia napotka limit czasu kontrolera dysku, awarię zasilania w porcie równoległym lub błąd danych z sieci lub karty szeregowej, sterownik urządzenia może rejestrować informacje o tych zdarzeniach, aby pomóc administratorowi systemu zdiagnozować problemy sprzętowe.
  • Złe sektory. Jeśli sterownik dysku twardego napotka uszkodzony sektor, może być w stanie go odczytać lub zapisać po ponowieniu próby wykonania operacji, ale sektor w końcu będzie uszkodzony. Jeśli sterownik dysku może kontynuować, powinien zarejestrować zdarzenie Ostrzeżenie; w przeciwnym razie powinien zarejestrować zdarzenie Błąd. Jeśli sterownik systemu plików znajdzie dużą liczbę nieprawidłowych sektorów i je naprawi, rejestrowanie zdarzeń ostrzegawczych może pomóc administratorowi określić, że dysk może zakończyć się niepowodzeniem.
  • Zdarzenia informacyjne. Aplikacja serwera (na przykład serwer bazy danych) rejestruje logowanie użytkownika, otwieranie bazy danych lub uruchamianie transferu plików. Serwer może również rejestrować inne zdarzenia, takie jak błędy (nie można uzyskać dostępu do pliku, rozłączony proces hosta itd.), uszkodzenie bazy danych lub czy transfer plików zakończył się pomyślnie.

Pisanie komunikatów

Komunikaty powinny mieć sens dla administratorów i użytkowników, którzy próbują rozwiązać problem. Komunikat powinien zawierać wszystkie informacje potrzebne do zrozumienia przyczyny problemu i sposobu jego rozwiązania.

Unikaj pisania tajemniczego komunikatu, takiego jak "Pakiet sterownika odebrany z podsystemu we/wy był nieprawidłowy. Dane są pakietem". Lepszy komunikat wskazuje, że sterownik, którego dotyczy problem, działa prawidłowo, ale rejestruje niepoprawnie sformatowane pakiety. Można powiedzieć, że do rozwiązania problemu potrzebna jest wersja Unicode sterownika. Aby uzyskać więcej informacji na temat pisania dobrych komunikatów o błędach, zobacz Wskazówki dotyczące komunikatów o błędach.

Nie używaj kart ani przecinków w tekście wiadomości, ponieważ dzienniki zdarzeń można zapisywać jako pliki tekstowe rozdzielane przecinkami lub tabulatorami. Wiele organizacji importuje te pliki do baz danych, a dodatkowe znaki formatowania będą wymagały ręcznego manipulowania.

W przypadku używania nazw UNC lub innych łączy zawierających spacje należy ująć nazwę w nawiasy kątowe. Na przykład <\\nazwa_udziału\nazwa_serwera>. Możesz napisać adres URL na końcu komunikatu wskazującego użytkownika na powiązane materiały pomocy. Adres URL musi być w pełni kwalifikowaną nazwą hosta DNS. Możesz na przykład dołączyć następujący tekst do wiadomości: "Aby uzyskać dodatkowe informacje na temat tej wiadomości, odwiedź naszą witrynę pomocy technicznej pod adresem https://www.microsoft.com/Support/ProdRedirect/ContentSearch.asp. Link prowadzi do strony ASP, która przekierowuje użytkownika do zawartości dotyczącej komunikatu o błędzie. Analizuje dodatkowe parametry (przekazywane po kliknięciu adresu URL), aby określić, gdzie przekierować użytkownika.

Argumenty przekazane do funkcji ReportEvent są dołączane do adresu URL w następujący sposób:

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;

Jeśli nazwa firmy, nazwa produktu, wersja produktu, nazwa pliku i wersja pliku z nagłówka biblioteki DLL komunikatu dla źródła zdarzeń są prawidłowe, są również dołączane do adresu 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);

Zmniejszenie nakładu pracy

Rejestrowanie zdarzeń zużywa zasoby, takie jak miejsce na dysku i czas procesora. Ilość miejsca na dysku wymaganego przez dziennik zdarzeń oraz obciążenie aplikacji, która rejestruje zdarzenia, zależy od ilości informacji, które mają być rejestrowane. Dlatego ważne jest, aby rejestrować tylko istotne informacje. Warto również umieścić wywołania rejestrowania zdarzeń w ścieżce błędu w kodzie, a nie w głównej ścieżce kodu, co mogłoby zmniejszyć wydajność.

Ilość miejsca na dysku wymaganego dla każdego rekordu dziennika zdarzeń obejmuje elementy członkowskie struktury EVENTLOGRECORD. Jest to struktura o zmiennej długości; ciągi i dane binarne są przechowywane zgodnie ze strukturą.