Ihre App ist gestoppt. Finden Sie den ersten nützlichen Hinweis.

Definieren Sie einen beobachtbaren Fehler

„Gestoppt“ kann einen HTTP-Fehler, eine Zeitüberschreitung, einen nicht abgeschlossenen Job oder einen beendeten Prozess bedeuten. Notieren Sie eine URL oder Aktion, ihre letzte bekannte funktionierende Zeit, die erste Fehlerzeit und Ihre Zeitzone. Geben Sie an, ob alle betroffen sind oder nur ein Client. Halten Sie die aktuelle SSH-Sitzung während der Untersuchung offen; das Ändern von Zugriffsregeln ist keine notwendige erste Reaktion auf einen Anwendungsfehler.

Dieser Leitfaden setzt einen Linux-Host mit systemd, einen Anwendungsdienst namens first-api.service, und einen lokalen Health-Endpunkt unter 127.0.0.1:3000/healthz. Diese Standardwerte entsprechen dem ersten API-Bereitstellungsleitfaden. Ersetzen Sie sie durch Ihre tatsächlichen Namen. Die Untersuchung kann Administratorrechte erfordern, um Prozesse oder Protokolle anderer Benutzer zu sehen. Befehle und Ausgaben unten sind beispielhaft; für diesen Leitfaden wurde keine Anbieterinstanz getestet.

Bewahren Sie Notizen außerhalb des Verzeichnisses der fehlerhaften App auf. Zeichnen Sie Beobachtungen vor Interpretationen auf: „connection refused um 09:18 UTC“ ist eine Tatsache; „der VPS braucht mehr CPU“ ist noch eine Hypothese. Wenn der Server selbst nicht erreichbar ist, verwenden Sie Ihren etablierten Wiederherstellungszugang und sammeln Sie Verbindungsdetails, anstatt anzunehmen, dass ein App-Neustart möglich ist.

Lesen Sie den Prozessstatus und seine jüngste Historie

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

Die Statusansicht beschreibt den aktuellen oder letzten Aufruf und enthält aktuelle Journalmeldungen. Die ausgewählten Eigenschaften liefern einen kompakten Datensatz zum späteren Vergleich. Ein fehlerhafter Zustand oder eine steigende Neustartanzahl verdienen eine Untersuchung; ein aktiver Prozess benötigt dennoch einen Anfragetest. Dies sind unterschiedliche Prüfungen, wie beschrieben in der upstream systemctl-Referenz.

Wenn die Unit fehlt, überprüfen Sie zunächst ihren Namen und die Bereitstellungsmethode. Eine in einem interaktiven Terminal gestartete App, ein Container und ein systemd-Dienst haben unterschiedliche Eigentümer und Logs. Das sofortige Erstellen eines neuen Dienstes könnte zwei Kopien zurücklassen, die um denselben Port konkurrieren. Identifizieren Sie die bestehende Anordnung, bevor Sie sie ändern.

Prüfen Sie den Listener und führen Sie eine lokale Anfrage aus

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

Suchen Sie nach der erwarteten Adresse und dem Port und identifizieren Sie dann den zugehörigen Prozess. Ein Prozess, der auf einem anderen Port lauscht, kann gesund sein, aber vom konfigurierten Proxy nicht erreicht werden. Ein anderer Prozess hat möglicherweise den erwarteten Port belegt. Das ss-Handbuch definiert die Listener- und Prozessoptionen.

Wenn die lokale Anfrage funktioniert und die öffentliche HTTPS-Anfrage fehlschlägt, fahren Sie fort mit DNS-, TLS- und Proxy-Prüfungen. Wenn der Listener fehlt, untersuchen Sie den Startfehler. Wenn die Verbindung erfolgreich ist, aber die App einen Fehler zurückgibt, untersuchen Sie diese Route und ihre Abhängigkeiten. Curl ohne --fail kann bei einer HTTP-Fehlerantwort erfolgreich abschließen, lesen Sie daher die Antwort, anstatt sich nur auf ihren Exit-Code zu verlassen. Siehe CurLs Antwort- und Fehleroptionen.

