Aplicația ta s-a oprit. Găsește primul indiciu util.

Definește o singură defecțiune observabilă

„Oprit” poate însemna o eroare HTTP, un timeout, o sarcină care nu s-a terminat sau un proces care s-a încheiat. Notează un URL sau o acțiune, ultima dată cunoscută de funcționare, prima oră a defecțiunii și fusul tău orar. Include dacă toată lumea este afectată sau doar un singur client. Ține sesiunea SSH curentă deschisă în timpul investigării; schimbarea regulilor de acces nu este un prim răspuns necesar la o eroare de aplicație.

Acest ghid presupune o gazdă Linux folosind systemd, un serviciu de aplicație numit first-api.service, și un endpoint local de sănătate la 127.0.0.1:3000/healthz. Aceste valori implicite corespund primului ghid de implementare API. Înlocuiește cu numele tale reale. Inspecția poate necesita permisiuni de administrator pentru a vedea procesele sau jurnalele altor utilizatori. Comenzile și rezultatele de mai jos sunt ilustrative; nicio instanță de furnizor nu a fost testată pentru acest ghid.

Ține notițele în afara directorului aplicației defecte. Notează observațiile înainte de interpretări: „conexiune refuzată la 09:18 UTC” este un fapt; „VPS-ul are nevoie de mai mult CPU” este încă o ipoteză. Dacă serverul însuși este inaccesibil, folosește accesul de recuperare stabilit și colectează detaliile conexiunii în loc să presupui că o repornire a aplicației este posibilă.

Citește starea procesului și istoricul său recent

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

Vizualizarea stării descrie invocarea curentă sau cea mai recentă și include mesaje recente din jurnal. Proprietățile selectate vă oferă o înregistrare compactă pentru comparații ulterioare. O stare de eșec sau un număr de reporniri în creștere merită investigat; un proces activ necesită totuși un test de cerere. Acestea sunt verificări diferite, după cum se descrie în referința upstream systemctl.

Dacă unitatea lipsește, verificați mai întâi numele acesteia și metoda de implementare. O aplicație pornită într-un terminal interactiv, un container și un serviciu systemd au proprietari și jurnale diferite. Crearea imediată a unui serviciu nou ar putea lăsa două copii concurând pentru același port. Identificați aranjamentul existent înainte de a-l modifica.

Verifică listenerul și fă o cerere locală

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

Căutați adresa și portul așteptate, apoi identificați procesul proprietar. Un proces care ascultă pe alt port poate fi sănătos, dar inaccesibil prin proxy-ul configurat. Un proces diferit poate fi revendicat portul așteptat. manualul ss definește opțiunile pentru listener și proces.

Dacă cererea locală funcționează și cererea publică HTTPS eșuează, continuați prin verificările DNS, TLS și proxy. Dacă listener-ul este absent, examinați eșecul la pornire. Dacă conexiunea reușește, dar aplicația returnează o eroare, investigați acea rută și dependențele ei. Curl fără --fail poate finaliza cu succes pentru un răspuns de eroare HTTP, așa că citiți răspunsul în loc să vă bazați doar pe codul de ieșire. Consultați opțiunile de răspuns și eșec ale curl.

Citește în jurul primei defecțiuni, nu doar ultima linie

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

Prima interogare selectează serviciul; a doua selectează mesajele kernelului. Ajustați intervalul pentru a include ultima cerere funcțională și schimbarea care a precedat întreruperea. Accesul și retenția determină ce rămâne disponibil. referința upstream journalctl explică filtrele de unitate, timp și kernel. Anonimizați tokenurile, datele clienților și șirurile de conexiune înainte de a partaja extrase.

Extras ilustrativ dintr-o aplicație separată cu funcție de încărcare:

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

Aceasta indică accesul utilizatorului serviciului la o cale specifică. Verificați proprietatea fișierului și a directorului părinte conform instrucțiunilor de lansare. Nu acordați acces larg de scriere pentru întregul sistem de fișiere. Un mesaj ulterior de „upstream indisponibil” din proxy ar fi o consecință în acest scenariu, deci repararea mai întâi a proxy-ului ar rata cauza.

Compară resursele cu versiunea cea mai recentă

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

Aceste instantanee vă ajută să întrebați dacă presiunea pe memorie, spațiul pe sistemul de fișiere sau epuizarea inode-urilor au coincis cu defecțiunea. Interpretarea lor aparține în ghidul de memorie și disc; o singură citire ridicată nu stabilește cauza. Un serviciu poate de asemenea atinge propria limită de resurse în timp ce restul gazdei are capacitate.

Comparați identificatorul versiunii implementate, comanda de pornire, numele variabilelor de mediu necesare și căile de date cu ultima versiune funcțională. Nu includeți valori secrete de mediu într-un raport. Căutați un director redenumit, o dependență de runtime lipsă, o schimbare de port sau o migrare incompatibilă a bazei de date. Menționați ce s-a schimbat și ce prevede eroarea că ar trebui să găsiți.

Fă o singură corectare justificată și verifică recuperarea

Alegeți cea mai mică corecție susținută de dovezi. Pentru eșecul ilustrativ de permisiuni, aceasta înseamnă restabilirea accesului intenționat pentru contul serviciului, apoi o singură încercare controlată de pornire. Dacă folosiți în schimb o versiune de cod cunoscută ca funcțională, stabiliți mai întâi dacă schema sa de bază de date rămâne compatibilă. O revenire la versiunea anterioară a codului nu poate inversa automat o migrare a datelor.

După corecție, repetați aceleași verificări pentru serviciu, endpoint local și cerere publică. Confirmați că o acțiune reprezentativă a aplicației funcționează, că noile erori s-au oprit și că procesul rămâne stabil pe parcursul următoarei sarcini normale. Politicile de repornire pot ajuta la recuperarea unui proces, dar nu fac sănătos un program defectuos persistent; consultați referința serviciului systemd pentru politica reală.

Încheiați nota de incident cu simptomul, primul indiciu util, modificarea făcută și rezultatul verificării. Dacă cauza rămâne incertă, raportați acea incertitudine cu dovezi anonimizate, în loc să etichetați o repornire temporară drept soluție permanentă. Îmbunătățiți lista de verificare a lansării cu verificarea care ar fi prins această defecțiune mai devreme.