Blackbox monitoring v roce 2026: UptimeRobot, Gatus, Blackbox Exporter a kdy který zvolit

Externí monitoring dostupnosti serveru: jak se o problému dozvědět dřív než uživatel

Standardní postup pro seriózní produkci: na serveru běží agent (Prometheus node_exporter, Zabbix agent, Netdata, Datadog), který sbírá metriky CPU, RAM, disku, sítě. Vše se loguje, jsou tam pěkné dashboardy, nastavené alerty. Zdálo by se, plná kontrola.

Až do okamžiku, kdy OS zamrzne, síťový stack selže, nebo server chytne kernel panic. Agent mlčí, protože mlčí celý server. Dashboardy ukazují poslední stav před pádem. Alerty žádné. Uživatel, který obnovuje vaši hlavní stránku a vidí 408 Request Timeout (nebo rovnou connection refused), se o problému dozví rychleji než vy.

To je klasické slepé místo whitebox monitoringu: uvnitř toho vidí hodně, ale nevidí nic, když „uvnitř" není koho se zeptat. Externí monitoring (blackbox) tuto díru uzavírá z opačné strany, kontroluje dostupnost serveru zvenčí, nezávisle na jeho stavu.

1. Blackbox vs whitebox — dva úhly pohledu

Whitebox monitoring vidí server „zevnitř": ví o procesech, metrikách jádra, diskovém I/O, síťových spojeních, logách aplikací. Je hluboký, přesný, umožňuje nejen konstatovat problém, ale i pochopit jeho příčinu.

Blackbox monitoring vidí server tak, jak ho vidí uživatel: otevírá se stránka, odpovídá API, je validní SSL certifikát, jak dlouho trvá TCP handshake. Je povrchový, o příčinách nic neříká, ale má jednu unikátní vlastnost: funguje i tehdy, když whitebox mlčí.

Závěr je jasný: tyto dva přístupy se navzájem nenahrazují, ale doplňují. Whitebox říká „proč něco nefunguje". Blackbox říká „nefunguje". Každý sám o sobě ponechává slepá místa. Dohromady pokrývají většinu reálných scénářů výpadku.

2. Co přesně kontrolovat zvenčí

Než začneme mluvit o nástrojích, je potřeba rozumět sadě základních kontrol, ze kterých se skládá jakýkoli externí monitoring.

HTTP/HTTPS

Základní kontrola pro webové služby. Monitorovací agent udělá GET požadavek na váš endpoint a dívá se na:

