Blackbox моніторинг у 2026: UptimeRobot, Gatus, Blackbox Exporter та коли який обирати

Зовнішній моніторинг доступності сервера: як дізнатись про проблему раніше за користувача

Стандартна процедура для серйозного продакшну: на сервері крутиться агент (Prometheus node_exporter, Zabbix agent, Netdata, Datadog), який збирає метрики CPU, RAM, диску, мережі. Все логується, є гарні дашборди, налаштовані алерти. Здавалося б, повний контроль.

Аж до того моменту, коли ОС зависає, мережевий стек відмовляє, або сервер ловить kernel panic. Агент мовчить, бо мовчить весь сервер. Дашборди показують останній стан до збою. Алертів немає. Користувач, який обновляє вашу головну сторінку і бачить 408 Request Timeout (або взагалі connection refused), дізнається про проблему швидше, ніж ви.

Це класичний сліпий кут whitebox-моніторингу: він бачить багато всередині, але не бачить нічого, коли «всередині» немає кого спитати. Зовнішній моніторинг (blackbox) закриває цю діру з протилежного боку, перевіряючи доступність сервера ззовні, незалежно від його стану.

1. Blackbox vs whitebox — два кути зору

Whitebox-моніторинг бачить сервер «зсередини»: знає про процеси, метрики ядра, дисковий I/O, мережеві з'єднання, логи додатків. Він глибокий, точний, дає змогу не просто констатувати проблему, а зрозуміти її причину.

Blackbox-моніторинг бачить сервер так, як його бачить користувач: чи відкривається сторінка, чи відповідає API, чи валідний SSL-сертифікат, скільки часу займає TCP-рукостискання. Він поверхневий, не каже нічого про причини, але має одну унікальну властивість: працює навіть тоді, коли whitebox мовчить.

Висновок очевидний: ці два підходи не замінюють один одного, а доповнюють. Whitebox каже «чому щось не працює». Blackbox каже «не працює». Кожен сам по собі залишає сліпі плями. Разом вони закривають більшість реальних сценаріїв збою.

2. Що саме перевіряти ззовні

Перш ніж обговорювати інструменти, треба розуміти набір базових перевірок, з яких складається будь-який зовнішній моніторинг.

HTTP/HTTPS

Базова перевірка для веб-сервісів. Агент моніторингу робить GET-запит на ваш endpoint і дивиться:

• HTTP-код фінальної відповіді (нормально, коли 200; перед ним можуть бути 3xx-редиректи, це не проблема. А ось 4xx або 5xx як кінцевий код — або у ланцюгу після 3xx — це збій)
• Час відповіді (повільнішає, ще до повної відмови видає попередження)
• Наявність ключового слова у відповіді (наприклад, фрагменту тексту вашої головної сторінки, щоб виключити випадок «віддає не те»)
• Валідність HTTP-заголовків (наприклад, redirect chains, cache-control)

TCP-порт

Для нестандартних сервісів: SSH (22), SMTP (25, 465, 587), IMAP (143, 993), бази даних (5432, 3306, 27017), кастомні API на нетипових портах. Агент намагається відкрити TCP-з'єднання і дивиться, чи відповідає сервер SYN-ACK.

ICMP (ping)

Найпростіша перевірка: «чи живий хост на мережевому рівні». Корисна як швидкий індикатор, але обмежена: багато провайдерів і CDN блокують ICMP за замовчуванням, тому false-positive «ping не пройшов = сервер впав» — типова помилка новачків.

SSL-сертифікат

Окрема, недооцінена перевірка. Агент моніторингу підключається до 443 порту, отримує сертифікат і дивиться на термін придатності. Ви хочете дізнатися про закінчення сертифіката за 30 днів, а не у момент, коли користувачі бачать страшні попередження браузера. У 2026 році це особливо актуально: терміни сертифікатів продовжують скорочуватися (CA/Browser Forum проголосував за поетапне зниження до 47 днів до 2029), тому ручний контроль перестає працювати.

DNS

