Twoja aplikacja zatrzymała się. Znajdź pierwszą przydatną wskazówkę.

Zdefiniuj jedną obserwowalną awarię

„Zatrzymane” może oznaczać błąd HTTP, przekroczenie limitu czasu, zadanie, które się nie zakończyło, albo proces, który zakończył działanie. Zapisz jeden adres URL lub działanie, czas ostatniego znanego działania, czas pierwszej awarii i swoją strefę czasową. Uwzględnij, czy problem dotyczy wszystkich, czy tylko jednego klienta. Podczas badania pozostaw otwartą bieżącą sesję SSH; zmiana reguł dostępu nie jest konieczną pierwszą reakcją na błąd aplikacji.

Ten przewodnik zakłada hosta Linux używającego systemd, usługę aplikacji o nazwie first-api.service, oraz lokalny punkt końcowy kondycji pod adresem 127.0.0.1:3000/healthz. Te wartości domyślne odpowiadają przewodnikowi po pierwszym wdrożeniu API. Zastąp je swoimi rzeczywistymi nazwami. Kontrola może wymagać uprawnień administratora, aby zobaczyć procesy lub dzienniki innych użytkowników. Poniższe polecenia i wyniki mają charakter poglądowy; na potrzeby tego przewodnika nie testowano żadnej instancji dostawcy.

Prowadź notatki poza katalogiem samej zawodnej aplikacji. Zapisuj obserwacje przed interpretacjami: „odmowa połączenia o 09:18 UTC” to fakt; „VPS potrzebuje więcej CPU” to wciąż hipoteza. Jeśli sam serwer jest nieosiągalny, użyj ustalonego dostępu odzyskiwania i zbierz szczegóły połączenia, zamiast zakładać, że ponowne uruchomienie aplikacji jest możliwe.

Odczytaj stan procesu i jego niedawną historię

systemctl status first-api.service --no-pager --full
systemctl show first-api.service -p ActiveState -p SubState -p Result -p ExecMainStatus -p NRestarts

Widok statusu opisuje bieżące lub ostatnie wywołanie i zawiera ostatnie komunikaty dziennika. Wybrane właściwości dają zwięzły zapis do późniejszego porównania. Stan niepowodzenia lub rosnąca liczba restartów wymaga zbadania; aktywny proces nadal wymaga testu żądania. To różne kontrole, zgodnie z opisem w referencyjnej dokumentacji systemctl.

Jeśli jednostka nie istnieje, najpierw zweryfikuj jej nazwę i metodę wdrożenia. Aplikacja uruchomiona w interaktywnym terminalu, kontener i usługa systemd mają różnych właścicieli i dzienniki. Natychmiastowe utworzenie nowej usługi mogłoby pozostawić dwie kopie konkurujące o ten sam port. Zidentyfikuj istniejący układ, zanim go zmienisz.

Sprawdź nasłuch i wykonaj lokalne żądanie

sudo ss -ltnp
curl --silent --show-error --max-time 5 http://127.0.0.1:3000/healthz

Poszukaj oczekiwanego adresu i portu, a następnie zidentyfikuj proces będący ich właścicielem. Proces nasłuchujący na innym porcie może być zdrowy, ale nieosiągalny przez skonfigurowane proxy. Inny proces mógł zająć oczekiwany port. podręcznik ss definiuje opcje nasłuchu i procesu.

Jeśli lokalne żądanie działa, a publiczne żądanie HTTPS kończy się niepowodzeniem, kontynuuj przez kontrole DNS, TLS i proxy. Jeśli nasłuch nie istnieje, zbadaj niepowodzenie uruchamiania. Jeśli połączenie się powiedzie, ale aplikacja zwraca błąd, zbadaj tę trasę i jej zależności. Curl bez --fail może zakończyć się powodzeniem dla odpowiedzi błędu HTTP, więc czytaj odpowiedź, zamiast polegać wyłącznie na jej kodzie wyjścia. Zobacz opcje odpowiedzi i błędów curl.

