Logi w serwerze aplikacji

Logi w serwerze aplikacji EuroAP cz. II – podsystem logowania

W drugiej części cyklu o logach w serwerze aplikacji EuroAP opowiemy o podsystemie logowania. Pokażemy, jak można wyklikać jego konfigurację w graficznej konsoli administratora.

W drugiej części cyklu o logach w serwerze aplikacji EuroAP opowiemy o podsystemie logowania. Pokażemy, jak można wyklikać jego konfigurację w graficznej konsoli administratora.

Przypomnijmy, że ostatnim razem pokazaliśmy, że za logowanie w EuroAP i pokrewnych serwerach aplikacji odpowiedzialne są, aż trzy mechanizmy: logowanie podczas uruchamiani (bootstrap logging), podsystem logowania, profile logowania. Dziś skupimy na podsystemie podsystemie, a konkretnie na root logerze i handlerach.

Podsystem logowania

Konfiguracją podsystemu logowania sterujemy przede wszystkim za pomocą dwóch elementów: kategorii (ang. categories) i handlerów (ang. handlers). Kategorie opisują, które wiadomości mają zostać przechwycone i przekazują je handlerowi. Handler odpowiada za zapisanie tych wiadomości.

Root logger

Zanim jednak przejdziemy do teorii, zauważmy, że z podsystemem logowania obcujemy już od pierwszego zetknięcia się z EuroAP. Dzieje się to za sprawą root loggera. Po polsku moglibyśmy go nazwać loggerem bazowym albo źródłowym. To dzięki niemu widzimy to, co wyświetla się nam w oknie terminala, gdy uruchomimy serwer aplikacji skryptem np. ./EUROAP_HOME/bin/standalone.sh. To on zapisuje logi do plików server.log.

Root logger to domyślnie skonfigurowany logger w EuroAP i pokrewnych serwerach aplikacji. Możemy podejrzeć jego konfigurację w graficznej konsoli administratora: Configuration > Subsystems > Logging > Configuration

Domyślnie root logger ma ustawiony poziom logowania INFO oraz 2 handlery – CONSOLE i FILE.

Gdy klikniemy przycisk „View”, następnie przejdziemy do Root Logger > Edit, to zobaczymy, że poza poziomem logowania i handlerem możemy zdefiniować także sposób filtrowania wiadomości (ang. filter spec).

Aby zrozumieć, co to oznacza, musimy poznać nieco teorii.

Handler

Handler na język polski moglibyśmy przetłumaczyć jako dyspozytor, manipulator, procedura albo obsługa – w naszym kontekście logowania. Zadaniem handlerów w podsystemie logowania jest bowiem zapisywanie logów.

W EuroAP i pokrewnych serwerach aplikacji mamy dostępnych 9 typów handlerów:

  • console – handler konsolowy. Ten typ jest wyjątkowy, ponieważ nie zapisuje logów. Po prostu wyświetla je na standardowym wyjściu (System.out), na standardowym wyjściu błędów (System.err) albo na `console` – wynik pracy handlera zostaje przekazany do klasy `java.io.PrintWriter`. To od niej zależy, co stanie się dalej

  • file – ten typ handlera zapisuje logi do pliku
  • periodic – tutaj logi także zostają zapisane do pliku, ale plik będzie okresowo (ang. periodic) rotowany. Gdy upłynie zadany czas, stary plik zostanie zapisany z odpowiednim znacznikiem czasowym, a nowe logi zapiszą się w nowo utworzonym pliku
  • size – zapisuje do pliku i rotuje, gdy plik osiągnie określony rozmiar. Wymaga określenia rozmiaru, przy który ma rotować oraz maksymalną ilość plików, które ma przetrzymywać na dysku. Gdy przychodzi czas rotowania, to stary plik zapisywany jest z odpowiednim numerem
  • periodic size – połączenie size i periodic. Rotuje co określony czas lub co zadaną wielkość

  • syslog – typ handlera, który umożliwia wysyłanie logów do zdalnego serwera. Przydatny, gdy chcemy trzymać logi z całego systemu w jednym miejscu, by móc je łatwo analizować
  • socket – jak syslog, tylko ze zdalnym serwerem łączy się po gnieździe sieciowym (ang. socket)
  • async – wrapper, który dostarcza asynchroniczne operacje dla innych typów handlerów. Warto go użyć, gdy logger ma duże opóźnienia (ang. latency) lub problemy wydajnościowe
  • custom – typ pozwalający używać własnego handlera. Własna implementacja musi rozszerzać java.util.logging.Handler oraz być zapakowana jako moduł. W ten sposób podłącza się appender Log4j.

Jak widać na screenshotach, poza nazwą handlera i typem, mamy do określenia jeszcze kilka atrybutów. Prawdopodobnie najciekawszymi są: poziom, formater i specyfikacja filtrów. Pierwsze dwa omówimy dziś, a specyfikację filtrów w następnym artykule.

Poziomy logowania

