Egy VPS-t nem elég beállítani: figyelni is kell. A legtöbb leállás nem a semmiből jön, hanem jelei vannak: lassan betelő lemez, egyre több memóriát használó folyamat, egy ismétlődő hiba a naplóban, egy hétvégén lejáró tanúsítvány. Ha ezeket időben látod, a hibát a látogatóid előtt veszed észre, és megelőzheted a leállást.

Ebben az útmutatóban összefoglaljuk, mit érdemes mérni egy VPS-en, milyen eszközökkel, hogyan állíts be riasztásokat úgy, hogy ne fulladj bele az értesítésekbe, és mit kezdj a mért adatokkal.

Mit mérj?

Elérhetőség kívülről

A legfontosabb kérdés: eléri-e a látogató a weboldalt? Ezt a szerveren kívülről kell mérni, mert ha a szerver leáll, a saját monitorozása sem tud szólni. Egy külső uptime-figyelő néhány percenként meghívja az oldalt (és akár egy kulcsszót is keres benne), és ha nem válaszol, riaszt.

Processzor

• CPU-használat: a tartósan 80–90% fölötti használat azt jelzi, hogy kevés a processzor, vagy egy folyamat elszabadult.
• Load average: az átlagos futásra váró folyamatok száma 1, 5 és 15 percre. Akkor gyanús, ha tartósan meghaladja a vCPU-k számát. Hogy mit jelent a load Linuxon, tudásbázis cikkünk írja le.
• Steal time (st): VPS-en ez mutatja, mennyi időt várt a virtuális gép a fizikai processzorra. Tartósan magas értéke a fizikai szerver túlterheltségére utal; egy garantált erőforrású KVM VPS-en ennek alacsonynak kell lennie.
• I/O wait (wa): mennyi időt vár a processzor a lemezre. Ha magas, a tároló a szűk keresztmetszet.

Memória

• Használt és elérhető memória: a Linux a szabad memóriát gyorsítótárnak használja, ezért a „free” érték alacsony lehet akkor is, ha minden rendben van. Az available (elérhető) értéket figyeld.
• Swap: ha a rendszer rendszeresen swapol, kevés a memória, és lassul.
• OOM killer: ha elfogy a memória, a kernel leállít egy folyamatot (gyakran éppen az adatbázist). A naplóban az „Out of memory” bejegyzések erre utalnak; erről az OOM killerről és a swap fájl létrehozásáról szóló cikk ír.

Lemez

• Szabad hely: a betelt lemez az egyik leggyakoribb leállási ok (naplók, mentések, feltöltések). 80–85%-nál riassz.
• Inode-ok: sok apró fájlnál (gyorsítótár, munkamenetek) az inode-ok elfogyhatnak, mielőtt a hely elfogyna.
• Lemezműveletek (IOPS, átvitel) és késleltetés.

A lemezhasználat ellenőrzéséről a du és df parancsokat bemutató cikk szól.

Hálózat

Bejövő és kimenő forgalom, kapcsolatok száma, hibák. Egy hirtelen forgalomnövekedés lehet egy sikeres kampány, de egy támadás vagy egy feltört szerverről induló spamküldés is.

Szolgáltatások és alkalmazás

• Futnak-e a fontos szolgáltatások (webszerver, PHP-FPM, adatbázis, levelezés)?
• Az alkalmazás válaszideje, a hibás kérések (5xx) aránya.
• Az adatbázis lassú lekérdezései.
• SSL tanúsítvány lejárata, a domain lejárata.
• Mentések: lefutott-e a legutóbbi mentés.

Naplók

A rendszer- és alkalmazásnaplók (journald, /var/log, a webszerver hiba- és hozzáférési naplói) mutatják meg, mi történt. Az ismétlődő hibák, a sikertelen belépési kísérletek és a szokatlan kérések korai figyelmeztetések. A naplók olvasásáról a journalctl-t és a /var/log könyvtárat bemutató cikk és a webszerver-naplók elemzéséről szóló blogcikkünk szól.

Eszközök

Gyors diagnózis a parancssorban

• htop vagy btop: a folyamatok, a CPU és a memória élőben. Erről a top és htop használatáról szóló cikk ír.
• vmstat 1: CPU, memória, swap, I/O wait és steal másodpercenként.
• iostat -x 1 (sysstat csomag): lemezterhelés és késleltetés.
• df -h, df -i, du: lemezhely és inode-ok.
• ss -tulpn: nyitott portok és kapcsolatok.
• journalctl -p err -b: a rendszer hibái az utolsó indítás óta.

Ezek a hibakereséshez kellenek; folyamatos figyeléshez és riasztáshoz az alábbi eszközök valók.

Monitorozó rendszerek

Eszköz	Mire jó	Megjegyzés
Netdata	Részletes, valós idejű mérés néhány perc alatt, kész riasztásokkal	Egy-két szerverhez a legegyszerűbb; nyílt forráskódú, felhőszolgáltatással is
Prometheus + Grafana	Idősoros mérés, testre szabott irányítópultok és riasztások	A node_exporterrel a rendszermetrikák, exporterekkel az alkalmazások is mérhetők; több szervernél ideális
Zabbix	Teljes körű vállalati monitorozás	Sok szerverhez, összetettebb beállítás
Glances	Egyszerű, áttekinthető terminálos és webes nézet	Gyors áttekintéshez
Monit	Szolgáltatások figyelése és automatikus újraindítása	Kicsi és megbízható, lásd lent

Külső elérhetőség-figyelés

• Uptime Kuma: saját üzemeltetésű, nyílt forráskódú uptime-figyelő, szép állapotoldallal. Egy másik szerveren futtasd, ne azon, amelyiket figyeli.
• Szolgáltatásként: UptimeRobot, Better Stack, HetrixTools és társaik; ingyenes csomaggal is néhány percenkénti ellenőrzést adnak.

