Server nere: vad du kontrollerar först, och i vilken ordning

Den här guiden handlar om själva servern: en VPS, en dedikerad server eller en molnserver som du driver. Om en enskild hemsida fallerar och allt annat på maskinen fungerar, eller om din hemsida ligger på delat webbhotell, börja i stället med guiden Hemsidan ligger nere: vad du gör. Här tittar vi på maskinen: svarar den alls, kommer du in, och vad stoppade.

Steg 1: vad är egentligen nere?

”Servern är nere” kan betyda tre mycket olika saker, och var och en har sin egen åtgärd. Ta först reda på det utifrån, från ett nätverk som inte är ditt. För hemsidor på servern talar kontrollen av om hemsidan ligger nere om inom några sekunder om namnet slås upp, om porten svarar och vilken statuskod som kommer tillbaka. För maskinen använder du ping och ett porttest från din egen dator:

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

Läs resultaten tillsammans:

• Inget ping, ingen SSH, ingen webbport: maskinen är avstängd, frusen, eller så ligger nätverket framför den nere. Gå till steg 2.
• Ping svarar, SSH gör det inte: maskinen körs, men SSH är blockerat, stoppat eller så är servern för överbelastad för att svara. Gå till steg 3.
• SSH fungerar, hemsidan gör det inte: servern är i ordning, en tjänst är det inte. Gå till steg 4.

Vissa servrar släpper ping med avsikt. Om ping aldrig fungerat, lita på porttesterna.

Steg 2: ingenting svarar

Öppna leverantörens kontrollpanel eller molnkonsol före allt annat. Tre frågor avgör de flesta fall på en minut:

1. Körs servern? En stoppad instans, ett avstängt konto eller en misslyckad betalning ser precis ut som ett driftstopp utifrån.
2. Finns det en känd incident? Kontrollera leverantörens statussida för din region eller ditt datacenter.
3. Vad visar konsolen? Webb- eller seriekonsolen visar maskinens skärm även utan nätverk. En kernel panic, ”Out of memory: Killed process” i en loop eller en uppstart som fastnat vid en filsystemskontroll berättar var problemet finns.

Om maskinen är frusen får en omstart från konsolen den oftast tillbaka. Innan du startar om: ta en skärmdump av konsolen; när den startat om är bevisen borta. Om den inte startar erbjuder de flesta leverantörer ett räddningssystem där du kan montera disken, läsa loggarna och reparera /etc/fstab eller en trasig nätverkskonfiguration.

Steg 3: ping svarar, SSH gör det inte

Maskinen lever, så orsaken finns på den. Använd konsolen för att logga in och kontrollera sedan de vanliga misstänkta:

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 brandväggsregel som lagts till i all hast, din egen IP-adress som spärrats efter några felaktiga lösenord, eller en ändring av SSH-konfigurationen som misslyckades i sitt test är de vanligaste låsen. Häv spärren för din adress med sudo fail2ban-client set sshd unbanip YOUR_IP, och kör alltid sudo sshd -t innan du startar om SSH. Om SSH körs men bara är mycket långsamt är servern överbelastad: gå till steg 4.

Steg 4: du är inne, läs nu fyra tal

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): långt över antalet CPU-kärnor betyder att maskinen är överbelastad. top eller htop visar vilken process som ansvarar.
• Minne (free -m): inget ledigt minne och ingen swap, plus ”Killed process” i dmesg, betyder att kärnan stoppade en process för att överleva. Oftast var det databasen eller PHP.
• Disk (df -h): en full disk är den vanligaste orsaken till serverproblem. Databaser slutar skriva, loggar upphör, sessioner misslyckas. df -i kontrollerar inoderna: en disk kan vara ”full” med gigabyte lediga om miljontals små filer använder alla inoder.
• I/O-fel eller ett skrivskyddat filsystem i dmesg: disken själv har ett problem. Sluta skriva, ta en säkerhetskopia om du fortfarande kan och kontakta din leverantör.

För att frigöra utrymme på ett säkert sätt, börja med systemjournalen och gamla arkiv:

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

Radera aldrig databasfiler eller hemsidefiler för att få plats.

Steg 5: vilken tjänst stoppade, och varför

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

systemctl --failed listar varje tjänst som stoppade med ett fel. Tjänstens journal nämner orsaken: en port som redan används, ett syntaxfel i en konfigurationsfil, ett saknat certifikat, slut på utrymme. Testa konfigurationen före varje omstart (nginx -t, apachectl configtest, php-fpm -t) och starta sedan med sudo systemctl restart SERVICE. En omstart utan testet kan ta ner en tjänst som fortfarande fungerade till hälften.

Steg 6: vad ändrades?

Driftstopp har orsaker, och orsaken är oftast den senaste ändringen. Leta efter 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

Automatiska uppdateringar, en ny kärna som väntar på en omstart, en driftsättning, ett cronjobb som fyllde disken med säkerhetskopior, ett utgånget certifikat eller en konfigurationsändring av någon annan: om en av dessa rader sammanfaller med tidpunkten då driftstoppet började har du din ledtråd.

När samma serverproblem återkommer

En server som gick ner en gång på grund av en full disk eller en stoppad databas gör det igen. Kontroll utifrån talar om när den är nere; kontroll inifrån talar om det innan. Serveragenten rapporterar belastning, minne, diskar och tjänster inifrån maskinen och larmar dig när en disk passerar ditt tröskelvärde eller en tjänst du kryssat i stoppar, medan det ännu finns tid att agera. Serverövervakning med agenten ingår i betalplanerna.

När du inte vill göra det här klockan 03 på natten

Om din server är nere och du hellre vill ha den åtgärdad än felsöka själv hanterar en Quick Fix de vanliga orsakerna till fast pris: den startar om en stoppad tjänst efter att dess konfigurationstest har godkänts, frigör en full disk och förnyar ett utgånget certifikat, med en säkerhetskopia först. När det inte räcker tar en Deep Fix över dygnet runt, debiterad i block om 15 minuter, med priset visat innan du beställer. Båda fungerar via Responder, SSH som root eller SSH-åtkomst till ditt webbutrymme. Detaljer på sidan server nere: åtgärd och akut serverhjälp.