Web může působit funkčně při ranní kontrole a být několik hodin nedostupný v noci. U více magazínů si takové výpadky nikdo nemusí všimnout, dokud se neozve čtenář nebo neuspěje automatická publikace. Monitoring má dát včasný a použitelný signál: který web má problém, od kdy, zda jde o celý web nebo jen jednu funkci a kdo to má řešit.
Co samotná kontrola dostupnosti nezjistí
Externí kontrola adresy může ověřit, že server vrací úspěšnou odpověď. Nedokáže tím ale potvrdit, že se načítají obrázky, funguje formulář, REST API přijímá články nebo cron publikuje naplánované příspěvky. Web může vracet HTTP 200 s chybovou stránkou, případně přesměrovat všechny URL na homepage. Naopak krátký výpadek jedné kontrolní stanice nemusí znamenat skutečný výpadek webu. Proto kombinujte několik typů signálů.
| Kontrola | Co odhalí | Co sama nezaručí |
|---|---|---|
| Externí HTTP kontrola | Nedostupnost, chybný kód, timeout | Správný obsah a funkci administrace |
| Kontrola klíčové stránky | Chybějící text či špatné přesměrování | Funkci všech rubrik |
| REST API kontrola | Nedostupnou publikační cestu | Úspěch skutečného zápisu bez testovací operace |
| Zdraví webu a cron | Problémy plánovaných úloh a konfigurace | Nepřetržitou veřejnou dostupnost |
| PHP a serverové logy | Příčinu chyby a opakované výjimky | Upozornění bez nastaveného vyhodnocení |
| Kontrola certifikátu a domény | Blížící se konec platnosti či DNS problém | Funkci samotného WordPressu |
U běžného obsahového webu začněte externím HTTP dohledem homepage a jednoho typického článku, alarmem na chybové stavy a kontrolou certifikátu. Pak přidejte to, co je pro provoz skutečně kritické: plánované publikace, formulář nebo API. Nenastavujte desítky identických alarmů bez vlastníka; lidé si na takový hluk rychle zvyknou.
Jak nastavit použitelné upozornění
U alarmu uveďte doménu, kontrolovanou URL, čas prvního selhání, typ chyby a odkaz na postup řešení. Krátké ověření z více míst může snížit falešné poplachy. Interval kontroly a počet opakování závisí na důležitosti webu: minutové kontroly mohou být vhodné pro obchodní systém, ale pro malý magazín mohou zbytečně zatěžovat rozpočet a vytvářet šum. Hlavní je, aby se zpráva dostala k člověku, který může jednat.
- Vyberte jednu veřejnou URL, která má vracet správný kód a očekávaný obsah.
- Nastavte rozumný interval a potvrzení chyby opakovaným testem.
- Určete odpovědnou osobu a náhradní kontakt. Ověřte doručení testovacího alarmu.
- Přidejte cestu eskalace: hosting, DNS, vývojář, redakce.
- Po prvním týdnu zkontrolujte falešné poplachy a upravte prahy.
Neposílejte hesla, přístupové tokeny ani citlivé výpisy databáze do notifikací. Pro test administrace nebo API používejte omezený účet a bezpečné uložení přístupů. Pro čtenářskou dostupnost většinou není nutné přihlášení vůbec. Správu technických účtů a aplikačních hesel podrobněji popisuje návod k zabezpečení WordPressu.
Publikace přes REST API a plánované články
Pokud obsah vytváří automatický nástroj přes REST API, sledujte zvlášť čtyři fáze: odeslání požadavku, odpověď serveru, skutečný stav článku v CMS a veřejnou stránku. Timeout po zápisu neznamená automaticky, že článek nevznikl. Před opakováním vyhledejte stav v CMS podle známého identifikátoru nebo jiné spolehlivé evidence operace; samotný shodný název nemusí stačit. Při slepém opakování mohou vzniknout duplicity.
U naplánovaných článků porovnávejte plánovaný čas s reálným stavem ve WordPressu a veřejnou URL. WP-Cron bývá spouštěn návštěvami, takže na méně navštěvovaném webu může běžet se zpožděním. Zdraví webu upozorňuje na některé problémy plánovače. Pokud je přesné vydání důležité, zjistěte u hostingu možnost skutečného serverového cronu a po nastavení zkontrolujte, že úloha opravdu běží.
Provozní deník pro síť webů
Spravujete-li desítky instalací, jedna obrazovka s počtem „online“ webů nestačí. U každého webu držte URL, hosting, DNS správce, poslední úspěšný backup, poslední aktualizaci, poslední veřejně ověřenou publikaci a kontaktní osobu. Pak umíte při incidentu poznat společného jmenovatele: několik výpadků na stejném hostingu, selhání po hromadné aktualizaci nebo expiraci společného certifikátu.
| Událost | První reakce | Koho zapojit |
|---|---|---|
| Jedna URL vrací 404 | Ověřit přesun, přesměrování a obsah | Redakce nebo správce webu |
| Celý web vrací 5xx | Zkontrolovat hosting, PHP log a poslední změnu | Správce a podpora hostingu |
| Nefunguje publikace přes API | Zjistit stav operace v CMS před opakováním | Správce integrace |
| Více webů na jednom hostingu vypadlo | Hledat společný limit či incident infrastruktury | Hosting a odpovědný provozní kontakt |
Jak se vyhnout falešným poplachům
Monitoring může nahlásit výpadek, když má problém jen jeho kontrolní bod, dočasně selže DNS resolver nebo ochrana webu zablokuje automatizovaný test. Při návrhu alarmu proto ověřujte chybu opakovaně a podle možností z více míst. Neskrývejte ale skutečný výpadek příliš dlouhým čekáním. Prahy nastavujte podle služby: pro web s objednávkami je krátký výpadek závažnější než pro archivní magazín.
Užitečný alarm rozlišuje chybu DNS, timeout, kód 5xx, expiraci certifikátu a chybějící očekávaný obsah. Pokud každý problém přijde jako stejný e-mail „site down“, správce musí znovu objevovat základní fakta. V notifikaci pomůže poslední úspěšný čas a číslo poslední změny, pokud ho bezpečně evidujete. Při obnově služby pošlete i potvrzení konce incidentu a spočítejte skutečnou délku, nikoli jen interval mezi dvěma upozorněními.
Co měřit mimo veřejnou stránku
Zálohy, plánované úlohy, dostupnost disku a počet serverových chyb často předznamenají výpadek. U hostingu sledujte, zda poskytuje statistiky vyčerpání CPU, paměti, současných PHP procesů a I/O. Bez nich není možné spolehlivě určit, zda za sporadické chyby může cache, plugin nebo sdílený limit. Ne každý hosting nabízí detailní metriky; v takovém případě uchovávejte alespoň čas chyb a korelujte je s logy a hromadnými operacemi.
Pro redakci je samostatným provozním ukazatelem poslední úspěšné vydání článku. Když tři články denně vznikají automatizovaně, sledujte, zda skutečně získaly očekávaný stav, autora, obrázek a veřejnou URL. Kontrola pouze HTTP stavu homepage takovou poruchu nezachytí. Přitom právě zdánlivě tichá chyba může znamenat několik dní nepublikovaného obsahu.
Malý provozní plán pro větší síť
Začněte tabulkou všech domén a skupin podle hostingu. Každému webu přiřaďte veřejnou kontrolní URL a případně jedno důležité funkční ověření. Pak stanovte, kdo vidí alarmy ve všední den a kdo při dovolené. Pokud žádný člověk nemá odpovědnost, nepomůže ani nejlepší služba. Jednou měsíčně proveďte testovací alarm pro jeden web a ověřte, že kontakt a postup ještě platí.
Výpadky vyhodnocujte také jako skupinu. Když tři magazíny na stejném hostingu hlásí timeout, jeden incident je pravděpodobnější než tři nezávislé chyby pluginů. Když selhává jen jeden web po jeho aktualizaci, začněte u poslední změny. Tato jednoduchá korelace šetří čas a pomáhá vést věcný rozhovor s podporou poskytovatele.
Co dělat při alarmu
Nejdřív ověřte výpadek z jiného připojení nebo externího testu a zjistěte jeho rozsah. Pak porovnejte čas s poslední aktualizací, publikací, změnou DNS či změnou PHP. Pokud jde o chybu na serveru, stáhněte relevantní logy a zkontrolujte limity účtu. Při výpadku více webů na stejné službě neodstraňujte jednotlivé pluginy naslepo; nejprve řešte společnou příčinu. Pokud potíže začaly po nové verzi, projděte kontrolní postup po aktualizaci WordPressu a pluginů.
- Neodkladné: úplná nedostupnost, zjevně kompromitovaný web, nefunkční objednávka či kritická integrace.
- Vysoká priorita: selhání naplánované publikace, chybný formulář, opakované 5xx, neúspěšná záloha.
- Běžná údržba: jedna chybějící stránka, menší zpomalení nebo doporučená aktualizace bez incidentu.
Po vyřešení zaznamenejte příčinu, délku výpadku a opatření, které zabrání opakování. Dobrý monitoring se nepozná počtem grafů, ale tím, zda umíte incident rychle vysvětlit a napravit. Pokud se problém týká výkonu, navazuje návod k diagnostice rychlosti; pokud obnovy, začněte u plánu záloh.
Modelový incident: alarm při noční publikaci
Představte si, že automatické publikování dostane timeout v 02:00. Monitor homepage přitom hlásí dostupnost a redakční nástroj neví, zda vytvoření článku proběhlo. Správný postup je nejprve načíst evidenci operace a stav v CMS. Může se ukázat, že článek vznikl jako návrh, ale nedostal náhledový obrázek; nebo že se publikoval a odpověď se ztratila cestou. V obou případech by slepé opakování mohlo vytvořit duplicitní příspěvek.
Po zjištění stavu opravte jen chybějící krok, ověřte autora, obsah, obrázek a veřejnou URL. Do provozního deníku uložte čas, ID, výsledek a příčinu. Pokud se chyba opakuje ve stejné době na více webech, srovnejte ji s noční zálohou nebo limity hostingu. Tento druh kontroly je nadstavba běžného „web je online“ a pro automatizovanou redakci má často větší hodnotu než další měření homepage.
Časté otázky k monitoringu
Stačí bezplatná kontrola jedné URL?
Je to dobrý začátek pro zjištění úplné nedostupnosti. Neodhalí ale tichou chybu publikačního procesu nebo nefunkční formulář. Přidejte aspoň jeden test odpovídající tomu, na čem web skutečně závisí.
Jak často kontrolovat magazín?
Interval volte podle dopadu výpadku a rychlosti reakce. Pokud se nikdo nedostane k alarmu dřív než ráno, kontrola každých pár sekund nepřinese užitek. Důležitější je spolehlivé doručení a jasný postup.
Jak ověřit REST API bez vytváření článků?
Veřejný čtecí požadavek zjistí dostupnost rozhraní, nikoli možnost autorizovaného zápisu. Pro kontrolu zápisové cesty použijte řízený testovací návrh a evidenci jeho ID, nebo sledujte skutečné produkční operace. Test nesmí vytvářet veřejné duplicity.
Co když hosting neukazuje detailní vytížení?
Uchovávejte přesné časy alarmů, odpovědi serveru a logy, které dostupné jsou. Požádejte podporu o konkrétní limit a čas překročení. Bez těchto údajů by rozhodnutí o dražším tarifu stálo na odhadu.
