Health checki i gotowość aplikacji
Odróżnisz działający proces od gotowej usługi i sprawdzisz endpoint /health z limitem czasu.
1. Krótka teoria
Aktywny proces systemd nie gwarantuje, że aplikacja odpowiada na żądania. Health check wykonuje konkretne sprawdzenie, na przykład żądanie do /health, i ocenia kod HTTP oraz czas odpowiedzi. Liveness odpowiada na pytanie, czy proces nadal działa poprawnie i wymaga ewentualnego restartu. Readiness mówi, czy instancja może przyjmować ruch; może uwzględniać połączenie z bazą, ale nie powinna wykonywać kosztownych operacji. Brak gotowości nie zawsze oznacza konieczność restartu. Zależności mogą być chwilowo niedostępne, dlatego wynik trzeba interpretować razem z logami i stanem bazy. Kod 200 zwykle oznacza pozytywny wynik, a 503 brak gotowości. Sama strona główna 200 nie dowodzi działania ważnych funkcji. Ustaw krótki timeout, aby zawieszony endpoint nie blokował sprawdzania. Ograniczona liczba ponowień zmniejsza wpływ pojedynczego błędu sieci, lecz nie może ukrywać długiej awarii. Endpoint nie powinien ujawniać sekretów ani szczegółów infrastruktury.
2. Przykłady komend
systemctl status orders-api --no-pager
Sprawdza stan procesu, ale nie zastępuje testu HTTP.
$ systemctl status orders-api --no-pager
curl -sS -o /dev/null -w '%{http_code}
' http://127.0.0.1:8000/health
Odczytuje kod odpowiedzi endpointu zdrowia.
$ curl -sS -o /dev/null -w '%{http_code}
' http://127.0.0.1:8000/health
200
curl --fail --max-time 2 http://127.0.0.1:8000/health
Zwraca błąd dla niepowodzenia HTTP i ogranicza czas oczekiwania.
$ curl --fail --max-time 2 http://127.0.0.1:8000/health
curl --fail --max-time 2 --retry 2 --retry-delay 1 http://127.0.0.1:8000/health
Ponawia krótkotrwały błąd najwyżej dwa razy.
$ curl --fail --max-time 2 --retry 2 --retry-delay 1 http://127.0.0.1:8000/health
journalctl -u orders-api -n 30 --no-pager
Łączy wynik health checku z ostatnimi logami usługi.
$ journalctl -u orders-api -n 30 --no-pager
ss -lntp | grep ':8000'
Sprawdza nasłuch portu aplikacji.
$ ss -lntp | grep ':8000'3. Zadanie praktyczne
orders-api przygotuj kontrakt /health: kod 200, gdy instancja może obsługiwać ruch, i 503 przy braku krytycznej zależności. Opisz osobno prosty test liveness i readiness. Sprawdź proces, port oraz żądanie HTTP z timeoutem. Zasymuluj niedostępność testowej bazy i zapisz, dlaczego aktywny systemd nie wystarcza do uznania usługi za gotową.
4. Typowe błędy
- Traktowanie systemctl active jako dowodu poprawnej odpowiedzi aplikacji.
- Łączenie liveness z każdą chwilową awarią zależności i wywoływanie pętli restartów.
- Brak timeoutu, przez co sprawdzenie może się zawiesić.
- Nieograniczone ponawianie, które opóźnia wykrycie trwałej awarii.
- Zwracanie haseł lub szczegółów połączenia w publicznym endpointcie.
5. Podsumowanie
Health check ocenia zachowanie aplikacji, a nie tylko jej proces. Liveness pomaga wykryć instancję wymagającą restartu, readiness określa gotowość do ruchu. Kod HTTP, timeout i ograniczone ponowienia tworzą użyteczny sygnał do monitoringu.