3.1 Lista poziomów wydarzeń

Rejestrowanie to proces rejestrowania wszelkich zdarzeń, które mają miejsce podczas działania programu. Twoim obowiązkiem jako programisty jest record everything importantto, że wtedy, gdy productionpojawią się dziwne i/lub poważne błędy, nie będziesz miał nic więcej oprócz tych logów.

Każdy błąd zostanie wyeliminowany wielokrotnie szybciej, jeśli masz wszystkie informacje na jego temat oraz całą historię połączeń. Ale stąd wynika prosty wniosek - logować wszystko ogólnie: wywołania wszystkich metod, wartości wszystkich parametrów.

To również nie wchodzi w grę – za dużo informacji jest tak samo złe, jak za mało. Potrzebujemy inteligentnego logowania. Stworzony przez człowieka dla człowieka. I tu dochodzimy do pierwszego faktu dotyczącego logowania – wszystkie wpisy w logu są podzielone na kategorie już w momencie ich tworzenia.

Lista poziomów wydarzeń

Programista, zapisując zdarzenie do logu, musi sam zdecydować, jak ważna jest to informacja. Poziom istotności zdarzenia jest wybierany przez autora wiadomości. Istnieje log4j5 poziomów ważności zarejestrowanych informacji:

  • DEBUG
  • INFO
  • WARN
  • ERROR
  • FATAL

Poniżej opowiemy o nich bardziej szczegółowo.

3.2 DEBUGOWANIE

Poziom DEBUGjest uważany za najmniej ważny. Informacje o tym poziomie ważności zapisywane w dzienniku są potrzebne tylko podczas debugowania aplikacji. W celu zarejestrowania informacji potrzebnych podczas debugowania stosowana jest metoda debug().

Java webinar

Przykład:

class Manager {
    private static final Logger logger = LoggerFactory.getLogger(Manager.class);

    public boolean processTask(Task task) {
        logger.debug("processTask id = " + task.getId());
        try {
            task.start();
            task.progress();
            task.complete();
            return true;
        } catch (Exception e) {
            logger.error("Unknown error", e);
            return false;
        }
    }
}

Zwróć uwagę, metoda debugjest na samym początku metody (metoda nie zdążyła jeszcze nic zrobić) i zapisuje do logu wartość zmiennej przekazanej do metody. Jest to najczęstszy przypadek użycia metody debug().

3.3 INFORMACJE i OSTRZEŻENIA

Kolejne dwa poziomy to INFOi WARN. Istnieją dla nich dwie metody - info()i warn().

Poziom INFOjest używany po prostu do komunikatów informacyjnych: dzieje się to i tamto. Kiedy zaczynasz analizować błąd w dzienniku, bardzo przydatne może być przeczytanie jego tła. Metoda jest do tego idealna info().

Poziom WARNsłuży do zapisywania ostrzeżeń (od słowa ostrzeżenie ). Zwykle przy takim poziomie ważności pisana jest informacja, że ​​coś poszło nie tak, ale program wie, co w takiej sytuacji zrobić.

Na przykład w trakcie zapisywania pliku na dysk okazało się, że taki plik już istnieje. Tutaj program może zarejestrować ostrzeżenie (ostrzeżenie), ale pokazać użytkownikowi okno dialogowe i zaoferować wybór innej nazwy pliku.

Przykład:

class FileManager {
    private static final Logger logger = LoggerFactory.getLogger(FileManager.class);

    public boolean saveFile(FileData file) {
        logger.info(“save the file ” + file.getName());
        boolean resultOK = SaveUtils.save(file);
        if (resultOK) return true;

        logger.warn(“file writing problem ” + file.getName());
        String filename = Dialog.selectFile();
        boolean result = SaveUtils.save(file, filename);
        return result;
    }

3.4 BŁĄD i KRYTYCZNY

Wreszcie dwa najważniejsze poziomy rejestrowania to ERRORi FATAL. Dla nich istnieją również specjalne metody o tych samych nazwach: error()i fatal().

Postanowili też podzielić błędy na dwie kategorie – błędy zwykłe i błędy krytyczne . Błąd krytyczny najczęściej powoduje awarię aplikacji (w przypadku aplikacji komputerowych) lub awarii usługi internetowej (w przypadku aplikacji internetowych).

Innym dobrym przykładem jest system operacyjny Windows. Jeśli twój program właśnie się zawiesił, to z punktu widzenia systemu operacyjnego jest to Error. A jeśli sam system operacyjny padł i widzisz niebieski ekran śmierci systemu Windows, to już jest Fatal error.

W aplikacjach Java zdarzenia Errorsą najczęściej Fatalkojarzone z zgłaszanymi wyjątkami. Przykład:

class Manager {
    private static final Logger logger = LoggerFactory.getLogger(Manager.class);

    public boolean processTask(Task task) {
        logger.debug("processTask id = " + task.getId());
        try {
            task.start();
            task.progress();
            task.complete();
            return true;
        } catch (Exception e) {
            logger.error("Unknown error", e);
            return false;
        }
    }
}

3.5 Co rejestrować

Oczywiście nie warto rejestrować wszystkiego po kolei. W większości przypadków drastycznie pogarsza to czytelność logu, a przecież log jest zapisywany w pierwszej kolejności po to, aby można go było przeczytać.

Ponadto do dziennika nie można zapisywać różnych informacji osobistych i finansowych. Teraz z tym ściśle i łatwo możesz natknąć się na grzywny lub procesy sądowe. Prędzej czy później taka kłoda wycieknie na bok i wtedy nie będzie problemów.

Co zatem powinno być rejestrowane?

Najpierw musisz zalogować uruchomienie aplikacji . Po uruchomieniu aplikacji zaleca się zapisanie trybu jej działania oraz różnych ważnych ustawień - ułatwi to w przyszłości odczytanie logu.

Po drugie, musisz logować stan wszystkich usług firm trzecich , z którymi współpracuje Twoja aplikacja: systemów mailingowych, wszelkich usług zewnętrznych. Jako minimum musisz zabezpieczyć moment połączenia z nimi, aby mieć pewność, że działają poprawnie.

Po trzecie, wszystkie wyjątki muszą być rejestrowane . Jeśli są oczekiwane, informacje na ich temat można zapisać zwięźle. Pełne informacje o wyjątkach dają 50%-80% ważnych informacji podczas wyszukiwania błędu.

Należy również zarejestrować zamknięcie aplikacji . Aplikacja musi kończyć się normalnie i nie wyrzucać do logu dziesiątek błędów. Często w tym miejscu można znaleźć zablokowane zadania, problemy z pulą wątków, czy problemy z usuwaniem plików tymczasowych.

Pamiętaj, aby rejestrować wszystko, co dotyczy bezpieczeństwa i autoryzacji użytkownika . Jeśli użytkownik spróbuje zalogować się lub zresetować hasło 10 razy z rzędu, informacja ta powinna zostać odzwierciedlona w logach.

Rejestruj jak najwięcej informacji o zadaniach asynchronicznych — wyjątki często giną w takich wątkach. W przypadku zadania asynchronicznego należy zarejestrować jego rozpoczęcie i zakończenie. Pomyślne zakończenie powinno być rejestrowane w taki sam sposób jak problematyczne.

Co jeszcze? Uruchamianie zadań czasowych, uruchamianie przechowywanych zadań SQL-procedures, synchronizacja danych, wszystko związane z transakcjami rozproszonymi. Myślę, że to wystarczy na początek. W przyszłości dodasz do tej listy.