Server nede: hva du sjekker først, og i hvilken rekkefølge

Denne guiden handler om selve serveren: en VPS, en dedikert server eller en skyserver som du driver. Feiler bare én enkelt nettside og alt annet på maskinen fungerer, eller ligger nettsiden din på delt hosting, begynn i stedet med guiden Nettside nede: hva du gjør. Her ser vi på maskinen: svarer den i det hele tatt, kommer du inn, og hva stoppet.

Steg 1: hva er egentlig nede?

«Serveren er nede» kan bety tre veldig forskjellige ting, og hver har sin egen løsning. Finn først ut utenfra, fra et nettverk som ikke er ditt. For nettsider på serveren forteller nettside-nede-sjekken deg på sekunder om navnet løses opp, om porten svarer og hvilken statuskode som kommer tilbake. For maskinen bruker du ping og en porttest fra din egen datamaskin:

ping -c 3 203.0.113.10
nc -zv -w 5 203.0.113.10 22
nc -zv -w 5 203.0.113.10 443

Les resultatene sammen:

• Ingen ping, ingen SSH, ingen webport: maskinen er av, frosset, eller nettverket foran den er nede. Gå til steg 2.
• Ping svarer, SSH gjør det ikke: maskinen kjører, men SSH er blokkert, stoppet eller serveren er for overbelastet til å svare. Gå til steg 3.
• SSH fungerer, nettsiden gjør det ikke: serveren er i orden, en tjeneste er det ikke. Gå til steg 4.

Noen servere forkaster ping med vilje. Har ping aldri fungert, stol på porttestene.

Steg 2: ingenting svarer

Åpne leverandørens kontrollpanel eller skykonsoll før noe annet. Tre spørsmål avgjør de fleste tilfellene på et minutt:

1. Kjører serveren? En stoppet instans, en suspendert konto eller en mislykket betaling ser akkurat ut som et driftsstopp utenfra.
2. Finnes det en kjent hendelse? Sjekk leverandørens statusside for regionen eller datasenteret ditt.
3. Hva viser konsollen? Web- eller seriekonsollen viser maskinens skjerm selv uten nettverk. En kernel panic, «Out of memory: Killed process» i løkke, eller en oppstart som sitter fast på en filsystemkontroll forteller hver sitt om hvor problemet ligger.

Er maskinen frosset, får en omstart fra konsollen den vanligvis tilbake. Før du starter på nytt, ta et skjermbilde av konsollen: når den har startet på nytt, er beviset borte. Starter den ikke, tilbyr de fleste leverandører et redningssystem der du kan montere disken, lese loggene og reparere /etc/fstab eller en ødelagt nettverkskonfigurasjon.

Steg 3: ping svarer, SSH gjør det ikke

Maskinen lever, så årsaken ligger på den. Bruk konsollen til å logge inn, og sjekk deretter de vanlige mistenkte:

sudo ufw status verbose
sudo iptables -S | head -n 30
sudo fail2ban-client status sshd
sudo systemctl status ssh sshd 2>/dev/null | grep -E 'Loaded|Active'

En brannmurregel lagt til i full fart, din egen IP-adresse utestengt etter noen gale passord, eller en SSH-konfigurasjonsendring som feilet testen er de vanligste låsene. Opphev utestengingen av adressen din med sudo fail2ban-client set sshd unbanip YOUR_IP, og kjør alltid sudo sshd -t før du starter SSH på nytt. Kjører SSH, men er bare veldig treg, er serveren overbelastet: gå til steg 4.

Steg 4: du er inne, les nå fire tall

uptime
free -m
df -h
df -i
sudo dmesg -T | grep -iE 'oom|killed process|i/o error|read-only' | tail -n 20

• Belastning (uptime): langt over antall CPU-kjerner betyr at maskinen er overbelastet. top eller htop viser hvilken prosess som er ansvarlig.
• Minne (free -m): ikke noe ledig minne og ingen swap, pluss «Killed process» i dmesg, betyr at kjernen stoppet en prosess for å overleve. Vanligvis var det databasen eller PHP.
• Disk (df -h): en full disk er den hyppigste årsaken til serverproblemer. Databaser slutter å skrive, logger stopper, økter feiler. df -i sjekker inodene: en disk kan være «full» med gigabyte ledig hvis millioner av små filer bruker opp alle inodene.
• I/O-feil eller et skrivebeskyttet filsystem i dmesg: selve disken har et problem. Slutt å skrive, ta en sikkerhetskopi hvis du fortsatt kan, og kontakt leverandøren din.

For å frigjøre plass trygt starter du med systemjournalen og gamle arkiver:

sudo journalctl --vacuum-size=200M
sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -n 15

Slett aldri databasefiler eller nettsidefiler for å få plass.

Steg 5: hvilken tjeneste stoppet, og hvorfor

systemctl --failed
sudo journalctl -u nginx -n 50 --no-pager
sudo nginx -t

systemctl --failed lister hver tjeneste som stoppet med en feil. Journalen til den tjenesten navngir årsaken: en port som allerede er i bruk, en syntaksfeil i en konfigurasjonsfil, et manglende sertifikat, ikke mer plass. Test konfigurasjonen før hver omstart (nginx -t, apachectl configtest, php-fpm -t), og start den deretter med sudo systemctl restart SERVICE. En omstart uten testen kan ta ned en tjeneste som fortsatt fungerte halvveis.

Steg 6: hva ble endret?

Driftsstopp har årsaker, og årsaken er vanligvis den siste endringen. Let etter den:

grep -E ' (install|upgrade) ' /var/log/dpkg.log | tail -n 20
last -n 10
sudo journalctl --since "2 hours ago" -p err --no-pager | tail -n 40

Automatiske oppdateringer, en ny kjerne som venter på omstart, en utrulling, en cron-jobb som fylte disken med sikkerhetskopier, et utløpt sertifikat eller en konfigurasjonsendring gjort av noen andre: sammenfaller en av disse linjene med tidspunktet da driftsstoppet startet, har du et spor.

Når de samme serverproblemene kommer tilbake

En server som gikk ned én gang på grunn av en full disk eller en stoppet database, gjør det igjen. Å sjekke utenfra forteller deg når den er nede; å sjekke fra innsiden forteller deg før. Serveragenten rapporterer belastning, minne, disker og tjenester fra innsiden av maskinen og varsler deg når en disk passerer terskelen din eller en tjeneste du har krysset av stopper, mens det fortsatt er tid til å handle. Serverovervåking med agenten er en del av de betalte planene.

Når du ikke vil gjøre dette klokken 03 om natten

Er serveren din nede og du heller vil ha den fikset enn å feilsøke selv, tar en Quick Fix seg av de vanlige årsakene til fast pris: den starter en stoppet tjeneste på nytt etter at konfigurasjonstesten er bestått, frigjør en full disk og fornyer et utløpt sertifikat, med en sikkerhetskopi først. Er ikke det nok, tar en Deep Fix over døgnet rundt, fakturert i blokker på 15 minutter, med prisen vist før du bestiller. Begge fungerer via Responder, SSH som root eller SSH-tilgang til webhotellet ditt. Detaljer på siden rask hjelp når serveren er nede og akutt serverstøtte.