Server nefunguje: čo skontrolovať ako prvé a v akom poradí

Tento návod je o samotnom serveri: VPS, dedikovanom alebo cloudovom serveri, ktorý prevádzkujete. Ak zlyháva jeden web a všetko ostatné na stroji funguje, alebo váš web žije na zdieľanom hostingu, začnite radšej návodom Web nefunguje: čo robiť. Tu sa pozeráme na stroj: odpovedá vôbec, dostanete sa dnu a čo sa zastavilo.

Krok 1: čo presne nefunguje?

„Server nefunguje“ môže znamenať tri veľmi rozdielne veci a každá má vlastnú opravu. Zistite to najprv zvonku, zo siete, ktorá nie je vaša. Pri weboch na serveri vám kontrola dostupnosti webu za pár sekúnd povie, či sa názov preloží, či port odpovedá a aký stavový kód príde späť. Pre samotný stroj použite ping a test portu zo svojho počítača:

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

Čítajte výsledky spolu:

• Žiadny ping, žiadne SSH, žiadny webový port: stroj je vypnutý, zamrznutý alebo nefunguje sieť pred ním. Prejdite na krok 2.
• Ping odpovedá, SSH nie: stroj beží, ale SSH je blokované, zastavené alebo je server príliš preťažený na odpoveď. Prejdite na krok 3.
• SSH funguje, web nie: server je v poriadku, služba nie. Prejdite na krok 4.

Niektoré servery ping zámerne zahadzujú. Ak ping nikdy nefungoval, spoľahnite sa na testy portov.

Krok 2: nič neodpovedá

Pred čímkoľvek iným otvorte ovládací panel alebo cloudovú konzolu svojho poskytovateľa. Tri otázky vyriešia väčšinu prípadov za minútu:

1. Beží server? Zastavená inštancia, pozastavený účet alebo zlyhaná platba vyzerajú zvonku presne ako výpadok.
2. Existuje známy incident? Skontrolujte stavovú stránku poskytovateľa pre váš región alebo dátové centrum.
3. Čo ukazuje konzola? Webová alebo sériová konzola ukazuje obrazovku stroja aj bez siete. Kernel panic, „Out of memory: Killed process“ v slučke alebo štart zaseknutý na kontrole súborového systému, každé z toho hovorí, kde je problém.

Ak je stroj zamrznutý, reštart z konzoly ho zvyčajne vráti. Pred reštartom urobte snímku konzoly: po reštarte je dôkaz preč. Ak sa nenaštartuje, väčšina poskytovateľov ponúka záchranný systém, z ktorého môžete pripojiť disk, prečítať logy a opraviť /etc/fstab alebo pokazenú konfiguráciu siete.

Krok 3: ping odpovedá, SSH nie

Stroj žije, takže príčina je na ňom. Cez konzolu sa prihláste a skontrolujte obvyklých podozrivých:

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'

Narýchlo pridané pravidlo firewallu, vaša vlastná IP adresa zablokovaná po niekoľkých nesprávnych heslách alebo zmena konfigurácie SSH, ktorá zlyhala v teste, sú najčastejšie zámky. Svoju adresu odblokujte cez sudo fail2ban-client set sshd unbanip YOUR_IP a pred reštartom SSH vždy spustite sudo sshd -t. Ak SSH beží, ale je len veľmi pomalé, server je preťažený: prejdite na krok 4.

Krok 4: ste dnu, teraz prečítajte štyri čísla

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

• Záťaž (uptime): ďaleko nad počtom jadier CPU znamená, že stroj je preťažený. top alebo htop ukáže, ktorý proces je zodpovedný.
• Pamäť (free -m): žiadna voľná pamäť a žiadny swap plus „Killed process“ v dmesg znamená, že jadro zastavilo proces, aby prežilo. Zvyčajne to bola databáza alebo PHP.
• Disk (df -h): plný disk je najčastejšia príčina problémov so serverom. Databázy prestanú zapisovať, logy sa zastavia, relácie zlyhávajú. df -i kontroluje inody: disk môže byť „plný“ aj s gigabajtmi voľného miesta, ak milióny malých súborov spotrebujú všetky inody.
• Chyby I/O alebo súborový systém len na čítanie v dmesg: problém má samotný disk. Prestaňte zapisovať, ak ešte môžete, urobte zálohu a kontaktujte poskytovateľa.

Na bezpečné uvoľnenie miesta začnite so systémovým žurnálom a starými archívmi:

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

Nikdy nemažte súbory databázy ani súbory webu, aby ste uvoľnili miesto.

Krok 5: ktorá služba sa zastavila a prečo

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

systemctl --failed vypíše každú službu, ktorá sa zastavila s chybou. Žurnál tej služby pomenuje dôvod: port už používaný, syntaktická chyba v konfiguračnom súbore, chýbajúci certifikát, nezostáva miesto. Pred každým reštartom otestujte konfiguráciu (nginx -t, apachectl configtest, php-fpm -t) a potom službu spustite cez sudo systemctl restart SERVICE. Reštart bez testu môže zhodiť službu, ktorá ešte napoly fungovala.

Krok 6: čo sa zmenilo?

Výpadky majú príčiny a príčinou je zvyčajne posledná zmena. Hľadajte ju:

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

Automatické aktualizácie, nové jadro čakajúce na reštart, nasadenie, cron úloha, ktorá zaplnila disk zálohami, vypršaný certifikát alebo úprava konfigurácie niekým iným: ak sa niektorý z týchto riadkov zhoduje s časom začiatku výpadku, máte stopu.

Keď sa tie isté problémy so serverom vracajú

Server, ktorý raz spadol pre plný disk alebo zastavenú databázu, to urobí znova. Kontrola zvonku povie, kedy nefunguje; kontrola zvnútra povie skôr. Serverový agent hlási záťaž, pamäť, disky a služby zvnútra stroja a upozorní vás, keď disk prekročí váš prah alebo sa zastaví služba, ktorú ste zaškrtli, kým je ešte čas konať. Monitoring serverov s agentom je súčasťou platených tarifov.

Keď to nechcete robiť o 3. hodine ráno

Ak váš server nefunguje a radšej by ste ho nechali opraviť, než ladili sami, Quick Fix rieši bežné príčiny za pevnú cenu: reštartuje zastavenú službu po úspešnom teste konfigurácie, uvoľní plný disk a obnoví vypršaný certifikát, so zálohou vopred. Keď to nestačí, prevezme to Deep Fix nepretržite, účtovaný po 15-minútových blokoch, s cenou zobrazenou pred objednaním. Oboje funguje cez Responder, SSH ako root alebo prístup SSH do vášho webhostingu. Podrobnosti na stránke oprava nefunkčného servera a núdzová podpora.