Перевірка коректності DNS-резолвінгу для вашого домену з різних локацій. Виявляє ситуації, коли ваш DNS-провайдер має проблему у конкретному регіоні, а ви про це не знаєте, бо у вашому регіоні все працює.

3. Інструменти та підходи

Ринок зовнішнього моніторингу великий і фрагментований. Усі рішення можна поділити на три категорії: SaaS, self-hosted, або гібрид. Кожна має свої переваги і свої сценарії застосування.

3.1 SaaS: швидкий старт без своєї інфраструктури

SaaS-сервіси беруть на себе всю інфраструктурну роботу: ви тільки реєструєтесь, вводите URL для перевірки, налаштовуєте канали алертингу. Probe-точки у них є у десятках країн, що автоматично дає глобальну картину доступності.

Коли обирати SaaS: у вас немає окремого інженера для self-hosted рішень; ви хочете швидко налаштувати моніторинг за 15 хвилин; ваш проект малий або середній і безкоштовного tier вистачить; вам потрібна перевірка з реально глобальних локацій (Південна Америка, Азія, Океанія), які складно емулювати власною інфраструктурою.

Чого варто остерігатися: у безкоштовних tier інтервал перевірок 3-5 хвилин, тобто ви дізнаєтесь про збій з затримкою до 5 хвилин. Платні tier (від $7/міс) дають 30-секундні перевірки. Також врахуйте, що ви ділитеся даними про свою інфраструктуру з третьою стороною — для деяких регуляторно чутливих галузей це може бути проблемою.

3.2 Self-hosted: Prometheus Blackbox Exporter

Якщо у вас уже розгорнутий Prometheus для whitebox-моніторингу, Blackbox Exporter — це природне розширення. Це окремий процес, який виконує HTTP/TCP/ICMP/DNS-перевірки і експонує результати в Prometheus-форматі.

Базова конфігурація 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

І відповідна секція у Prometheus, яка scrape-ить цей exporter для конкретних 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

Далі алертинг через Alertmanager на метрики probe_success (0 = впав) і probe_ssl_earliest_cert_expiry (час до закінчення SSL). Візуалізація через Grafana з готовими дашбордами для Blackbox Exporter (їх багато на grafana.com/dashboards).

Коли обирати: у вас уже є Prometheus-стек, є компетенції на його супровід, ви хочете єдину систему алертингу для whitebox і blackbox.

3.3 Self-hosted: Gatus — легка YAML-альтернатива

Gatus це молодший і простіший варіант для тих, хто не хоче розгортати повний Prometheus-стек заради зовнішнього моніторингу. Один Go-бінарник, конфіг у YAML, вбудована веб-морда зі status-page, алертинг через Slack/Telegram/Discord/PagerDuty/email з коробки.

Конфіг config.yaml для типового моніторингу:

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}"

Усе. Запускається одним docker run або як systemd-сервіс на VPS, споживає 30-50 МБ RAM, дає публічний status-page для клієнтів. У 2026 році Gatus став одним з найпопулярніших open-source рішень саме завдяки простоті.

Коли обирати: вам не потрібен Prometheus, ви хочете максимально просту систему з малим overhead, цікавить публічна status-page для клієнтів.

3.4 Гібрид: self-hosted + SaaS для критичних endpoint

Найрозсудливий підхід для серйозних продакшнів. Логіка така: основну масу перевірок робите self-hosted (дешево, контрольовано, дає всі дані вам), а найкритичніші endpoint дублюються через SaaS (fallback на випадок, коли ваша моніторингова інфраструктура сама недоступна).

Що зазвичай виноситься на SaaS у гібридній схемі:

• Публічна головна сторінка: те, що клієнти бачать першим
• Login/auth endpoint: без нього клієнти не можуть зайти, навіть якщо сайт відкривається
• Payment page: найдорожчий простой, тут варто платити за 30-секундні перевірки
• Public API health-endpoint: якщо у вас публічне API з SLA

Решта 50-200 endpoint крутиться на self-hosted інфраструктурі, з власними дашбордами і повним контролем над даними.

3.5 Порівняння чотирьох підходів

