Logi usług i aplikacji
Wyfiltrujesz zdarzenia z journalu i logów aplikacji, zachowując czas, kontekst i prywatność.
1. Krótka teoria
Log usługi powinien odpowiadać na pytania: kiedy, w którym komponencie, na jakim poziomie i co się stało. journalctl -u orders-api filtruje jednostkę systemd, -n ogranicza liczbę wpisów, --since wybiera okno czasu, a -p filtruje priorytet. Poziom warning nie oznacza automatycznie awarii, a brak error nie dowodzi poprawności działania. Znacznik czasu ma znaczenie przy łączeniu logów aplikacji, Nginxa i kontenera bazy. Aplikacja może pisać na stdout, który przejmuje systemd lub runtime kontenera. Ustrukturyzowany log to zestaw pól, na przykład time, level, service i request_id; ułatwia filtrowanie, ale nie wymaga wdrożenia nowej platformy logowej. Identyfikator żądania pomaga skleić zdarzenia z kilku komponentów. tail i grep przydają się dla zwykłych plików. Logi mogą zawierać dane wrażliwe; nie zapisuj haseł i pełnych tokenów. Retencja i rotacja ograniczają rozmiar magazynu, a usuwanie logów podczas incydentu bez kopii utrudnia dochodzenie.
2. Przykłady komend
journalctl -u orders-api -n 50 --no-pager
Czyta ostatnie wpisy jednostki.
$ journalctl -u orders-api -n 50 --no-pager
journalctl -u orders-api --since '2026-09-18 14:00:00' --until '2026-09-18 14:15:00' --no-pager
Zawęża logi do czasu incydentu.
$ journalctl -u orders-api --since '2026-09-18 14:00:00' --until '2026-09-18 14:15:00' --no-pager
journalctl -u orders-api -p warning --since '1 hour ago' --no-pager
Pokazuje wpisy od poziomu warning wzwyż w ostatniej godzinie.
$ journalctl -u orders-api -p warning --since '1 hour ago' --no-pager
journalctl -u orders-api -o json --since '10 minutes ago' --no-pager
Wyświetla wpisy journalu jako rekordy JSON.
$ journalctl -u orders-api -o json --since '10 minutes ago' --no-pager
tail -n 50 /var/log/nginx/error.log
Czyta końcówkę logu błędów proxy.
$ tail -n 50 /var/log/nginx/error.log
grep 'request_id=ord-42' /var/log/orders-api/app.log
Wyszukuje zdarzenia jednego żądania, jeśli aplikacja zapisuje to pole.
$ grep 'request_id=ord-42' /var/log/orders-api/app.log
journalctl --disk-usage
Sprawdza miejsce zajmowane przez journal przed zmianą retencji.
$ journalctl --disk-usage3. Zadanie praktyczne
orders-api w przedziale 14:00–14:15 zbierz wpisy jednostki oraz końcówkę logu Nginxa. Oddziel ostrzeżenia od błędów, sprawdź strefę czasu i wyszukaj ćwiczeniowy request_id=ord-42, jeśli jest zapisywany. Zaprojektuj jedną krótką linię logu z polami time, level, service, request_id i message bez sekretów. Sprawdź rozmiar journalu i zaproponuj rozsądną retencję bez kasowania dowodów.
4. Typowe błędy
- Czytanie wszystkich logów bez ograniczenia czasu i usługi.
- Zakładanie, że każdy warning oznacza awarię użytkownika.
- Mieszanie czasów z różnych stref podczas budowania osi incydentu.
- Logowanie haseł, tokenów i pełnych danych klientów.
- Usuwanie logów przed zapisaniem materiału potrzebnego do diagnozy.
5. Podsumowanie
Filtruj logi po usłudze, czasie i priorytecie, a zdarzenia łącz przez request ID. Ustrukturyzowane pola ułatwiają diagnostykę. Retencję dobieraj świadomie, chroniąc zarówno przestrzeń dyskową, jak i dane wrażliwe.