- A státuszkód önmagában hazudik, a tartalmi kulcsszó figyelése elkapja az üres és a feltört oldalt is.
- Hat jelzés adja a teljes képet: válaszkód, tanúsítvány lejárata, tartalmi kulcsszó, válaszidő, űrlap-végpont és DNS-válasz.
- Az ellenőrzési gyakoriságot oldaltípushoz igazítsd, a webshop kasszájának sűrűbb figyelés jár, mint egy blogcikknek.
- Kétszintű riasztási rend nélkül az éjszakai zaj elnyeli a valódi jelzést, ezért csak a bevételt érintő hiba ébresszen fel valakit.
- Minden riasztástípushoz írd le előre, ki reagál és milyen határidővel, különben a jelzés gazdátlan marad.
Egy kkv-oldalnál a leállás ritkán úgy néz ki, hogy nem válaszol a szerver. Sokkal gyakoribb, hogy a kiszolgáló él, a böngészőben megjelenik valami, és közben hetekig nem érkezik ajánlatkérés. A klasszikus elérhetőség-figyelő ilyenkor csendben marad, mert ő csak annyit lát, hogy a gép felveszi a kapcsolatot. Ez az írás arról szól, hogyan építs olyan figyelést, ami a csendes hibát is elkapja, és hogyan rendezd a riasztásokat úgy, hogy tényleg reagáljon rájuk valaki.
Mit figyel valójában egy elérhetőség-figyelő, és mit nem?
Az alap elérhetőség-figyelés annyit állapít meg, hogy a megadott címre érkezik-e HTTP-válasz a megadott időn belül. Ennyi. Nem nézi meg, mi van a válaszban, nem tudja, hogy a főoldalad helyén most egy üres sablon vagy egy idegen kártyaadat-halászó űrlap áll.
Hivatalosan igazolt: a HTTP-szabvány szerint a 200-as válaszkód azt jelenti, hogy a kérés sikeres volt és a szerver küldött törzset. Arról, hogy a törzs tartalma helyes-e, üzletileg értelmes-e vagy egyáltalán a tiéd-e, a válaszkód semmit nem mond.
Saját tapasztalat: a kkv-oldalakon látott valódi kiesések nagyobb része nem teljes leállás volt, hanem részleges hiba. Egy rosszul lefutott bővítmény-frissítés, egy lejárt adatbázis-jelszó, egy félbemaradt migráció. Ezek mindegyike tud olyan oldalt eredményezni, ami kívülről egészségesnek látszik.
Milyen hat jelzést érdemes egy kkv-oldalra tenni?
Hat figyelés adja együtt a teljes képet. Külön-külön mindegyik vak valamire, együtt viszont lefedik a gyakorlatban előforduló hibák nagy részét.
1. Válaszkód
Ez az alapréteg. Azt figyeled, hogy a fő URL-ek 200-as kóddal válaszolnak-e, és nem csúsznak-e át 500-as szerverhibába vagy váratlan 301/302 átirányításba. Az átirányítás-figyelés azért fontos, mert egy rosszul beállított bővítmény képes az egész oldalt egy idegen címre terelni, miközben a kiinduló kérés technikailag sikeres.
Gyors kézi ellenőrzés parancssorból: curl -s -o /dev/null -w '%{http_code} %{time_total}\n' https://pelda.hu/
2. Tanúsítvány lejárata
A lejárt TLS-tanúsítvány az egyik legdrágább apró hiba, mert a böngésző teljes képernyős figyelmeztetést dob, és a látogató visszafordul. Az automatikus megújítás (Let's Encrypt, ACME) jó, de nem csalhatatlan, a megújító feladat el tud némulni egy szerverköltözés vagy egy jogosultság-változás után.
Állíts be figyelmeztetést 30, 14 és 7 nappal a lejárat előtt. Kézi ellenőrzés: echo | openssl s_client -connect pelda.hu:443 -servername pelda.hu 2>/dev/null | openssl x509 -noout -enddate
3. Tartalmi kulcsszó jelenléte
Ez a legfontosabb réteg, és a legtöbb kkv-oldalról pont ez hiányzik. A figyelő letölti a HTML-t, és megnézi, szerepel-e benne egy olyan szöveg, aminek ott KELL lennie, ha az oldal jól működik. Ilyen lehet a cégnév a láblécben, a Kosárba gomb felirata, a Kapcsolat oldal Ajánlatkérés szövege vagy egy termékoldal ártáblájának fejléce.
Érdemes fordított irányban is figyelni. Ha a válaszban megjelenik olyan szöveg, aminek soha nem szabadna ott lennie (adatbázis-hibaüzenet, warning, deprecated, Error establishing a database connection), az önmagában riasztás. Kézi minta: curl -s https://pelda.hu/kapcsolat | grep -q 'Ajánlatkérés' || echo HIANYZIK
4. Válaszidő-küszöb
A lassulás a leállás előszobája. Ha a főoldal válaszideje a szokásos érték két-háromszorosára ugrik, valami elkezdett romlani, jellemzően az adatbázis vagy egy külső beépülő szolgáltatás. Ne fix számot állíts be vaktában, hanem mérj két hétig, és a szokásos érték köré tegyél küszöböt. Figyelmeztető és riasztó szintet is érdemes húzni, hogy legyen időd megnézni a dolgot, mielőtt tényleg elesik.
5. Űrlap-végpont
Az ajánlatkérő űrlap a kkv-oldal bevételi csatornája, mégis szinte soha nincs figyelve. Két megoldás van. Az egyszerűbb, hogy az űrlapot tartalmazó oldalra teszel tartalmi kulcsszó-figyelést a gomb feliratára, így legalább az eltűnt űrlapot észreveszed. A komolyabb, hogy a figyelőszolgáltatás rendszeres időközönként POST-ot küld az űrlap végpontjára egy felismerhető tesztadattal, és a válaszban a köszönő-üzenetet keresi.
Szakmai feltételezés: a POST-os megoldás pontosabb, cserébe szemetel a beérkező levelek között és torzíthatja a konverziós mérést. Ha bevezeted, a tesztküldést szűrd ki a mérésből és a levelezésben külön címkézd.
6. DNS-válasz
A DNS-figyelés azt nézi, hogy a domained a várt IP-címre vagy a várt névre mutat-e. Erre két okból van szükség. Egyrészt a domain-lejárat és a névszerver-csere csendben el tudja vinni az egész oldalt, másrészt a jogosulatlan DNS-módosítás a domain-eltérítés első lépése. Ha az A rekord vagy az MX rekord az éjszaka közepén megváltozik, és te ezt csak reggel veszed észre, addig a leveleid is máshová mennek.
Kézi ellenőrzés: dig +short pelda.hu A @1.1.1.1
Miért ér többet a tartalmi kulcsszó figyelése, mint a státuszkód?
Mert a legveszélyesebb hibák mind 200-as kóddal jönnek. Ez a cikk saját nézőpontja, és a gyakorlatban ez választja el a látszatfigyelést a valóditól.
Gondolj végig három esetet. Az első, amikor egy sablonfrissítés után a tartalom eltűnik, és az oldal fejléccel meg lábléccel, de üres törzzsel töltődik be. A szerver boldogan küld 200-at. A második, amikor a WordPress-oldalt feltörik, és a támadó a tartalom helyére átirányító szkriptet tesz, ami csak a mobilos látogatóknak vagy csak a keresőből érkezőknek aktiválódik. A szerver megint 200-at küld. A harmadik, amikor a webshop kosár-bővítménye halt el, a termékoldal betölt, csak épp nincs rajta Kosárba gomb. Megint 200.
Mindhárom esetben az egyetlen külső jelzés az, hogy egy konkrét szövegrész eltűnt az oldalról. Saját tapasztalat: ha egyetlen dolgot vezetsz be ebből a cikkből, a tartalmi kulcsszó-figyelést vezesd be, a főoldalra, a legfontosabb szolgáltatásoldalra és a kapcsolati oldalra.
Van egy hasznos mellékhatása is. A tartalmi figyelés akkor is jelez, ha valaki a csapatból jó szándékkal átírja a fontos gomb szövegét. Ez eleinte téves riasztásnak tűnik, valójában viszont változás-napló, és érdemes végignézni, mit módosítottak.
Hogyan állítsd be lépésről lépésre egy figyelőszolgáltatásban?
A lépéssor a legtöbb szolgáltatásnál (UptimeRobot, Better Stack, Pingdom, Hetrix, önhosztolt Uptime Kuma) ugyanez, csak a mezők neve más.
- Írd össze a figyelendő URL-eket. Kezdj öttel, ne ötvennel. Főoldal, legfontosabb bevételt hozó aloldal, kapcsolati oldal, webshopnál a kosár és a pénztár.
- Hozz létre HTTPS-figyelőt minden URL-re. Állítsd be, hogy a figyelő NE kövesse automatikusan az átirányítást, különben pont az átirányítás-hibát nem látod meg.
- Kapcsold be a kulcsszó-figyelést. Add meg a keresett szöveget pontosan úgy, ahogy a forráskódban szerepel, ékezetekkel együtt. Ellenőrizd, hogy a szöveg a HTML-ben is benne van-e, és nem csak JavaScripttel kerül oda, mert a figyelő jellemzően nem futtat szkriptet.
- Adj hozzá egy fordított kulcsszó-szabályt a hibaüzenetekre. Ha a szolgáltatás nem tud tiltólistát, hozz létre egy második figyelőt, ami akkor riaszt, ha a tiltott szöveg megjelenik.
- Állítsd be a válaszidő-küszöböt. Két hét mérés után húzd meg a figyelmeztető és a riasztó szintet.
- Kapcsold be a tanúsítvány-figyelést a 30, 14 és 7 napos előjelzéssel.
- Vedd fel a DNS-figyelőt az A rekordra, és ha e-mailt is fogadsz a domainen, az MX rekordra.
- Állítsd be a megerősítést. Egyetlen sikertelen lekérés ne riasszon, két vagy három egymás utáni hiba riasszon. Ez szűri ki a hálózati pillanathibákat.
- Legalább két földrajzi helyről ellenőriztess, ha a szolgáltatás tudja. Így kiderül, hogy tényleg az oldal fekszik, vagy csak az egyik mérőpont útvonala.
- Teszteld élesben. Kapcsold ki egy percre a figyelt bővítményt, vagy írd át ideiglenesen a keresett szöveget, és nézd meg, tényleg megérkezik-e a riasztás oda, ahová vártad.
Milyen gyakran ellenőrizz oldaltípusonként?
A gyakoriság ára a téves riasztások száma és a figyelő terhelése, ezért ne mindent nézess percenként.
- Webshop kosár és pénztár: egy perc. Itt minden kieső perc mérhető bevételkiesés.
- Főoldal és fő szolgáltatásoldal: egy-öt perc.
- Kapcsolati oldal és űrlap-végpont: öt perc a kulcsszó-figyelésre, az aktív POST-tesztet elég óránként futtatni.
- Blog, aloldalak, tudásbázis: tizenöt perc bőven elég.
- Tanúsítvány: napi egy ellenőrzés.
- DNS-rekordok: öt-tizenöt perc, a domain-lejárat figyelése napi.
- Foglalási vagy időpontfoglaló rendszer: öt perc a nyitvatartási időben, éjszaka ritkábban.
Szakmai feltételezés: a legtöbb kkv-nál az egyperces figyelés csak a bevételi útvonalon hoz valódi hasznot, máshol inkább több zajt ad, mint információt.
Hogyan építs riasztási rendet, hogy ne vesszen el a jelzés az éjszakai zajban?
A rossz riasztási rend rosszabb, mint a semmilyen, mert hamis biztonságérzetet ad, és egy idő után mindenki némítja az értesítéseket. Két szintre bontsd a jelzéseket.
Az ébresztő szintre csak az kerül, ami pénzt visz. Teljes elérhetetlenség, pénztár- vagy kosárhiba, eltűnt tartalmi kulcsszó a főoldalon, DNS-változás. Ezek telefonhívást vagy áttörő értesítést érdemelnek, éjjel is.
A napközbeni szintre kerül minden más. Lassulás, tanúsítvány-előjelzés, aloldali hiba, egyszeri lekérés-kimaradás. Ezek e-mailben vagy csoportos üzenetben gyűlnek, és munkaidőben nézi meg valaki.
Három technika csökkenti a zajt érdemben. Az első a megerősítés, vagyis legalább két egymás utáni hibás lekérés kell a riasztáshoz. A második a csoportosítás, ha tíz figyelő egyszerre esik el, az egy riasztás legyen, ne tíz. A harmadik a karbantartási ablak, a tervezett frissítés idejére némítsd le a figyelőt, különben megtanulod figyelmen kívül hagyni a jelzéseit.
Az éjszakai zaj legnagyobb forrása saját tapasztalat szerint nem az oldal, hanem a tárhely éjszakai mentése és az agresszív robotforgalom. Mindkettő átmeneti lassulást okoz. Ha ezt látod, ne a küszöböt emeld meg vakon, hanem tedd a lassulást napközbeni szintre, és az ébresztőt hagyd meg a tényleges kiesésnek.
Ki reagáljon a riasztásra, és milyen határidővel?
A figyelés annyit ér, amennyi cselekvés követi. Írd le egy fél oldalon, ki az elsődleges és ki a másodlagos felelős, és mit tegyen, ha az elsődleges nem elérhető. Kkv-nál ez jellemzően a weboldalt karbantartó partner, mögötte a tárhelyszolgáltató ügyfélszolgálata, és a cég részéről egy ember, aki dönthet.
- Teljes elérhetetlenség vagy pénztárhiba: visszajelzés 15 percen belül, érdemi vizsgálat megkezdése 30 percen belül, a cég felé állapotjelentés óránként.
- Eltűnt tartalmi kulcsszó vagy gyanús szöveg megjelenése: visszajelzés 30 percen belül, mert ez biztonsági esemény is lehet.
- Tanúsítvány-előjelzés: munkanapon belül intézendő, a 7 napos jelzésnél már sürgős.
- Válaszidő-romlás: egy munkanapon belül ránézés, mérésekkel alátámasztva.
- DNS-változás, amit senki nem kezdeményezett: azonnali, mert domain-eltérítés gyanúja.
A határidőket a saját működésedhez igazítsd, de legyenek leírva, és legyen egy hely, ahol a riasztások és a rájuk adott válaszok nyoma marad. Ez később a visszanézésnél többet ér, mint bármilyen műszerfal.
Mit érdemes ellenőrizned, mielőtt késznek tekinted a beállítást?
- Minden figyelt URL a végleges, átirányítás nélküli címre mutat.
- A keresett kulcsszó a HTML forráskódban van, nem csak a megjelenített oldalon.
- A riasztás legalább két csatornán megy ki, és legalább két emberhez ér el.
- Volt már valódi tesztriasztás, és megérkezett oda, ahová várták.
- A tanúsítvány- és a domain-lejárat figyelése külön van, mert a kettő nem ugyanaz.
- A karbantartási ablak beállítható, és a csapat tudja, hogyan kell használni.
- A figyelőszolgáltatás értesítései nem a spam mappában landolnak.
- Van írásos felelős-rend, és az ott szereplő emberek tudnak róla.
Ez a felépítés nem garantál hibamentes működést, és nem előzi meg a kiesést. Azt viszont jó eséllyel eléri, hogy a hibát te vedd észre előbb, ne az ügyfeled, és hogy a javítás percekben, ne napokban mérődjön.
Források és további olvasnivalók
- Google Search Central, dokumentáció a webhely elérhetőségéről és a feltörés utáni helyreállításról
- Google Search Central, Core Web Vitals és oldalélmény dokumentáció
- IETF RFC 9110, HTTP Semantics (válaszkódok jelentése)
- IETF RFC 8555, Automatic Certificate Management Environment (ACME)
- Let's Encrypt hivatalos dokumentáció a tanúsítvány-megújításról
- Mozilla Developer Network, HTTP status codes és TLS referencia
- OWASP, Web Security Testing Guide
- Google Site Reliability Engineering kézikönyv, Monitoring Distributed Systems fejezet
- ICANN, domain-regisztrációval és lejárattal kapcsolatos tájékoztatók
Gyakori kérdések
Elég, ha csak a főoldalt figyelem?
A főoldal jó kiindulás, de önmagában keveset mond. A legtöbb bevételt hozó aloldal, a kapcsolati oldal és webshopnál a kosár is kerüljön be a figyelésbe, mert ezek külön is el tudnak romlani úgy, hogy a főoldal közben hibátlanul működik.
Miért nem elég a 200-as státuszkód figyelése?
Mert a 200 csak annyit jelent, hogy a szerver sikeresen küldött választ. Az üres, a hibásan frissült és a feltört oldal is 200-at ad vissza. Ezért kell mellé olyan tartalmi kulcsszót figyelni, aminek kötelezően ott kell lennie a működő oldalon.
Milyen szöveget válasszak kulcsszónak a figyeléshez?
Olyat, ami ritkán változik és egyértelműen a működő oldalhoz tartozik. Jó jelölt a cégnév a láblécben, a Kosárba vagy Ajánlatkérés gomb felirata, vagy egy szolgáltatásoldal állandó alcíme. Kerüld a dátumot, az árat és a kampányszövegeket.
Éjszaka is kapjak riasztást?
Csak arról, ami pénzt visz, vagyis teljes kiesésről, pénztárhibáról, eltűnt főoldali tartalomról és váratlan DNS-változásról. Minden más várhat a következő munkanapig. Ha éjjel minden apróság ébreszt, néhány héten belül mindenki némítja az értesítéseket.
Hogyan figyeljem az ajánlatkérő űrlapot anélkül, hogy tele szemetelném a postafiókot?
Első körben elég az űrlapot tartalmazó oldalra kulcsszó-figyelést tenni a gomb feliratára. Ha aktív tesztküldést is szeretnél, futtasd ritkábban, például óránként, felismerhető tesztadattal, és szűrd ki ezeket a beérkező levelek és a konverziómérés közül.
Mit jelez, ha megváltozik a domain DNS-rekordja anélkül, hogy bárki hozzányúlt volna?
Ez biztonsági esemény gyanúja, jellemzően domain-eltérítés vagy illetéktelen hozzáférés a regisztrátori fiókhoz. Ilyenkor azonnali reagálás kell, jelszócsere a regisztrátornál, kétlépcsős azonosítás bekapcsolása, és az MX rekord ellenőrzése, mert a levelezés is elterelhető.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.