Dlaczego dzienniki są potrzebne w Javie

1.1 Wprowadzenie do logów

Dziennik to lista zdarzeń, które miały miejsce. Prawie jak dziennik żeglarski lub pamiętnik. Cóż, odpowiednio, rejestrator jest obiektem, za pomocą którego można się logować. W programowaniu zwyczajowo rejestruje się prawie wszystko. A w Javie wszystko jest takie, a nawet trochę więcej.

Faktem jest, że programy Java są bardzo często dużymi aplikacjami serwerowymi bez interfejsu użytkownika, konsoli i tak dalej. Przetwarzają żądania od tysięcy użytkowników w tym samym czasie i często występują różne błędy. Zwłaszcza, gdy różne wątki zaczynają ze sobą kolidować.

I tak naprawdę jedynym sposobem na znalezienie rzadko powielanych błędów i awarii w takiej sytuacji jest zapisanie do dziennika/pliku wszystkiego , co dzieje się w każdym wątku.

Najczęściej do logu zapisywane są informacje o parametrach metody, z jaką została ona wywołana, o wszystkich przechwyconych błędach oraz dużo informacji pośrednich. Im pełniejszy dziennik, tym łatwiej odtworzyć kolejność zdarzeń i prześledzić przyczyny awarii lub błędu.

Ale im większy dziennik, tym trudniej z nim pracować. Czasami logi osiągają kilka gigabajtów dziennie. Jest okej.

1.2 Nieudane dzienniki

Jako pierwszych logów twórcy wykorzystali po prostu wyjście do konsoli . Wygodnie jest to zrobić podczas debugowania aplikacji - kiedy wszystkie ważne informacje i wartości zmiennych są zapisywane w konsoli. Ale taki dziennik jest całkowicie nieprzydatny podczas normalnego działania aplikacji.

Po pierwsze, aplikacja może chcieć sama coś wyprowadzać na konsolę, a użytkownik w ogóle nie chce widzieć informacji serwisowych przeznaczonych dla programisty.

Po drugie, rozmiar bufora konsoli jest ograniczony, nie można tam dużo pisać.

I wreszcie, po trzecie, informacje o błędach programu, które są gromadzone przez długi czas, powinny być przesyłane do twórców programu. I najwygodniej jest zapisać wszystkie te informacje naraz w pliku.

Twórcy szybko rozwiązali pierwszy problem – wymyślili kolejny strumień wyjściowy – System.err. Możesz pisać do niego wiadomości i będą one wysyłane do osobnego wątku, a nie do standardowej konsoli.

I nawet problem z zapisem do pliku został rozwiązany:

// Define the file to which we will write the log
System.setErr(new PrintStream(new File("log.txt")));
// Display messages
System.err.println("Message 1");
System.err.println("Message 2");
// Display an error message
try {
    throw new Exception("Error message");
} catch (Exception e) {
    e.printStackTrace();
}

Ale nawet w tej formie nie rozwiązało to całego problemu, dlatego postanowiono stworzyć specjalną bibliotekę, która zapisywałaby komunikaty dziennika do pliku. Zrobiła to w sprytny sposób i pozwoliła na elastyczność w konfigurowaniu filtrów dla rejestrowanych zdarzeń i danych.

Cały proces logowania składa się w rzeczywistości z trzech części:

• Pierwsza część to zbieranie informacji .
• Druga część to filtrowanie zebranych informacji.
• Trzecia część to zapis wybranych informacji.

1.3 Wprowadzenie do loggera log4j

Pierwszym popularnym rejestratorem w społeczności Java był log4j. Włączenie go do projektu jest bardzo proste, w tym celu wystarczy dodać kilka linii do pliku pom.xml

<dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>2.2.17</version>
</dependency>

Interakcja Twojego programu z takim loggerem wyglądałaby mniej więcej tak:

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

Wydają się tutaj trzy rzeczy:

Tworzenie obiektu jest podświetlone na zielono Logger . Jego obiekt jest przechowywany w zmiennej statycznej w celu wygodnej dalszej pracy z nim. A także getLogger()informacja o klasie, w której zbierane są informacje, jest przekazywana do metody.

Linia podświetlona na niebiesko to miejsce, w którym rejestrujemy wartościowe informacje tylko podczas debugowania . W tym celu stosuje się specjalną metodę -debug()

I wreszcie wiersz, w którym zapisujemy wyjątek, który pojawił się w dzienniku, jest podświetlony na czerwono . Wyjątki to potencjalne błędy, więc error().