Універсальної відповіді немає: малому проєкту краще SaaS, середньому Gatus, великому з власною інфраструктурою і командою DevOps підійде гібрид з Prometheus як основою.

4. Де фізично розміщувати агент моніторингу

Це частина, яку часто пропускають при налаштуванні моніторингу, але саме вона визначає, наскільки моніторинг буде корисним у момент реального збою.

4.1 Не на тому ж сервері, який моніториться

Очевидне, але порушуване правило: агент моніторингу не повинен бути на сервері, який він перевіряє. Якщо у вас і додаток, і моніторинг крутяться на одному VPS, то у момент збою цього VPS ви не дізнаєтеся нічого: моніторинг вмер разом із сервером. Це класична помилка, яку роблять навіть досвідчені адміни, коли «економлять».

4.2 Хостер в одному дата-центрі

Якщо весь ваш стек (бойовий сервер, бекапи, моніторинг) у одного провайдера в одному ДЦ, ваш моніторинг має сліпу пляму розміром у цей ДЦ. Якщо у провайдера буде проблема з мережею, живленням, охолодженням, у вас одночасно впадуть і сервер, і моніторинг — і ніхто вам про це не скаже.

Рішення: розмістіть агент моніторингу на VPS у іншого провайдера або хоча б в іншому географічному регіоні. Це може бути найдешевший VPS за $3-5/міс, його єдина задача — періодично пінгувати ваш бойовий сервер і алертити, якщо щось не так. Цей малий додатковий ризик окупається у єдиному випадку, коли він колись спрацює.

4.3 Хостер у кількох ДЦ

Якщо ваш провайдер має кілька дата-центрів і ви орендуєте сервери у кількох з них, ситуація цікавіша. Агенти моніторингу можна (і варто) розмістити у кожному ДЦ, щоб охоплювати не тільки доступність окремих серверів, а й зв'язність між ДЦ. Тоді у разі проблеми ви побачите не просто «сервер X недоступний», а «сервер X недоступний з ДЦ Y, але доступний з ДЦ Z», що одразу вказує на природу проблеми.

Деталі топології залежать від конкретної інфраструктури. Якщо у вас два ДЦ, досить двох probe-нод. Якщо чотири, варто покрити кожен.

4.4 SaaS-моніторинг як останній рубіж

Навіть з найдосконалішою власною інфраструктурою лишається сценарій, у якому її вся одночасно недоступна (катастрофа у провайдера, BGP-проблема цілого регіону, навіть просто масовий збій вашого основного DNS-провайдера). У такому випадку працює тільки SaaS-моніторинг з зовнішньої інфраструктури.

Тому навіть у повністю self-hosted установці варто мати хоча б один безкоштовний UptimeRobot-моніторинг з email/Telegram-алертом, який спрацьовує лише у разі повного блекауту. Один free-tier акаунт коштує нуль, налаштовується за 5 хвилин, і одного разу врятує вас від ситуації, коли ви три години не знаєте, що у вас взагалі нічого не працює.

5. Алертинг: канали, пороги, false positive

Налаштувати перевірки, це лише половина роботи. Друга половина: щоб про збій ви дізналися саме тоді, коли треба, і не дізнавалися тоді, коли не треба. Поганий алертинг створює алертну втому, через яку реальні інциденти губляться у потоці false positive.

Канали доставки

• Email: повільний (можна не побачити годинами), але архів. Підходить для не-критичних попереджень типу «SSL спливає за 30 днів».
• Telegram / Slack: швидкий, з можливістю reaction від колег. Стандарт для робочого часу.
• SMS / телефонний дзвінок: для нічних інцидентів. Платні, але часто єдиний спосіб гарантовано «розбудити» чергового.
• PagerDuty / Opsgenie: escalation policy, ротація чергових, інтеграція з усім. Для команд від 5+ інженерів.

Правило «трьох поспіль»

Найпростіший спосіб зменшити false positive: алерт спрацьовує лише після N поспіль невдалих перевірок. Типове значення це 3 поспіль збої з інтервалом 1 хвилина. Ви дізнаєтесь про реальний збій через 3-4 хвилини після його початку, але не отримуєте алертів про випадкові мережеві гикавки тривалістю 30 секунд.

