Leállt a szerver: mit ellenőrizzen először, és milyen sorrendben

Ez az útmutató magáról a szerverről szól: egy VPS-ről, dedikált vagy felhőszerverről, amelyet Ön üzemeltet. Ha csak egyetlen weboldal hibázik, és a gépen minden más működik, vagy az oldala megosztott tárhelyen van, kezdje inkább a Weboldal leállt: mit tegyen útmutatóval. Itt a gépet nézzük: válaszol-e egyáltalán, be tud-e lépni, és mi állt le.

1. lépés: mi áll le valójában?

A „leállt a szerver” három nagyon különböző dolgot jelenthet, és mindegyiknek más a javítása. Először kívülről derítse ki, egy olyan hálózatról, amely nem az Öné. A szerveren lévő weboldalaknál a weboldal-leállás ellenőrző másodpercek alatt megmondja, hogy a név feloldódik-e, a port válaszol-e, és milyen állapotkód jön vissza. A géphez használjon pinget és porttesztet a saját számítógépéről:

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

Az eredményeket együtt értelmezze:

• Nincs ping, nincs SSH, nincs webport: a gép ki van kapcsolva, lefagyott, vagy az előtte lévő hálózat nem működik. Ugorjon a 2. lépésre.
• A ping válaszol, az SSH nem: a gép fut, de az SSH blokkolva van, leállt, vagy a szerver túlságosan túlterhelt a válaszhoz. Ugorjon a 3. lépésre.
• Az SSH működik, a weboldal nem: a szerver rendben van, egy szolgáltatás nem. Ugorjon a 4. lépésre.

Egyes szerverek szándékosan eldobják a pinget. Ha a ping soha nem működött, támaszkodjon a porttesztekre.

2. lépés: semmi nem válaszol

Mindenekelőtt nyissa meg a szolgáltatója vezérlőpultját vagy felhőkonzolját. Három kérdés a legtöbb esetet egy perc alatt eldönti:

1. Fut a szerver? Egy leállított példány, egy felfüggesztett fiók vagy egy sikertelen fizetés kívülről pontosan úgy néz ki, mint egy leállás.
2. Van ismert incidens? Nézze meg a szolgáltató státuszoldalát a régiójára vagy adatközpontjára.
3. Mit mutat a konzol? A webes vagy soros konzol hálózat nélkül is megmutatja a gép képernyőjét. Egy kernel panic, ismétlődő „Out of memory: Killed process”, vagy egy fájlrendszer-ellenőrzésnél elakadt indítás mind megmondja, hol a probléma.

Ha a gép lefagyott, a konzolról végzett újraindítás általában visszahozza. Újraindítás előtt készítsen képernyőképet a konzolról: az újraindulás után a bizonyíték elvész. Ha nem indul el, a legtöbb szolgáltató kínál mentőrendszert, amelyből csatolhatja a lemezt, olvashatja a naplókat, és javíthatja az /etc/fstab fájlt vagy egy hibás hálózati konfigurációt.

3. lépés: a ping válaszol, az SSH nem

A gép él, tehát az ok rajta van. A konzolon jelentkezzen be, majd ellenőrizze a szokásos gyanúsítottakat:

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'

A sietve hozzáadott tűzfalszabály, néhány hibás jelszó után kitiltott saját IP-cím, vagy egy tesztjén megbukott SSH-konfigurációváltás a leggyakoribb zárak. Az IP-címét a sudo fail2ban-client set sshd unbanip YOUR_IP paranccsal oldhatja fel, és az SSH újraindítása előtt mindig futtassa a sudo sshd -t parancsot. Ha az SSH fut, de csak nagyon lassú, a szerver túlterhelt: ugorjon a 4. lépésre.

4. lépés: bent van, most olvasson el négy számot

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

• Terhelés (uptime): a CPU-magok számánál jóval magasabb érték azt jelenti, hogy a gép túlterhelt. A top vagy a htop megmutatja, melyik folyamat a ludas.
• Memória (free -m): ha nincs szabad memória és nincs swap, a dmesg pedig „Killed process” üzenetet mutat, a kernel leállított egy folyamatot a túlélésért. Általában az adatbázis vagy a PHP volt az.
• Lemez (df -h): a megtelt lemez a szerverproblémák leggyakoribb oka. Az adatbázisok nem írnak többé, a naplók leállnak, a munkamenetek hibáznak. A df -i az inode-okat ellenőrzi: egy lemez gigabájtnyi szabad hellyel is „tele” lehet, ha milliónyi apró fájl elhasználja az összes inode-ot.
• I/O-hibák vagy csak olvasható fájlrendszer a dmesg kimenetében: maga a lemez hibás. Hagyja abba az írást, készítsen mentést, ha még tud, és forduljon a szolgáltatójához.

A hely biztonságos felszabadításához kezdje a rendszernaplóval és a régi archívumokkal:

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

Soha ne törölje adatbázisfájlokat vagy weboldalfájlokat a hely megteremtéséhez.

5. lépés: melyik szolgáltatás állt le, és miért

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

A systemctl --failed felsorol minden szolgáltatást, amely hibával leállt. Annak a szolgáltatásnak a naplója megnevezi az okot: már használt port, szintaktikai hiba egy konfigurációs fájlban, hiányzó tanúsítvány, elfogyott hely. Minden újraindítás előtt tesztelje a konfigurációt (nginx -t, apachectl configtest, php-fpm -t), majd indítsa el a sudo systemctl restart SERVICE paranccsal. A teszt nélküli újraindítás leállíthat egy még félig működő szolgáltatást.

6. lépés: mi változott?

A leállásoknak oka van, és az ok általában az utolsó változtatás. Keresse meg:

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

Automatikus frissítések, egy újraindításra váró új kernel, egy telepítés, egy cron-feladat, amely mentésekkel töltötte meg a lemezt, egy lejárt tanúsítvány vagy valaki más konfigurációmódosítása: ha ezek egyike egybeesik a leállás kezdetének idejével, megvan a nyom.

Amikor ugyanazok a szerverproblémák visszatérnek

Egy szerver, amely egyszer megtelt lemez vagy leállt adatbázis miatt leállt, újra meg fogja tenni. A kívülről végzett ellenőrzés megmondja, mikor áll; a belülről végzett megmondja előtte. A szerverügynök belülről jelenti a terhelést, a memóriát, a lemezeket és a szolgáltatásokat, és riaszt, amikor egy lemez átlépi a küszöbét, vagy egy bejelölt szolgáltatás leáll, amíg még van idő cselekedni. A szervermonitorozás az ügynökkel a fizetős csomagok része.

Amikor nem akarja ezt hajnali 3-kor csinálni

Ha a szervere leállt, és inkább megjavíttatná, mint maga hibakeresne, a Quick Fix a gyakori okokat fix áron kezeli: újraindítja a leállt szolgáltatást sikeres konfigurációs teszt után, felszabadítja a megtelt lemezt, és megújítja a lejárt tanúsítványt, előtte biztonsági másolattal. Ha ez nem elég, a Deep Fix átveszi éjjel-nappal, 15 perces blokkokban elszámolva, az árat rendelés előtt látja. Mindkettő a Responderen, rootként SSH-n vagy a tárhelyére szóló SSH-hozzáféréssel működik. A részletek a szerverleállás javítása és sürgősségi szervertámogatás oldalon.