Czytaj wokół pierwszej awarii, nie tylko ostatnią linię

sudo journalctl -u first-api.service --since "30 minutes ago" --no-pager -n 100
sudo journalctl -k --since "30 minutes ago" --no-pager -n 100

Pierwsze zapytanie wybiera usługę; drugie wybiera komunikaty jądra. Dostosuj interwał, aby objąć ostatnie działające żądanie i zmianę poprzedzającą awarię. Dostęp i retencja określają, co pozostaje dostępne. referencyjna dokumentacja journalctl wyjaśnia filtry jednostek, czasu i jądra. Zredaguj tokeny, dane klientów i ciągi połączeń przed udostępnieniem fragmentów.

Przykładowy fragment z osobnej aplikacji z funkcją przesyłania:

09:18:03 field-api: opening upload directory
09:18:03 field-api: EACCES: permission denied, open '/var/lib/field-api/uploads/index.json'
09:18:03 field-api: startup aborted

To wskazuje na dostęp użytkownika usługi do określonej ścieżki. Sprawdź własność pliku i katalogu nadrzędnego zgodnie z instrukcjami wydania. Nie przyznawaj szerokiego dostępu do zapisu całemu systemowi plików. Późniejszy komunikat proxy „upstream unavailable” byłby w tym scenariuszu konsekwencją, więc naprawa proxy w pierwszej kolejności pominęłaby przyczynę.

Porównaj zasoby z najnowszym wydaniem

free -h
df -h / /opt/first-api
df -i / /opt/first-api

Te migawki pomagają zapytać, czy presja pamięci, miejsce w systemie plików lub wyczerpanie i-węzłów zbiegły się z awarią. Ich interpretacja należy do przewodnika po pamięci i dysku; pojedynczy odczyt zajętości nie ustala przyczyny. Usługa może również osiągnąć własny limit zasobów, gdy reszta hosta ma jeszcze zapas.

Porównaj wdrożony identyfikator wydania, polecenie uruchomienia, wymagane nazwy zmiennych środowiskowych i ścieżki danych z ostatnim działającym wydaniem. Nie zrzucaj tajnych wartości środowiskowych do raportu. Szukaj zmienionego katalogu, brakującej zależności środowiska uruchomieniowego, zmiany portu lub niezgodnej migracji bazy danych. Podaj, co się zmieniło i czego błąd pozwala oczekiwać.

Wprowadź jedną uzasadnioną poprawkę i zweryfikuj odzyskanie

Wybierz najmniejszą poprawkę popartą dowodami. Dla przykładowego błędu uprawnień oznacza to przywrócenie zamierzonego dostępu dla konta usługi, a następnie jedną kontrolowaną próbę uruchomienia. Jeśli zamiast tego użyjesz znanego działającego wydania kodu, najpierw ustal, czy jego schemat bazy danych pozostaje zgodny. Wycofanie kodu nie może automatycznie odwrócić migracji danych.

Po poprawce powtórz te same kontrole usługi, lokalnego punktu końcowego i publicznego żądania. Potwierdź, że reprezentatywna akcja aplikacji działa, że nowe błędy ustały i że proces pozostaje stabilny przez następne normalne obciążenie. Zasady restartu mogą pomóc odzyskać proces, ale nie czynią trwale zepsutego programu zdrowym; skonsultuj referencję usługi systemd w sprawie rzeczywistej zasady.

Zakończ notatkę incydentu objawem, pierwszą użyteczną wskazówką, wprowadzoną zmianą i wynikiem weryfikacji. Jeśli przyczyna pozostaje niepewna, zgłoś tę niepewność wraz z zredagowanymi dowodami, zamiast nazywać tymczasowy restart trwałą naprawą. Ulepsz listę kontrolną wydania o kontrolę, która wcześniej wykryłaby tę awarię.