A szerver felügyelete

Modul 8: Biztonsági mentések és felügyelet · Olvasási idő: 10 perc

Tanulási cél: A lecke után Ön meg tudja határozni, mit figyeljen a szerverén (kívülről és belülről), milyen küszöbértékek észszerűek, és hogyan biztosíthatja, hogy egy riasztás valóban eljusson Önhöz anélkül, hogy elárasztanák az értesítések.

Kulcsfogalmak: külső felügyelet, belső felügyelet, rendelkezésre állás (uptime), http-ellenőrzés, portellenőrzés, tanúsítvány lejárata, lemezterület, memória, terhelés (load), heartbeat (dead man's switch), küszöbérték, értesítési csatorna, riasztási fáradtság, a szolgáltató grafikonjai

Miért van szükség felügyeletre?

Felügyelet nélkül a problémákról az ügyfeleitől értesül, vagy egyáltalán nem. Egy webhely, amely szombat óta nem működik, egy lejárt tanúsítvány, egy megtelt lemez, egy biztonsági mentés, amely már három hete csendben meghiúsul: mindezt időben észrevehette volna. A felügyelet azt jelenti, hogy egy program folyamatosan figyel, és figyelmezteti Önt, ha valami nincs rendben.

Egy jó felügyelet két kérdésre ad választ:

1. Működik a felhasználó számára? Ezt kívülről méri.
2. Hamarosan baj lesz? Ezt belülről méri: lemez, memória, frissítések, biztonsági mentések.

Kívülről: amit a felhasználó lát

A külső felügyelet egy másik gépen fut, mint a szerver, lehetőleg egy másik szolgáltatónál. Ez logikus: ha a szerver leáll, már nem tud maga figyelmeztetni.

A tanúsítvány külön figyelmet érdemel. A Let's Encrypt tanúsítványai rövid ideig érvényesek, és automatikusan megújulnak (lecke 7.3), de ha a megújítás csendben meghiúsul, csak akkor veszi észre, amikor a látogatók figyelmeztetést kapnak. Maga a Let's Encrypt 2025 júniusa óta nem küld emlékeztető e-maileket a lejáró tanúsítványokról, és kifejezetten felügyeletet javasol. Egy tanúsítványellenőrzés, amely 14 napnál kevesebb érvényesség esetén figyelmeztet, tehát nem luxus.

Erre gyakran használt, saját üzemeltetésű program az Uptime Kuma, amelyet a lecke 9.4-ben konténerben telepít. Lehetőleg ne ugyanarra a szerverre tegye, amelyet felügyelnie kell, vagy kombinálja egy második, külső ellenőrzéssel. Vannak külső szolgáltatások is, amelyek ugyanezt teszik; válasszon egy Önnek megfelelőt, és figyeljen arra, hol van a székhelyük, ha az értesítésekben ügyféladatok is szerepelhetnek.

Belülről: ami hamarosan elromlik

Bizonyos problémákat kívülről csak akkor lát, amikor már késő. Ezeket magán a szerveren méri:

Ezt megoldhatja egy egyszerű szkripttel és időzítővel (lecke 6.3), amely küszöbtúllépéskor értesítést küld, vagy egy felügyeleti programmal, amelynek ügynöke (agent) fut a szerveren (ismert nyílt forráskódú példák a Netdata, valamint a Prometheus és a node_exporter kombinációja). Kezdje kicsiben: a lemez, a meghiúsult szolgáltatások és a biztonsági mentések figyelése a legtöbb problémát elkapja.

A szolgáltatója paneljében lévő grafikonok (processzor, memória, hálózat, lemez egy naptól egy évig) remekül kiegészítik ezt, mert láthatóvá teszik a trendeket: ha a lemez foglaltsága havonta néhány százalékkal nő, tudja, mikor fog megtelni. A WebOké-nál ezek a VPS képernyőjén találhatók, más szolgáltatóknál hasonló helyen. Általában nem küldenek értesítést, így nem helyettesítik a felügyeletet.

A heartbeat: jelzés, ha semmi sem történik

Bizonyos dolgokat éppen egy jel elmaradására kell figyelni. Az éjszakai biztonsági mentés a legjobb példa: ha a szkript el sem indul (az időzítő ki van kapcsolva, a szerver nem fut, a szkript hibás), hibaüzenet sem érkezik.

A megoldás neve heartbeat vagy dead man's switch: a felügyelet minden nap egy jelzést vár. A mentési szkript a végén, csak ha minden sikerült, egy kis http-kérést küld a felügyelet egy állandó, titkos URL-jére:

restic backup ... && restic check && curl -fsS -m 10 https://status.example.com/api/push/Xyz123abc?status=up >/dev/null

Ha egy napon nem érkezik meg a jelzés, értesítést kap. Az Uptime Kuma erre a Push monitortípust kínálja; vannak saját üzemeltetésű programok is, például a Healthchecks. Így egyetlen sorral ellenőrizheti, hogy a biztonsági mentés valóban lefutott-e.

Értesítések, amelyek megérkeznek, de nem túl sok

Egy értesítés, amelyet senki sem olvas el, nem felügyelet. Három dolgot rendezzen el:

1. Olyan értesítési csatorna, amelyet valóban lát: push-értesítés a telefonján, csevegőcsatorna, SMS. Az e-mail is megfelel, de csak ha a szervere megbízhatóan tud leveleket küldeni, és az e-mailek könnyen elsikkadnak. A legfontosabb értesítésekhez használjon két csatornát.
2. Ne függjön attól, amit felügyel. Ha a szerver maga küldi az e-mailt a megtelt lemezről, az nem érkezik meg, amikor a lemez megtelt. A külső felügyelet és a heartbeat ezt kivédi.
3. Kevés, de indokolt. Ha naponta tíz olyan értesítést kap, amellyel semmit sem kezd, el fogja kezdeni figyelmen kívül hagyni őket, azt az egyet is, amelyik számít. Ezt riasztási fáradtságnak nevezzük. Úgy állítsa be a küszöbértékeket, hogy egy értesítés azt jelentse: tennie kell valamit. Az értesítés csak több egymást követő sikertelen ellenőrzés után (például háromszor) induljon el, hogy egyetlen elveszett csomag ne ébressze fel.

Tesztelje az értesítéseit: állítson le rövid időre egy szolgáltatást, és nézze meg, megérkezik-e az értesítés, és mennyi ideig tartott.

Amit ne tegyen

• Ne tegye mindenki számára elérhetővé a felügyeleti oldalakat belső nevekkel és címekkel. Nyilvános állapotoldal lehet, de csak azt mutassa, amit a látogatók tudhatnak.
• Ne használjon erős jelszó és kétlépcsős azonosítás (2FA) nélküli rendszergazdai fiókot a felügyeletben. Aki bejut a felügyeletébe, kikapcsolhatja az értesítéseket.
• Ne adjon az ügynököknek a szükségesnél több jogosultságot. Egy felügyeleti ügynöknek általában nem kell root jogosultsággal futnia.

Összefoglalás

• Kívülről, egy másik gépről figyelje, hogy működik-e (http, port, tanúsítvány, DNS), belülről pedig azt, hogy hamarosan baj lesz-e (lemez, memória, szolgáltatások, frissítések, biztonsági mentések).
• A tanúsítványok saját ellenőrzést érdemelnek: a Let's Encrypt 2025 júniusa óta nem küld emlékeztető e-maileket.
• A heartbeat egy jelzés elmaradását jelenti; ideális biztonsági mentésekhez és ütemezett feladatokhoz.
• Válasszon olyan értesítési csatornát, amelyet valóban lát, és amely független magától a szervertől, és úgy állítsa be a küszöbértékeket, hogy minden értesítés cselekvést igényeljen.
• A szolgáltató grafikonjai trendeket mutatnak, de általában nem küldenek értesítést.

Kvíz

Feladat

Feladat O8.3: Az Ön felügyeleti listája. Készítsen felügyeleti listát a saját szerveréhez: milyen külső ellenőrzések legyenek (milyen időközzel és honnan), milyen belsők (küszöbértékekkel), milyen heartbeat(ek), és milyen csatornán érkezzenek az értesítések. Állítson be legalább egy külső http- vagy tanúsítványellenőrzést és egy heartbeatet (például a biztonsági mentéshez), majd tesztelje az értesítést úgy, hogy rövid időre leállít egy szolgáltatást. Jegyezze fel, mennyi idő telt el, amíg az értesítés megérkezett.

További olvasnivaló

• Nem fér hozzá a VPS-éhez? Mi a teendő?
• Let's Encrypt, Expiration Notification Service Has Ended: https://letsencrypt.org/2025/06/26/expiration-notification-service-has-ended
• Uptime Kuma (GitHub): https://github.com/louislam/uptime-kuma
• VPS: az első bejelentkezéstől a biztonságos szerverig 8.3: Felügyelet kívülről és belülről
• VPS: az első bejelentkezéstől a biztonságos szerverig 7.1: Uptime Kuma: a webhelyek és a szerver felügyelete