Dziennik zdarzeń jest bezużyteczny na dwa sposoby: gdy nie zapisuje nic istotnego i gdy zapisuje wszystko.
Co zapisywać
- błędy wraz z okolicznościami wystąpienia,
- operacje zmieniające dane,
- logowania i próby nieudane,
- uruchomienia zadań cyklicznych,
- wywołania usług zewnętrznych i ich odpowiedzi.
Sam komunikat o błędzie rzadko wystarcza. Potrzebne są okoliczności: kto wykonywał operację, na jakich danych, z jakiego miejsca w systemie. Wpis bez tego kontekstu mówi, że coś się nie udało, ale nie pozwala tego powtórzyć — a błąd, którego nie da się odtworzyć, zwykle zostaje nienaprawiony.
Poziomy ważności
Rozróżnienie błędu od ostrzeżenia i od informacji. Bez tego nie da się odfiltrować rzeczy istotnych z tysięcy wpisów.
Poziom warto dobierać według skutku, nie według wrażenia. Błąd to sytuacja, w której operacja się nie wykonała. Ostrzeżenie — wykonała się, ale inaczej niż zwykle. Zbyt hojne używanie najwyższego poziomu sprawia, że filtrowanie po nim przestaje cokolwiek dawać.
Bez danych wrażliwych
Hasła, numery kart i pełne dane osobowe nie trafiają do dziennika. To najczęstszy sposób, w jaki takie dane wyciekają poza system.
Najczęściej dzieje się to przy zapisywaniu całej treści żądania albo odpowiedzi usługi zewnętrznej „na wszelki wypadek". Dzienniki bywają kopiowane, przekazywane do analizy i trzymane latami, więc raz zapisane dane zostają w wielu miejscach naraz. Szerszy zestaw zasad zawiera tekst o bezpieczeństwie skryptów administracyjnych.
Identyfikator zdarzenia
Wspólny znacznik dla wszystkich wpisów jednego żądania pozwala prześledzić przebieg. Bez niego wpisy z równoległych operacji mieszają się nierozerwalnie.
Ten sam identyfikator warto pokazać użytkownikowi przy komunikacie o błędzie. Zgłoszenie z takim numerem prowadzi prosto do właściwych wpisów, zamiast zaczynać od ustalania, kiedy dokładnie to było. Przy wymianie danych między systemami dobrze jest przekazywać go dalej — wtedy jedno zdarzenie da się prześledzić po obu stronach.
Rotacja
Dzienniki bez ograniczenia rozmiaru zapełniają dysk. Rotacja z ustalonym okresem przechowywania to jedno ustawienie i rozwiązany problem.
Okres przechowywania powinien wynikać z tego, do czego dziennik służy. Do diagnozy awarii wystarczają ostatnie tygodnie; do wyjaśniania nieprawidłowości w danych potrzeba dłuższej historii, ale wtedy lepiej trzymać ją spakowaną i poza serwerem produkcyjnym. To także najczęstsza przyczyna problemów opisanych w tekście o monitorowaniu miejsca na dysku.
Przegląd zamiast czekania
Zestawienie najczęstszych błędów raz w tygodniu pokazuje problemy, których nikt nie zgłosił, bo nauczył się je obchodzić.
Warto patrzeć nie tylko na liczby bezwzględne, ale i na zmianę. Nowy rodzaj błędu, który pojawił się po wdrożeniu, jest ważniejszy niż stary, powtarzalny i znany. Przegląd zajmuje kilkanaście minut i zwykle kończy się listą drobnych poprawek, które nigdy nie trafiłyby do zgłoszenia.
