Strežnik ne deluje: kaj preveriti najprej in v katerem vrstnem redu

Ta vodič govori o samem strežniku: VPS, namenskem ali oblačnem strežniku, ki ga upravljate. Če odpove eno samo spletno mesto, vse drugo na računalniku pa deluje, ali če vaše spletno mesto živi na skupnem gostovanju, raje začnite z vodičem Spletno mesto ne deluje: kaj storiti. Tu gledamo računalnik: ali sploh odgovarja, ali lahko vstopite in kaj se je ustavilo.

1. korak: kaj natančno ne deluje?

„Strežnik ne deluje“ lahko pomeni tri zelo različne stvari in vsaka ima svojo rešitev. Najprej ugotovite od zunaj, iz omrežja, ki ni vaše. Za spletna mesta na strežniku vam preverjanje delovanja spletnega mesta v nekaj sekundah pove, ali se ime razreši, ali vrata odgovarjajo in katera koda stanja se vrne. Za računalnik uporabite ping in preizkus vrat iz svojega računalnika:

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

Rezultate preberite skupaj:

• Brez pinga, brez SSH, brez spletnih vrat: računalnik je izklopljen, zamrznjen ali pa omrežje pred njim ne deluje. Pojdite na 2. korak.
• Ping odgovarja, SSH ne: računalnik teče, vendar je SSH blokiran, ustavljen ali pa je strežnik preobremenjen, da bi odgovarjal. Pojdite na 3. korak.
• SSH deluje, spletno mesto ne: strežnik je v redu, storitev pa ne. Pojdite na 4. korak.

Nekateri strežniki ping namenoma zavračajo. Če ping nikoli ni deloval, se zanesite na preizkuse vrat.

2. korak: nič ne odgovarja

Pred vsem drugim odprite nadzorno ploščo ali konzolo oblaka svojega ponudnika. Tri vprašanja v minuti rešijo večino primerov:

1. Ali strežnik teče? Ustavljena instanca, začasno ustavljen račun ali spodletelo plačilo od zunaj izgledajo popolnoma enako kot izpad.
2. Ali je znan incident? Preverite stran stanja ponudnika za svojo regijo ali podatkovni center.
3. Kaj kaže konzola? Spletna ali serijska konzola prikaže zaslon računalnika tudi brez omrežja. Panika jedra, „Out of memory: Killed process“ v zanki ali zagon, zataknjen pri preverjanju datotečnega sistema, vsak pove, kje je težava.

Če je računalnik zamrznjen, ga ponovni zagon iz konzole običajno obudi. Pred ponovnim zagonom posnemite zaslon konzole: ko se znova zažene, dokazov ni več. Če se ne zažene, večina ponudnikov ponuja reševalni sistem, iz katerega lahko priklopite disk, preberete dnevnike in popravite /etc/fstab ali pokvarjeno omrežno konfiguracijo.

3. korak: ping odgovarja, SSH ne

Računalnik je živ, zato je vzrok na njem. Prek konzole se prijavite in preverite običajne osumljence:

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'

Požarno pravilo, dodano v naglici, vaš lasten naslov IP, prepovedan po nekaj napačnih geslih, ali sprememba konfiguracije SSH, ki ni prestala preizkusa, so najpogostejše ključavnice. Svoj naslov odblokirate z sudo fail2ban-client set sshd unbanip YOUR_IP in pred ponovnim zagonom SSH vedno zaženite sudo sshd -t. Če SSH teče, vendar je samo zelo počasen, je strežnik preobremenjen: pojdite na 4. korak.

4. korak: ste noter, zdaj preberite štiri številke

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

• Obremenitev (uptime): daleč nad številom jeder CPU pomeni, da je računalnik preobremenjen. top ali htop pokaže, kateri proces je odgovoren.
• Pomnilnik (free -m): ni prostega pomnilnika in ni swapa, poleg tega „Killed process“ v dmesg, pomeni, da je jedro ustavilo proces, da je preživelo. Običajno je bila to podatkovna baza ali PHP.
• Disk (df -h): poln disk je najpogostejši vzrok težav s strežnikom. Podatkovne baze prenehajo pisati, dnevniki prenehajo, seje odpovedo. df -i preveri inode: disk je lahko „poln“ z več gigabajti prostora, če milijoni majhnih datotek porabijo vse inode.
• Napake V/I ali datotečni sistem samo za branje v dmesg: težava je v samem disku. Prenehajte pisati, naredite varnostno kopijo, če še lahko, in kontaktirajte ponudnika.

Za varno sprostitev prostora začnite s sistemskim dnevnikom in starimi arhivi:

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

Nikoli ne brišite datotek podatkovne baze ali datotek spletnega mesta, da naredite prostor.

5. korak: katera storitev se je ustavila in zakaj

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

systemctl --failed našteje vsako storitev, ki se je ustavila z napako. Dnevnik te storitve poimenuje razlog: že zasedena vrata, sintaksna napaka v konfiguracijski datoteki, manjkajoč certifikat, zmanjkalo prostora. Pred vsakim ponovnim zagonom preizkusite konfiguracijo (nginx -t, apachectl configtest, php-fpm -t), nato storitev zaženite z sudo systemctl restart SERVICE. Ponovni zagon brez preizkusa lahko ugasne storitev, ki je še napol delovala.

6. korak: kaj se je spremenilo?

Izpadi imajo vzroke, vzrok pa je običajno zadnja sprememba. Poiščite jo:

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

Samodejne posodobitve, novo jedro, ki čaka na ponovni zagon, namestitev, opravilo cron, ki je disk napolnilo z varnostnimi kopijami, potečen certifikat ali urejanje konfiguracije s strani nekoga drugega: če se ena od teh vrstic ujema s časom začetka izpada, imate sled.

Ko se iste težave s strežnikom vračajo

Strežnik, ki je enkrat odpovedal zaradi polnega diska ali ustavljene podatkovne baze, bo to ponovil. Preverjanje od zunaj pove, kdaj ne deluje; preverjanje od znotraj pove prej. Agent za strežnik poroča obremenitev, pomnilnik, diske in storitve od znotraj računalnika in vas opozori, ko disk preseže vaš prag ali se ustavi storitev, ki ste jo označili, dokler je še čas za ukrepanje. Nadzor strežnikov z agentom je del plačljivih paketov.

Ko tega ne želite početi ob 3. uri zjutraj

Če vaš strežnik ne deluje in ga raje date popraviti, kot da bi ga sami odpravljali, Quick Fix pogoste vzroke obravnava po fiksni ceni: znova zažene ustavljeno storitev, ko je preizkus njene konfiguracije uspešen, sprosti poln disk in obnovi potečen certifikat, pred tem pa naredi varnostno kopijo. Ko to ne zadošča, prevzame Deep Fix, 24 ur na dan, obračunan v 15-minutnih blokih, s ceno, prikazano pred naročilom. Oba delujeta prek Responderja, SSH kot root ali dostopa SSH do vašega spletnega prostora. Podrobnosti na strani popravilo strežnika in nujna podpora.