Poziomy logowania to coś, z czym z pewnością zetknął się każdy administrator i programista. To, co może zadziwić w EuroAP, to ich bogactwo. Poziomy logowania pozwalają pokazać, z jak ważną informacją mamy do czynienia. Są wykorzystywane przez handlery i kategorie do ograniczania przetwarzanych wiadomości.

Najpopularniejsze poziomy to: DEBUG, INFO, WARN, ERROR. Gdy spotykamy się z informacją z poziomu ERROR, to wiemy, że coś złego dzieje się w programie. WARN ostrzega nas przed potencjalnymi zagrożeniami np. używaniem domyślnej konfiguracji tam, gdzie nie jest to zalecane, czy używanie przestarzałych elementów. INFO dostarcza informacji o normalnym przebiegu pracy programu. DEBUG to szczegółowe wiadomości, które są przydatne do wyśledzenia problemu (ang. debugging), ale zazwyczaj tworzą zbyt duży szum informacyjny, żeby były włączone na co dzień.

W serwach aplikacji z rodziny EuroAP możemy korzystać z aż 14 poziomów logowania: ALL, FINEST, FINER, TRACE, DEBUG, FINE, CONFIG, INFO, WARN, WARNING, ERROR, SEVERE, FATAL, OFF. ALL oznacza, że chcemy przyjmować wszystkie wysyłane wiadomości, a OFF – żadnych.

Formater

Formater służy do formatowania pojedynczej wiadomości w logu. Definiuje, w jakiej postaci dana wiadomość zostanie do logu zapisana. W serwerze aplikacji EuroAP formater możemy nazwać i reużywać go między kilkoma handlerami za pomocą właściwości Named Formatter. Możemy go też nie nazywać i w handlerze używać anonimowego formatera zdefiniowanego we właściwości Formatter. Formatery możemy definiować w graficznej konsoli:

Możemy wybrać spośród 4 typów formaterów:

  • pattern formatter – formatuje zwykły tekst zgodnie ze swoją składnią
  • JSON formatter – zapisuje wiadomości jako JSON
  • XML formatter – zapisuje wiadomości jako XML
  • custom formatter – pozwala podłączyć swoją własną implementację formatera.

Pattern Formatter

Pattern Formatter, który można przetłumaczyć jako formater według wzorca, zapisuje logi zgodnie z wprowadzonym wzorcem.

Najczęściej używane elementy składni:

  • %c – kategoria eventu logowania
  • %p – poziom logowania
  • %d – obecna data w formacie yyyy-MM-dd HH:mm:ss,SSS
  • %r – czas relatywny – milisekundy odkąd serwer rozpoczął swoją pracę
  • %s – prosta wiadomość logu, nie zawiera stosu wyjątku
  • %m – wiadomość logu, może zawierać stos wyjątku
  • %e – stos wyjątku
  • %E – stos wyjątku z dodatkowymi informacjami o module
  • %t – nazwa bieżącego wątku
  • %n – nowa linia.

Przykładowo wzorce dają nam odpowiednio sformatowane wiadomości:

%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n 23:24:27,976 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: EuroAP 7.3.4.GA (WildFly Core 10.1.15.Final-redhat-00001) started in 4660ms - Started 306 of 560 services (355 services are lazy, passive or on-demand)
%d %-5p [%c] (%t) %s%e%n 2021-03-01 23:32:15,424 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: EuroAP 7.3.4.GA (WildFly Core 10.1.15.Final-redhat-00001) started in 2528ms - Started 306 of 560 services (355 services are lazy, passive or on-demand)
%r %p [%c] (%t) %m%e%n 212 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: EuroAP 7.3.4.GA (WildFly Core 10.1.15.Final-redhat-00001) started in 2566ms - Started 306 of 560 services (355 services are lazy, passive or on-demand)

Podsumowanie

Przez graficzną konsolę administratora możemy zobaczyć zwirtualizowaną konfigurację podsystemu logowania. Możemy także wyklikać tam całą konieczną konfigurację.

Zobaczyliśmy dziś, że podsystem logowania ma domyślnie skonfigurowany jeden podstawowy loger – root logger, do którego podpięte są dwa handlery – jeden wypisujący dane na konsolę i drugi zapisujący do pliku server.log. Wytłumaczyliśmy także, czym są handlery, poziomy logowania, formatery. W kolejnej części serii o logowaniu w serwerach aplikacji z rodziny EuroAP przedstawimy, czym są kategorie oraz specyfikacje filtrów. Skupimy się również na konfiguracji przez CLI.

Autorzy

Artykuły na blogu są pisane przez osoby z zespołu EuroLinux. 80% treści zawdzięczamy naszym developerom, pozostałą część przygotowuje dział sprzedaży lub marketingu. Dokładamy starań, żeby treści były jak najlepsze merytorycznie i językowo, ale nie jesteśmy nieomylni. Jeśli zauważysz coś wartego poprawienia lub wyjaśnienia, będziemy wdzięczni za wiadomość.