• HTTP kód finální odpovědi (normální je 200; před ním mohou být 3xx redirecty, to není problém. Ale 4xx nebo 5xx jako konečný kód — nebo v řetězci po 3xx — je výpadek)
• Response time (zpomaluje ještě před úplným selháním, dává varování)
• Přítomnost klíčového slova v odpovědi (například útržku textu vaší hlavní stránky, aby se vyloučil případ „vrací něco jiného")
• Validitu HTTP hlaviček (například redirect chains, cache-control)

TCP port

Pro nestandardní služby: SSH (22), SMTP (25, 465, 587), IMAP (143, 993), databáze (5432, 3306, 27017), vlastní API na netypických portech. Agent zkusí otevřít TCP spojení a dívá se, zda server odpoví SYN-ACK.

ICMP (ping)

Nejjednodušší kontrola: „je host živý na síťové úrovni". Užitečná jako rychlý indikátor, ale omezená: mnoho poskytovatelů a CDN blokuje ICMP ve výchozím nastavení, takže false positive „ping neprošel = server spadl" je typická chyba začátečníků.

SSL certifikát

Samostatná, podceňovaná kontrola. Monitorovací agent se připojí na port 443, získá certifikát a dívá se na dobu platnosti. Chcete se dozvědět o vypršení certifikátu 30 dní předem, ne v okamžiku, kdy uživatelé vidí strašlivá varování prohlížeče. V roce 2026 je to obzvlášť aktuální: doby platnosti certifikátů se dál zkracují (CA/Browser Forum odhlasovalo postupné snížení na 47 dní do roku 2029), takže ruční kontrola přestává fungovat.

DNS

Kontrola korektního DNS resolvingu pro vaši doménu z různých lokací. Odhaluje situace, kdy váš DNS poskytovatel má problém v konkrétním regionu a vy o tom nevíte, protože ve vašem regionu vše funguje.

3. Nástroje a přístupy

Trh externího monitoringu je velký a fragmentovaný. Všechna řešení lze rozdělit do tří kategorií: SaaS, self-hosted nebo hybrid. Každá má své výhody a své scénáře použití.

3.1 SaaS: rychlý start bez vlastní infrastruktury

SaaS služby přebírají veškerou infrastrukturní práci: jen se registrujete, zadáte URL ke kontrole, nastavíte alertovací kanály. Probe pointy mají v desítkách zemí, což automaticky dává globální obraz dostupnosti.

Kdy volit SaaS: nemáte samostatného inženýra na self-hosted řešení; chcete rychle nastavit monitoring za 15 minut; váš projekt je malý nebo střední a bezplatný tier stačí; potřebujete kontrolu z reálně globálních lokací (Jižní Amerika, Asie, Oceánie), které je těžké emulovat vlastní infrastrukturou.

Na co si dát pozor: v bezplatných tierech je interval kontrol 3-5 minut, takže o výpadku se dozvíte se zpožděním až 5 minut. Placené tiery (od $7/měs) dávají 30sekundové kontroly. Také počítejte s tím, že sdílíte data o své infrastruktuře s třetí stranou — pro některé regulovaně citlivé obory to může být problém.

3.2 Self-hosted: Prometheus Blackbox Exporter

Pokud už máte nasazený Prometheus pro whitebox monitoring, Blackbox Exporter je přirozené rozšíření. Je to samostatný proces, který provádí HTTP/TCP/ICMP/DNS kontroly a vystavuje výsledky v Prometheus formátu.

Základní konfigurace blackbox.yml:

modules:
  http_2xx:
    prober: http
    timeout: 5s
    http:
      method: GET
      preferred_ip_protocol: "ip4"
      valid_status_codes: [200, 301, 302]
      fail_if_body_not_matches_regexp:
        - "Welcome to Example"

  tcp_connect:
    prober: tcp
    timeout: 5s

  icmp_check:
    prober: icmp
    timeout: 5s

A odpovídající sekce v Prometheu, která scrapuje tento exporter pro konkrétní URL:

scrape_configs:
  - job_name: 'blackbox_http'
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
        - https://example.com
        - https://api.example.com/health
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: blackbox-exporter:9115

Dále alerting přes Alertmanager na metriky probe_success (0 = spadl) a probe_ssl_earliest_cert_expiry (čas do vypršení SSL). Vizualizace přes Grafanu s hotovými dashboardy pro Blackbox Exporter (je jich hodně na grafana.com/dashboards).

Kdy volit: už máte Prometheus stack, máte kompetence na jeho údržbu, chcete jednotný alertovací systém pro whitebox i blackbox.

3.3 Self-hosted: Gatus — lehká YAML alternativa

Gatus je mladší a jednodušší varianta pro ty, kdo nechtějí nasazovat plný Prometheus stack kvůli externímu monitoringu. Jeden Go binárník, konfig v YAML, vestavěné webové rozhraní se status page, alerting přes Slack/Telegram/Discord/PagerDuty/email out of the box.

Konfig config.yaml pro typický monitoring:

endpoints:
  - name: main-website
    url: "https://example.com"
    interval: 60s
    conditions:
      - "[STATUS] == 200"
      - "[RESPONSE_TIME] < 1000"
      - "[CERTIFICATE_EXPIRATION] > 720h"
    alerts:
      - type: telegram
        failure-threshold: 3
        success-threshold: 2

  - name: api-health
    url: "https://api.example.com/health"
    interval: 30s
    conditions:
      - "[STATUS] == 200"
      - "[BODY].status == up"

alerting:
  telegram:
    token: "${TELEGRAM_TOKEN}"
    id: "${TELEGRAM_CHAT_ID}"

To je vše. Spouští se jedním docker run nebo jako systemd služba na VPS, spotřebuje 30-50 MB RAM, dává veřejnou status page pro klienty. V roce 2026 se Gatus stal jedním z nejpopulárnějších open-source řešení právě díky své jednoduchosti.

Kdy volit: nepotřebujete Prometheus, chcete maximálně jednoduchý systém s malým overheadem, zajímá vás veřejná status page pro klienty.

3.4 Hybrid: self-hosted + SaaS pro kritické endpointy

Nejrozumnější přístup pro seriózní produkci. Logika je taková: hlavní masu kontrol děláte self-hosted (levné, kontrolované, dává vám všechna data), a nejkritičtější endpointy se duplikují přes SaaS (fallback pro případ, kdy vaše monitorovací infrastruktura sama není dostupná).

Co se obvykle přesune na SaaS v hybridní schéma:

• Veřejná hlavní stránka: to, co klienti vidí jako první
• Login/auth endpoint: bez něj klienti nemohou dovnitř, i když se stránka otevírá
• Payment page: nejdražší výpadek, tady stojí za to platit za 30sekundové kontroly
• Public API health endpoint: pokud máte veřejné API s SLA

Zbylých 50-200 endpointů běží na self-hosted infrastruktuře, s vlastními dashboardy a plnou kontrolou nad daty.

3.5 Srovnání čtyř přístupů

Univerzální odpověď neexistuje: pro malý projekt je lepší SaaS, pro střední Gatus, pro velký s vlastní infrastrukturou a DevOps týmem sedí hybrid s Prometheem jako základem.

4. Kde fyzicky umístit monitorovacího agenta

Tuto část při nastavování monitoringu často přeskakují, ale právě ona určuje, jak bude monitoring užitečný v okamžiku reálného výpadku.

4.1 Ne na tomtéž serveru, který se monitoruje

Zřejmé, ale porušované pravidlo: monitorovací agent nemá být na serveru, který kontroluje. Pokud u vás aplikace i monitoring běží na jednom VPS, v okamžiku pádu tohoto VPS se nedozvíte nic: monitoring umřel spolu se serverem. To je klasická chyba, kterou dělají i zkušení admini, když „šetří".

4.2 Poskytovatel v jednom datacentru

Pokud je celý váš stack (bojový server, zálohy, monitoring) u jednoho poskytovatele v jednom DC, váš monitoring má slepé místo o velikosti tohoto DC. Pokud u poskytovatele nastane problém se sítí, napájením, chlazením, spadne vám současně server i monitoring — a nikdo vám to neřekne.

Řešení: umístěte monitorovacího agenta na VPS u jiného poskytovatele nebo alespoň v jiném geografickém regionu. Může to být nejlevnější VPS za $3-5/měs, jeho jediným úkolem je periodicky pingat váš bojový server a alertovat, pokud něco není v pořádku. Malé dodatečné riziko se vyplatí v jediném případě, kdy někdy vypálí.

4.3 Poskytovatel v několika DC

Pokud váš poskytovatel má několik datacenter a pronajímáte si servery ve více z nich, situace je zajímavější. Monitorovací agenty lze (a měli byste) umístit v každém DC, aby pokrývaly nejen dostupnost jednotlivých serverů, ale i konektivitu mezi DC. Pak v případě problému uvidíte nejen „server X nedostupný", ale „server X nedostupný z DC Y, ale dostupný z DC Z", což hned ukazuje na povahu problému.

Detaily topologie závisí na konkrétní infrastruktuře. Pokud máte dvě DC, stačí dva probe nody. Pokud čtyři, stojí za to pokrýt každé.

4.4 SaaS monitoring jako poslední záchrana

I s nejdokonalejší vlastní infrastrukturou zůstává scénář, ve kterém je celá najednou nedostupná (katastrofa u poskytovatele, BGP problém celého regionu, nebo prostě masivní výpadek vašeho hlavního DNS poskytovatele). V takovém případě funguje jen SaaS monitoring z externí infrastruktury.

Proto i v plně self-hosted nasazení stojí za to mít alespoň jeden bezplatný UptimeRobot monitoring s email/Telegram alertem, který vypálí jen v případě úplného blackoutu. Jeden free-tier účet stojí nulu, nastavuje se za 5 minut a jednou vás zachrání ze situace, kdy tři hodiny nevíte, že vám vůbec nic nefunguje.

5. Alerting: kanály, prahy, false positives

Nastavit kontroly je jen půl práce. Druhá půle: abyste se o výpadku dozvěděli právě tehdy, kdy je to potřeba, a nedozvídali se tehdy, kdy to potřeba není. Špatný alerting vytváří alertovou únavu, kvůli které se reálné incidenty ztrácejí v proudu false positives.

Kanály doručování

• Email: pomalý (můžete si ho hodiny nevšimnout), ale archiv. Hodí se pro nekritické varování typu „SSL vyprší za 30 dní".
• Telegram / Slack: rychlý, s možností reakcí od kolegů. Standard pro pracovní dobu.
• SMS / telefonní hovor: pro noční incidenty. Placené, ale často jediný způsob, jak spolehlivě „probudit" dozorujícího.
• PagerDuty / Opsgenie: escalation policy, rotace dozorujících, integrace se vším. Pro týmy od 5+ inženýrů.

Pravidlo „tří po sobě"

Nejjednodušší způsob, jak snížit false positives: alert vypálí jen po N po sobě neúspěšných kontrolách. Typická hodnota je 3 po sobě jdoucí selhání s intervalem 1 minuta. O reálném výpadku se dozvíte 3-4 minuty po jeho začátku, ale nedostáváte alerty o náhodných síťových škytnutích trvajících 30 sekund.

Prahy „varování" a „alert"

Ne všechny problémy jsou stejně závažné. Užitečné je mít dvě úrovně:

• Warning: response time vzrostl z 200ms na 1000ms, SSL vyprší za 30 dní, 1-2 po sobě neúspěšné kontroly. Telegram notifikace, bez nočního budíku.
• Critical: 3+ po sobě neúspěšné kontroly, response time >5 sekund, SSL vyprší za 7 dní. Telegram + email + SMS v nočním čase.

Escalation pro dlouhotrvající incidenty

Pokud alert nedostal acknowledgement do 15 minut, eskalace na dalšího dozorujícího nebo team leada. To je základní hygiena pro týmy s noční podporou. Pokud jedna notifikace dozorujícího neprobudila, druhá za 15 minut to udělá s větší pravděpodobností.

6. Minimální produkční schéma

Pokud nemáte čas nebo chuť budovat ideální systém, tady je minimum, pod které se nevyplatí klesat:

Povinné

• Alespoň jeden externí monitorovací agent z jiné lokace (ne u téhož poskytovatele, kde hostuje hlavní služba)
• Kontrola HTTP dostupnosti hlavní stránky a jednoho kritického API endpointu
• Kontrola SSL certifikátu s alertem 30 dní před vypršením
• Alerting alespoň přes dva kanály (Telegram + email)
• Pravidlo „3 po sobě selhání" před alertem (tam, kde se to nastavuje), abyste nereagovali na jednotlivé škytnutí

Vhodné

• 2-3 probe lokace v různých geografiích pro odhalení regionálních problémů
• Dvouúrovňový alerting (warning + critical) s různými kanály doručování
• Veřejná status page pro klienty (Gatus to dělá out of the box)
• Integrace monitoringu s incident managementem (PagerDuty, Opsgenie, nebo alespoň shared inbox)
• Pravidelný review alertů: které vypalovaly často, které nevypaly, kdy měly

Typické chyby

• Probe na tomtéž hostu. První věc, kterou je třeba opravit. Přeneste monitoring pryč z produkčního serveru.
• Příliš agresivní prahy. Alert na 200ms zpoždění bude tlouct celý den a nic nevyřeší.
• Absence escalation. Pokud dozorující neodpověděl, nikdo se to nedozví.
• Jediný kanál doručování. Pokud Telegram spadne spolu s vaším ISP, alert neuvidíte.
• Alerty bez runbooku. Alert „web nedostupný" bez pokynů, co s tím dělat, je půl užitku z monitoringu pryč.

7. Shrnutí

Externí monitoring není alternativou k internímu, ale jeho povinným doplňkem. Whitebox metriky dávají hloubku a pomáhají pochopit příčinu, blackbox kontroly zaručují, že se o výpadku dozvíte nezávisle na stavu serveru. Bez jedné z těchto polovin má váš monitoring slepé místo.

Co si z tohoto článku odnést:

• Probe nemá žít na tomtéž serveru, který se monitoruje. Pokud žije, v okamžiku skutečného výpadku alerty nebudou.
• Interval kontrol 1-5 minut je optimum pro většinu scénářů. 30 sekund dává smysl jen pro kritické e-commerce, 10+ minut je příliš zřídka.
• Pravidlo „3 po sobě selhání před alertem" zabíjí většinu false positives a nepropouští reálné incidenty.
• Dvouúrovňový alerting (warning + critical s různými kanály) je hygiena, ne overkill.
• SSL kontrola s prahem 30 dní je nejlevnější a nejužitečnější věc, která vás jednou zachrání před strašlivými varováními prohlížeče u klientů.

Další úroveň nezávislosti na OS, ke které stojí za to jít po nastavení externího monitoringu, je out-of-band management přes IPMI, iDRAC nebo iLO. To jsou hardwarová rozhraní na základní desce, která fungují nezávisle na hlavním OS: umožňují vidět konzoli i tehdy, když server „umřel", restartovat ho, vzdáleně připojovat ISO obrazy. Téma je velké a zaslouží si samostatný materiál.

Časté dotazy