Monitoring aplikacji i zależności
Zbudujesz prostą tablicę stanu usługi z sygnałów aplikacji, hosta i zależnej bazy.
1. Krótka teoria
Monitoring odpowiada na pytanie, czy usługa działa dla użytkownika i co ogranicza jej pracę. Dostępność endpointu to tylko jeden wymiar. Obserwuj ruch żądań, odsetek błędów, opóźnienie oraz nasycenie zasobów. Wzrost ruchu bez wzrostu błędów może być normalny, ale ten sam ruch przy wyczerpanej puli połączeń wskazuje ryzyko. Metryki hosta, takie jak CPU, pamięć, dysk i sieć, opisują maszynę. Metryki aplikacji opisują jej żądania, kolejki i połączenia. Niski CPU hosta nie wyklucza awarii orders-api. Zależna baza app-db potrzebuje własnego sygnału gotowości i czasu odpowiedzi. W prostym laboratorium wystarczą curl, uptime, free i df. W większym środowisku Prometheus może zbierać metryki, a Grafana je wizualizować; tutaj są przykładami narzędzi, nie częścią runtime ShellForge. Dashboard powinien pokazywać czas, jednostki i źródło danych. Brak próbki może oznaczać awarię monitoringu, a nie poprawny stan usługi.
2. Przykłady komend
curl -sS -o /dev/null -w '%{http_code} %{time_total}
' http://127.0.0.1:8000/health
Zbiera wynik i czas jednego żądania do aplikacji.
$ curl -sS -o /dev/null -w '%{http_code} %{time_total}
' http://127.0.0.1:8000/health
uptime
Pokazuje czas pracy hosta i średnie obciążenie.
$ uptime
free -h
Sprawdza pamięć hosta w czytelnych jednostkach.
$ free -h
df -h /
Sprawdza wolne miejsce na systemie plików hosta.
$ df -h /
ss -s
Pokazuje zbiorczy stan połączeń sieciowych.
$ ss -s
docker compose exec app-db pg_isready -U orders -d orders
Kontroluje gotowość zależnej bazy w ćwiczeniowym Compose.
$ docker compose exec app-db pg_isready -U orders -d orders
docker compose ps
Pokazuje stan usług aplikacji i bazy w projekcie.
$ docker compose ps3. Zadanie praktyczne
orders-api przygotuj prostą tablicę z pięcioma polami: dostępność, ruch, czas odpowiedzi, błędy i nasycenie. Obok wpisz stan app-db oraz CPU, pamięć i dysk hosta. Dla dwóch scenariuszy — baza nie odpowiada i dysk prawie pełny — wskaż, które pola zmienią się najpierw i jaki test potwierdzi przypuszczenie. Nie uznawaj braku danych monitoringu za dowód zdrowia aplikacji.
4. Typowe błędy
- Uznawanie poprawnego uptime hosta za dowód działania aplikacji.
- Ignorowanie zależnej bazy podczas diagnozy błędów aplikacji.
- Mieszanie jednostek czasu odpowiedzi, na przykład sekund i milisekund.
- Odczytywanie braku danych jako zera błędów.
- Budowanie dashboardu bez okna czasu i źródła sygnału.
5. Podsumowanie
Monitoruj objawy widoczne dla użytkownika oraz zasoby hosta i zależności. Ruch, błędy, opóźnienie i nasycenie dają szerszy obraz niż sam uptime. Prometheus i Grafana są przykładami zbierania i prezentacji tych sygnałów.