Lesen Sie um den ersten Fehler herum, nicht nur die letzte Zeile

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

Die erste Abfrage wählt den Dienst aus; die zweite wählt Kernelmeldungen aus. Passen Sie das Intervall an, um die letzte funktionierende Anfrage und die Änderung vor dem Ausfall einzuschließen. Zugriff und Aufbewahrung bestimmen, was verfügbar bleibt. Die upstream journalctl-Referenz erklärt Unit-, Zeit- und Kernel-Filter. Schwärzen Sie Tokens, Kundendaten und Verbindungszeichenfolgen, bevor Sie Auszüge teilen.

Illustrativer Auszug aus einer separaten App mit Upload-Funktion:

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

Dies deutet auf den Zugriff des Dienstbenutzers auf einen bestimmten Pfad hin. Prüfen Sie den Datei- und übergeordneten Verzeichnisbesitz gegen die Release-Anweisungen. Gewähren Sie keinen breiten Schreibzugriff auf das gesamte Dateisystem. Eine spätere Proxy-Meldung „upstream unavailable“ wäre in diesem Szenario eine Folge, sodass die Reparatur des Proxys zuerst die Ursache verfehlen würde.

Vergleichen Sie Ressourcen mit dem neuesten Release

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

Diese Momentaufnahmen helfen Ihnen zu klären, ob Speicherdruck, Dateisystemplatz oder Inode-Erschöpfung mit dem Ausfall zusammenfielen. Ihre Interpretation gehört in den Speicher- und Festplattenleitfaden; ein einzelner hoher Messwert belegt nicht die Ursache. Ein Dienst kann auch sein eigenes Ressourcenlimit erreichen, während der Rest des Hosts Kapazität hat.

Vergleichen Sie die bereitgestellte Release-Kennung, den Startbefehl, die erforderlichen Umgebungsvariablennamen und Datenpfade mit dem letzten funktionierenden Release. Geben Sie keine geheimen Umgebungswerte in einen Bericht aus. Suchen Sie nach einem umbenannten Verzeichnis, einer fehlenden Laufzeitabhängigkeit, einer Portänderung oder einer inkompatiblen Datenbankmigration. Geben Sie an, was sich geändert hat und was der Fehler erwarten lässt, das Sie finden sollten.

Nehmen Sie eine begründete Korrektur vor und überprüfen Sie die Wiederherstellung

Wählen Sie die kleinste durch die Beweise gestützte Korrektur. Für den illustrativen Berechtigungsfehler bedeutet das, den beabsichtigten Zugriff für das Dienstkonto wiederherzustellen und dann einen kontrollierten Startversuch zu unternehmen. Wenn Sie stattdessen ein bekanntermaßen funktionierendes Code-Release verwenden, stellen Sie zuerst fest, ob dessen Datenbankschema kompatibel bleibt. Ein Code-Rollback kann eine Datenmigration nicht automatisch rückgängig machen.

Wiederholen Sie nach der Korrektur dieselben Dienst-, lokalen Endpunkt- und öffentlichen Anfrageprüfungen. Bestätigen Sie, dass eine repräsentative Anwendungsaktion funktioniert, dass neue Fehler aufgehört haben und dass der Prozess durch die nächste normale Arbeitslast stabil bleibt. Neustartrichtlinien können helfen, einen Prozess wiederherzustellen, machen aber ein dauerhaft defektes Programm nicht gesund; konsultieren Sie die systemd-Dienstreferenz für die tatsächliche Richtlinie.

Schließen Sie Ihre Vorfallnotiz mit dem Symptom, dem ersten nützlichen Hinweis, der vorgenommenen Änderung und dem Verifikationsergebnis ab. Wenn die Ursache ungewiss bleibt, melden Sie diese Unsicherheit mit geschwärzten Beweisen, anstatt einen vorübergehenden Neustart als dauerhafte Lösung zu kennzeichnen. Verbessern Sie die Release-Checkliste mit der Prüfung, die diesen Fehler früher erkannt hätte.