Je app is gestopt. Vind de eerste nuttige aanwijzing.

Definieer één waarneembare fout

“Gestopt” kan een HTTP-fout, een timeout, een taak die niet is afgerond of een proces dat is afgesloten betekenen. Noteer één URL of actie, het laatst bekende werkende tijdstip, het eerste faaltijdstip en je tijdzone. Vermeld of iedereen is getroffen of slechts één client. Houd de huidige SSH-sessie open tijdens het onderzoek; toegangsregels wijzigen is geen noodzakelijke eerste reactie op een applicatiefout.

Deze gids gaat uit van een Linux-host met systemd, een applicatieservice genaamd first-api.service, en een lokaal health-endpoint op 127.0.0.1:3000/healthz. Deze standaardwaarden komen overeen met de eerste API-implementatiegids. Vervang ze door je werkelijke namen. Inspectie kan beheerdersrechten vereisen om processen of logs van andere gebruikers te zien. De onderstaande opdrachten en uitvoer zijn illustratief; er is geen providerinstantie getest voor deze gids.

Bewaar notities buiten de map van de falende app zelf. Noteer observaties vóór interpretaties: “verbinding geweigerd om 09:18 UTC” is een feit; “de VPS heeft meer CPU nodig” is nog steeds een hypothese. Als de server zelf onbereikbaar is, gebruik je je bestaande hersteltoegang en verzamel je verbindingsgegevens in plaats van aan te nemen dat een herstart van de app mogelijk is.

Lees de processtatus en de recente geschiedenis

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

De statusweergave beschrijft de huidige of meest recente aanroep en bevat recente journaalberichten. De geselecteerde eigenschappen geven je een compact overzicht om later te vergelijken. Een mislukte status of een oplopend herstartaantal verdient onderzoek; een actief proces heeft nog steeds een verzoektest nodig. Dit zijn verschillende controles, zoals beschreven in de upstream systemctl-referentie.

Als de unit ontbreekt, controleer eerst de naam en de implementatiemethode. Een app die in een interactieve terminal is gestart, een container en een systemd-service hebben verschillende eigenaren en logboeken. Direct een nieuwe service aanmaken kan ertoe leiden dat twee kopieën om dezelfde poort concurreren. Identificeer de bestaande situatie voordat je deze wijzigt.

Controleer de listener en doe een lokaal verzoek

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

Zoek naar het verwachte adres en de poort en identificeer vervolgens het eigenaarproces. Een proces dat naar een andere poort luistert, kan gezond zijn maar onbereikbaar via de geconfigureerde proxy. Een ander proces kan de verwachte poort hebben ingenomen. De ss-manual definieert de listener- en procesopties.

Als het lokale verzoek werkt en het openbare HTTPS-verzoek mislukt, ga dan verder met DNS-, TLS- en proxycontroles. Als de listener ontbreekt, onderzoek dan de opstartfout. Als de verbinding slaagt maar de app een fout retourneert, onderzoek dan die route en de afhankelijkheden ervan. Curl zonder --fail kan succesvol voltooien voor een HTTP-foutrespons, dus lees de respons in plaats van alleen te vertrouwen op de exitcode. Zie curl's respons- en foutopties.

Lees rond de eerste fout, niet alleen de laatste regel

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

De eerste query selecteert de service; de tweede selecteert kernelberichten. Pas het interval aan om het laatste werkende verzoek en de wijziging die aan de storing voorafging op te nemen. Toegang en bewaartermijn bepalen wat beschikbaar blijft. De upstream journalctl-referentie legt unit-, tijd- en kernelfilters uit. Redigeer tokens, klantgegevens en verbindingsstrings voordat je fragmenten deelt.

Illustratief fragment uit een aparte app met een uploadfunctie:

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

Dit wijst op de toegang van de servicegebruiker tot een specifiek pad. Controleer de eigendom van het bestand en de bovenliggende map aan de hand van de release-instructies. Verleen geen brede schrijftoegang tot het hele bestandssysteem. Een latere proxy-melding 'upstream unavailable' zou in dit scenario een gevolg zijn, dus het eerst repareren van de proxy zou de oorzaak missen.

Vergelijk resources met de meest recente release

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

Deze momentopnamen helpen je de vraag stellen of geheugendruk, bestandssysteemruimte of inode-uitputting samenviel met de storing. De interpretatie ervan hoort in de geheugen- en schijfgids; een enkele drukke meting stelt de oorzaak niet vast. Een service kan ook zijn eigen resourcelimiet bereiken terwijl de rest van de host capaciteit heeft.

Vergelijk de geïmplementeerde release-identifier, het opstartcommando, de vereiste namen van omgevingsvariabelen en datapaden met de laatste werkende release. Dumppel geen geheime omgevingswaarden in een rapport. Zoek naar een hernoemde map, ontbrekende runtime-afhankelijkheid, poortwijziging of incompatibele databasemigratie. Vermeld wat is gewijzigd en wat de fout voorspelt dat je zou moeten vinden.

Doe één gerechtvaardigde correctie en verifieer herstel

Kies de kleinste correctie die door het bewijs wordt ondersteund. Voor de illustratieve machtigingsfout betekent dat het herstellen van de beoogde toegang voor het serviceaccount en vervolgens één gecontroleerde opstartpoging. Als je in plaats daarvan een bekend werkende coderelease gebruikt, stel dan eerst vast of het databaseschema compatibel blijft. Een code-rollback kan een datamigratie niet automatisch ongedaan maken.

Herhaal na de correctie dezelfde service-, lokale endpoint- en openbare verzoekcontroles. Bevestig dat een representatieve applicatieactie werkt, dat nieuwe fouten zijn gestopt en dat het proces stabiel blijft tijdens de volgende normale werklast. Herstartbeleid kan helpen een proces te herstellen, maar maakt een blijvend defect programma niet gezond; raadpleeg de systemd-service-referentie voor het daadwerkelijke beleid.

Sluit je incidentnotitie af met het symptoom, de eerste nuttige aanwijzing, de gemaakte wijziging en het verificatieresultaat. Als de oorzaak onzeker blijft, meld die onzekerheid dan met geredigeerd bewijs in plaats van een tijdelijke herstart als permanente oplossing te bestempelen. Verbeter de releasechecklist met de controle die deze fout eerder zou hebben opgevangen.