Obserwowalność: logi, metryki i ślady
Dobierzesz log, metrykę lub ślad do pytania diagnostycznego i połączysz je w jedną oś czasu.
1. Krótka teoria
Obserwowalność pomaga wywnioskować stan systemu z jego sygnałów. Log opisuje konkretne zdarzenie z czasem i kontekstem, metryka liczy lub mierzy zjawisko w czasie, a ślad pokazuje drogę pojedynczego żądania przez komponenty. Gdy rośnie liczba błędów HTTP, metryka pokazuje skalę i początek problemu; log wskazuje komunikat błędu; ślad może pokazać, że większość czasu zajęło zapytanie do app-db. Nie trzeba wdrażać pełnego systemu distributed tracing, aby zrozumieć tę różnicę. Przydatny jest wspólny czas, nazwa usługi, identyfikator żądania i wersja aplikacji. Bez zgodnych znaczników czasu łatwo połączyć niepowiązane zdarzenia. Najpierw określ pytanie: czy problem dotyczy wielu żądań, konkretnego użytkownika czy jednego zależnego serwisu. Potem wybierz sygnał. Nie zapisuj w logach tokenów, haseł ani danych osobowych. Kontroluj dostęp i retencję sygnałów, ponieważ także metadane diagnostyczne mogą być wrażliwe.
2. Przykłady komend
date --iso-8601=seconds
Zapisuje czas rozpoczęcia obserwacji z informacją o strefie.
$ date --iso-8601=seconds
curl -sS -o /dev/null -w '%{http_code} %{time_total}
' http://127.0.0.1:8000/health
Zbiera prosty wynik HTTP i czas żądania.
$ curl -sS -o /dev/null -w '%{http_code} %{time_total}
' http://127.0.0.1:8000/health
journalctl -u orders-api --since '10 minutes ago' --no-pager
Czyta zdarzenia usługi z tego samego okna czasu.
$ journalctl -u orders-api --since '10 minutes ago' --no-pager
docker compose logs --since 10m app-db
Porównuje logi kontenera bazy z logami aplikacji.
$ docker compose logs --since 10m app-db
grep 'orders-api' /var/log/nginx/error.log | tail -n 20
Szukając błędów proxy, łączy obserwacje z warstwy HTTP.
$ grep 'orders-api' /var/log/nginx/error.log | tail -n 20
systemctl status orders-api --no-pager
Dodaje stan procesu do pozostałych sygnałów.
$ systemctl status orders-api --no-pager3. Zadanie praktyczne
orders-api zaczyna odpowiadać wolno po 14:00. Utwórz oś czasu z odczytu czasu HTTP, liczby błędów w krótkim oknie i logów aplikacji oraz app-db. Dla każdego sygnału zapisz, na jakie pytanie odpowiada. Zaproponuj identyfikator żądania, który łączyłby zdarzenia z kilku usług, bez logowania danych klienta.
4. Typowe błędy
- Wyciąganie wniosku o skali awarii z pojedynczego logu.
- Interpretowanie średniego czasu żądania jako przebiegu konkretnego requestu.
- Porównywanie logów bez kontroli strefy czasu i okna zdarzenia.
- Zapisywanie sekretów w danych diagnostycznych.
- Uruchamianie skomplikowanego tracingu bez jasnego pytania operacyjnego.
5. Podsumowanie
Metryki pokazują skalę i trend, logi szczegóły zdarzeń, a ślady przebieg wybranego żądania. Wspólny czas, usługa i identyfikator pozwalają połączyć sygnały w diagnozę bez ujawniania poufnych danych.