Server nejede: co zkontrolovat jako první a v jakém pořadí

Tento průvodce se týká samotného serveru: VPS, dedikovaného nebo cloudového serveru, který provozujete. Pokud selhává jeden web a všechno ostatní na stroji funguje, nebo váš web běží na sdíleném hostingu, začněte raději průvodcem Web nejede: co dělat. Tady se díváme na stroj: odpovídá vůbec, dostanete se dovnitř a co se zastavilo.

Krok 1: co přesně nejede?

„Server nejede“ může znamenat tři velmi odlišné věci a každá má svou opravu. Nejdřív to zjistěte zvenčí, ze sítě, která není vaše. U webů na serveru vám kontrola dostupnosti webu během několika sekund řekne, zda se jméno překládá, zda port odpovídá a jaký stavový kód se vrací. Pro stroj použijte ping a test portů z vlastního počítače:

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

Čtěte výsledky dohromady:

• Žádný ping, žádné SSH, žádný webový port: stroj je vypnutý, zamrzlý, nebo je nedostupná síť před ním. Pokračujte krokem 2.
• Ping odpovídá, SSH ne: stroj běží, ale SSH je blokované, zastavené, nebo je server příliš přetížený na to, aby odpověděl. Pokračujte krokem 3.
• SSH funguje, web ne: server je v pořádku, služba ne. Pokračujte krokem 4.

Některé servery ping záměrně zahazují. Pokud ping nikdy nefungoval, spolehněte se na testy portů.

Krok 2: nic neodpovídá

Dřív než cokoli jiného otevřete ovládací panel poskytovatele nebo cloudovou konzoli. Tři otázky vyřeší většinu případů za minutu:

1. Běží server? Zastavená instance, pozastavený účet nebo neúspěšná platba vypadají zvenčí přesně jako výpadek.
2. Existuje známý incident? Zkontrolujte stavovou stránku poskytovatele pro váš region nebo datové centrum.
3. Co ukazuje konzole? Webová nebo sériová konzole ukazuje obrazovku stroje i bez sítě. Kernel panic, „Out of memory: Killed process“ ve smyčce nebo start zaseknutý na kontrole souborového systému vám vždy řeknou, kde je problém.

Pokud je stroj zamrzlý, restart z konzole ho obvykle vrátí. Před restartem pořiďte snímek obrazovky konzole: po restartu jsou důkazy pryč. Pokud se nespustí, většina poskytovatelů nabízí záchranný systém, ze kterého můžete připojit disk, přečíst logy a opravit /etc/fstab nebo rozbitou konfiguraci sítě.

Krok 3: ping odpovídá, SSH ne

Stroj žije, takže příčina je na něm. Přihlaste se přes konzoli a zkontrolujte obvyklé podezřelé:

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'

Pravidlo firewallu přidané ve spěchu, vaše vlastní IP adresa zablokovaná po několika špatných heslech nebo změna konfigurace SSH, která neprošla testem, jsou nejčastější zámky. Odblokujte svou adresu příkazem sudo fail2ban-client set sshd unbanip YOUR_IP a před restartem SSH vždy spusťte sudo sshd -t. Pokud SSH běží, ale je jen velmi pomalé, je server přetížený: pokračujte krokem 4.

Krok 4: jste uvnitř, teď si přečtěte čtyři čí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átěž (uptime): hodnota daleko nad počtem jader CPU znamená, že je stroj přetížený. top nebo htop ukáže, který proces za to může.
• Paměť (free -m): žádná volná paměť a žádný swap plus „Killed process“ v dmesg znamená, že jádro zastavilo proces, aby přežilo. Obvykle to byla databáze nebo PHP.
• Disk (df -h): plný disk je nejčastější příčinou problémů se serverem. Databáze přestanou zapisovat, logy se zastaví, relace selhávají. df -i kontroluje inody: disk může být „plný“ s volnými gigabajty, pokud miliony malých souborů vyčerpají všechny inody.
• Chyby I/O nebo souborový systém jen pro čtení v dmesg: problém má samotný disk. Přestaňte zapisovat, pokud ještě můžete, udělejte zálohu a kontaktujte poskytovatele.

Místo uvolníte bezpečně tak, že začnete systémovým žurnálem a starými archivy:

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

Nikdy nemažte soubory databáze ani webu, abyste uvolnili místo.

Krok 5: která služba se zastavila a proč

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

systemctl --failed vypíše každou službu, která se zastavila s chybou. Žurnál této služby pojmenuje důvod: port, který už je používán, syntaktická chyba v konfiguračním souboru, chybějící certifikát, nedostatek místa. Před každým restartem otestujte konfiguraci (nginx -t, apachectl configtest, php-fpm -t), pak službu spusťte příkazem sudo systemctl restart SERVICE. Restart bez testu může shodit službu, která ještě napůl fungovala.

Krok 6: co se změnilo?

Výpadky mají příčiny a příčinou je obvykle poslední změna. Hledejte ji:

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é aktualizace, nové jádro čekající na restart, nasazení, úloha cron, která zaplnila disk zálohami, vypršelý certifikát nebo úprava konfigurace někým jiným: pokud některý z těchto řádků souhlasí s časem začátku výpadku, máte stopu.

Když se stejné problémy se serverem vracejí

Server, který jednou spadl kvůli plnému disku nebo zastavené databázi, to udělá znovu. Kontrola zvenčí vám řekne, kdy server nejede; kontrola zevnitř vám to řekne předtím. Serverový agent hlásí zátěž, paměť, disky a služby zevnitř stroje a upozorní vás, když disk překročí váš práh nebo se zastaví služba, kterou jste zaškrtli, dokud je ještě čas jednat. Monitoring serverů s agentem je součástí placených plánů.

Když to nechcete dělat ve 3 ráno

Pokud váš server nejede a raději byste ho měli opravený, než ho sami ladili, Quick Fix řeší běžné příčiny za pevnou cenu: restartuje zastavenou službu po úspěšném testu konfigurace, uvolní plný disk a obnoví vypršelý certifikát, se zálohou předem. Když to nestačí, převezme to Deep Fix nonstop, účtovaný po 15minutových blocích, s cenou zobrazenou před objednáním. Oba fungují přes Responder, SSH jako root nebo přístup přes SSH do vašeho webhostingu. Podrobnosti na stránce oprava výpadku serveru a nouzová podpora serverů.