Riasztások

Egy jó riasztás akkor szól, amikor tenni kell valamit, és csak akkor. Néhány tanács:

• Küszöb és időtartam: ne egy pillanatnyi kiugrásra riassz, hanem tartós állapotra (például „a CPU 5 percig 90% fölött”).
• Két szint: figyelmeztetés (például a lemez 80%-nál) és kritikus riasztás (95%-nál).
• A tünetet figyeld, ne csak az okot: a „nem válaszol a weboldal” fontosabb, mint a „magas a load”.
• Csatorna: az e-mailes riasztások könnyen elvesznek; a kritikusakat küldd mobilra (push értesítés, Telegram, Slack, SMS).
• Ne riassz feleslegesen: ha egy riasztásra rendszeresen nem kell tenni semmit, állítsd át vagy töröld, különben a fontosat is figyelmen kívül fogod hagyni.

Néhány bevált kiindulási küszöb:

Mérőszám	Figyelmeztetés	Kritikus
Lemezhasználat	80%	90–95%
Elérhető memória	15% alatt	5% alatt
CPU (tartósan)	80%	95%
Load (tartósan)	vCPU-k száma	a vCPU-k kétszerese
SSL lejárat	21 nap	7 nap
Weboldal elérhetősége	–	2–3 egymást követő sikertelen ellenőrzés

Automatikus helyreállítás

A Monit egy leállt szolgáltatást automatikusan újraindíthat, és értesít róla. Például a webszerverhez:

check process nginx with pidfile /run/nginx.pid
  start program = "/usr/bin/systemctl start nginx"
  stop program  = "/usr/bin/systemctl stop nginx"
  if failed host 127.0.0.1 port 80 protocol http then restart
  if 5 restarts within 5 cycles then alert

Az automatikus újraindítás tüneti kezelés: ha egy szolgáltatás rendszeresen leáll, az okát meg kell keresni.

Mit kezdj az adatokkal?

• Kevés a memória, rendszeres swap, OOM: hangold az alkalmazásokat (PHP-FPM folyamatszám, adatbázis pufferméret), vagy válts nagyobb csomagra.
• Magas CPU egy folyamatnál: nézd meg, melyik és miért (egy bővítmény, egy cron feladat, egy botforgalom, egy feltörés).
• Magas I/O wait: lassú lekérdezések, túl sok naplózás, vagy egy nagy mentés munkaidőben.
• Betelő lemez: naplórotáció, régi mentések törlése, gyorsítótár takarítása; ha a du nem mutatja, hol a hely, a betelt lemez rejtett okairól szóló cikk segít.
• Rendszeresen elért határok: az aWh KVM VPS-ein az ügyfélportálon nagyobb csomagra válthatsz; a VPS erőforrásainak skálázásáról külön útmutatónk szól.

A mért adatok a tervezéshez is kellenek: a heti és havi trendekből látszik, mikor fogy el a hely vagy a memória, így időben bővíthetsz.

Ki figyeli a szervert?

Egy nem menedzselt VPS-en a monitorozás a te feladatod. Ha nincs rá időd vagy tudásod, a menedzselt VPS szolgáltatásunkban a szerver felügyeletét, a riasztások kezelését és a hibák elhárítását mi végezzük. Az aWh KVM VPS szerverei garantált processzorral és memóriával, NVMe SSD-vel, napi mentéssel és 99,9%-os rendelkezésre állással érhetők el; a garantált erőforrások miatt a mért értékek kiszámíthatók, nem a szomszédos ügyfelek forgalmától függnek.

Összefoglalás

Mérd kívülről az elérhetőséget, belülről a CPU-t (a steal és az I/O wait értékkel együtt), a memóriát, a lemezt, a hálózatot, a szolgáltatásokat, a tanúsítványokat és a mentéseket. Egy-két szerverhez a Netdata és egy külső uptime-figyelő elég, több szerverhez a Prometheus és a Grafana. Állíts be kevés, de értelmes riasztást, és a trendekből tervezd meg a bővítést.

Gyakori kérdések

Mi a legegyszerűbb módja egy VPS figyelésének?

Egy külső uptime-figyelő (például UptimeRobot vagy egy másik szerveren futó Uptime Kuma) és a szerverre telepített Netdata. Ez néhány perc alatt beállítható, és a legtöbb problémát időben jelzi.

Mit jelent a steal time?

Azt az időt, amennyit a virtuális gép a fizikai processzorra várt, mert az mással volt elfoglalva. Garantált erőforrású KVM VPS-en alacsony; ha tartósan magas, jelezd a szolgáltatónak.

Lassítja a szervert a monitorozás?

A könnyű ügynökök (node_exporter, Netdata) elhanyagolható terhelést jelentenek. Egy nagyon kicsi VPS-en válassz könnyebb eszközt, és ne gyűjts feleslegesen sűrűn adatot.

Milyen gyakran ellenőrizzem az elérhetőséget?

1–5 percenként. Riasztást csak 2–3 egymást követő sikertelen ellenőrzés után küldj, hogy egy pillanatnyi hálózati hiba ne okozzon téves riasztást.

Hol tároljam a monitorozás adatait?

Ha lehet, ne ugyanazon a szerveren, amelyiket figyeled: egy külső szolgáltatásban vagy egy másik szerveren. Így a szerver kiesésekor is látod, mi történt előtte.

Kell monitorozás egy kis VPS-hez is?

Igen, legalább egy külső elérhetőség-figyelő és egy lemezhely-riasztás, mert a betelt lemez és a leállt szolgáltatás a kis szervereknél is a leggyakoribb hiba.

• vps
• monitorozás
• szerver üzemeltetés
• rendelkezésre állás
• útmutató