Пороги «обережно» і «алерт»

Не всі проблеми однакової серйозності. Корисно мати два рівні:

• Warning: час відповіді виріс з 200мс до 1000мс, SSL спливає за 30 днів, 1-2 поспіль невдалі перевірки. Telegram-сповіщення, без нічного будильника.
• Critical: 3+ поспіль невдалі перевірки, час відповіді >5 секунд, SSL спливає за 7 днів. Telegram + email + SMS у разі нічного часу.

Escalation для тривалих інцидентів

Якщо алерт не отримав acknowledgement за 15 хвилин, ескалація на наступного чергового або на тимліда. Це базова гігієна для команд, у яких є нічна підтримка. Якщо чергового не змогло «розбудити» одне сповіщення, друге через 15 хвилин зробить це з більшою ймовірністю.

6. Мінімальна схема для продакшну

Якщо у вас немає часу або бажання будувати ідеальну систему, ось мінімум, нижче якого опускатися не варто:

Обов'язково

• Хоча б один зовнішній моніторинговий агент з іншої локації (не з того ж провайдера, де хоститься основний сервіс)
• Перевірка HTTP-доступності головної сторінки і одного критичного API endpoint
• Перевірка SSL-сертифіката з алертом за 30 днів до закінчення
• Алертинг хоча б через два канали (Telegram + email)
• Правило «3 поспіль збої» перед алертом (там, де це налаштовується), щоб не реагувати на одиничні гикавки

Бажано

• 2-3 probe-локації у різних географіях для виявлення регіональних проблем
• Двохрівневий алертинг (warning + critical) з різними каналами доставки
• Публічна status-page для клієнтів (Gatus це робить з коробки)
• Інтеграція моніторингу з incident management (PagerDuty, Opsgenie, або хоча б shared inbox)
• Регулярний review алертів: які спрацьовували часто, які не спрацьовували коли мали б

Типові помилки

• Probe на тому ж хості. Перше що повинно бути виправлене. Виносьте моніторинг геть з production-серверу.
• Занадто агресивні пороги. Алерт на 200мс затримку буде бити цілий день і нічого не вирішить.
• Відсутність escalation. Якщо черговий не відповів, ніхто не дізнається.
• Один канал доставки. Якщо Telegram впаде разом із вашим інтернет-провайдером, ви не побачите алерт.
• Алерти без runbook. Алерт «сайт недоступний» без вказівки що з цим робити, це половина користі від моніторингу.

7. Підсумок

Зовнішній моніторинг це не альтернатива внутрішньому, а його обов'язкове доповнення. Whitebox-метрики дають глибину і допомагають зрозуміти причину, blackbox-перевірки гарантують, що про збій ви дізнаєтесь незалежно від стану сервера. Без однієї з цих половин ваш моніторинг має сліпу пляму.

Що варто запам'ятати з цієї статті:

• Probe не повинен жити на тому самому сервері, який моніториться. Якщо живе, у момент справжнього збою алертів не буде.
• Інтервал перевірок 1-5 хвилин це оптимум для більшості сценаріїв. 30 секунд має сенс тільки для критичних e-commerce, 10+ хвилин занадто рідко.
• Правило «3 поспіль збої перед алертом» вбиває більшість false positive і не пропускає реальні інциденти.
• Дворівневий алертинг (warning + critical з різними каналами) це гігієна, а не overkill.
• SSL-перевірка з порогом 30 днів, найдешевша і найкорисніша річ, яка одного разу врятує вас від страшних попереджень браузера у клієнтів.

Наступний рівень незалежності від ОС, до якого варто йти після налаштування зовнішнього моніторингу, це out-of-band керування через IPMI, iDRAC або iLO. Це апаратні інтерфейси на материнській платі, які працюють незалежно від основної ОС: дозволяють бачити консоль навіть коли сервер «вмер», перезавантажувати його, монтувати ISO-образи віддалено. Тема велика і заслуговує окремого матеріалу.

Часті питання