Menu
security

Uptime 101: як налаштувати базовий моніторинг і алерти для вашого сайту

Аптайм – не магія, а дисципліна. Його забезпечують дві речі: спостережність (ви бачите, що відбувається) і оповіщення (ви дізнаєтеся про проблему раніше за користувача). Базовий моніторинг – це мінімальний набір перевірок і метрик, які цілодобово стежать за сайтом та інфраструктурою і сигналять у потрібний канал, коли щось іде не так.

Мета матеріалу – дати практичний, приземлений план. Без перевантаження термінами, але з конкретними чек‑листами, прикладами алертів і порадами щодо порогів. Підійде власникам сайтів, техлідерам невеликих команд, розробникам і DevOps‑інженерам, які хочуть «закрити базу» за один вечір і спати спокійніше.

Як це працює (мінімум теорії)

Blackbox vs Whitebox

  • Blackbox‑моніторинг – ви дивитеся на систему ззовні, як користувач: ping, TCP/HTTP‑перевірки, час відповіді, чинність TLS‑сертифіката, DNS. Це відповідає на питання: «Чи живий сайт з точки зору клієнта?»
  • Whitebox‑моніторинг – ви заглядаєте всередину: CPU/RAM/Disk/IO, мережа, кількість відкритих файлів, пула підключень до БД, помилки застосунку, метрики веб‑сервера, черги задач. Це відповідає на питання: «Чому стало погано?»

Потрібні обидва підходи: blackbox дає швидкий сигнал, whitebox – контекст для усунення причин.

Метрики, логи, трейси

  • Метрики – числа в часі (наприклад, p95 часу відповіді, відсоток 5xx, утилізація CPU). Вони компактні та ідеальні для алертів.
  • Логи – деталі подій. Корисні для розслідування інциденту (stack trace, IP клієнта, шлях запиту).
  • Трейси – шлях запиту через сервіси; допомагають знайти вузьке місце (БД, зовнішнє API).

Для старту достатньо метрик + логів. Трейси можна додати пізніше.

SLI, SLO і бюджет помилки

  • SLI (Service Level Indicator) – вимірювана величина якості: частка успішних запитів, p95 латентності, аптайм за період.
  • SLO (Service Level Objective) – ціль по SLI (наприклад, «99,9% успішних запитів і p95 < 300 мс за 30 днів»).
  • Бюджет помилки – скільки «поганих» запитів/хвилин простою можна «витратити» в періоді, не зламавши SLO. На його основі будується пріоритет робіт і агресивність релізів.

Чому це важливо (і з чого почати)

1) Ви дізнаєтеся про проблему раніше за користувачів

Push‑алерт у хвилину деградації дешевший, ніж година втраченої конверсії й кошиків. Проста HTTP‑перевірка з кількох регіонів помітить падіння швидше, ніж потік скарг у підтримку.

2) Ви зменшуєте MTTR

Середній час відновлення (MTTR) падає, якщо алерт веде на зрозумілий дашборд і плейбук: «що перевірити, де логи, як перезапустити, як відкотитися снапшотом».

3) Ви перестаєте «боятися релізів»

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

4) Ви рахуєте економіку на фактах

Зі спостережністю легко порівняти: «перехід на NVMe», «новий кеш», «оптимізація SQL» – що реально дало приріст і окупилося.

Що моніторити: базовий чек‑лист

A. Доступність і периметр

  1. DNS: A/AAAA/CNAME резолвляться? TTL адекватний? Є аварійні NS?
  2. ICMP Ping: хост відповідає? Зростають RTT/втрати пакетів?
  3. TCP/порт: 80/443/ваші сервісні порти відкриті й приймають з’єднання?
  4. HTTP/HTTPS: код 2xx/3xx, час TTFB/p95, розмір відповіді, ключові слова на сторінці (перевірка контенту).
  5. TLS‑сертифікат: строк дії, ланцюжок, відповідність домену; алерт за 30/14/7 днів до завершення.
  6. WAF/DDoS‑щит: змін правил немає? Немає блокування легітимного трафіку?

B. Застосунок

  1. Error rate: частка 5xx/4xx (фокус на 5xx) > порога X% за N хвилин.
  2. Латентність: p95/p99 сторінок або API – пороги за SLO (наприклад, p95 < 300 мс).
  3. Критичні ендпоїнти: /healthz, /readyz, /login, /checkout, RPC/GraphQL‑методи.
  4. Черги: глибина та вік задач (email/SMS, фон).
  5. Кеш: hit‑ratio нижчий за Y%? Пули з’єднань до БД.

C. Інфраструктура (whitebox)

  1. CPU: утилізація, steal time (на віртуалках), навантаження на ядро.
  2. RAM: вільно/кешовано, page cache, OOM‑івенти.
  3. Диск/FS: заповнення > 80–90%, inodes, IOPS/latency, окремий том під логи/журнали.
  4. Мережа: помилки/дропи, PPS, bandwidth, SYN backlog, ESTABLISHED/WAIT.
  5. Процеси: systemd‑юнити впали? Перезапустилися?
  6. БД: реплікація, затримки, довгі запити, блокування.

D. Залежності

  1. Платіжні/поштові/geo‑API: SLA провайдера, HTTP‑помилки/таймаути.
  2. Об’єктне сховище/CDN: латентність/помилки PUT/GET, egress.
  3. Черги/кеші: доступність і ріст затримок.

E. Бек‑офіс

  1. Бекапи: свіжість, розмір, контроль відновлення.
  2. Снапшоти: за розкладом і перед релізами.
  3. Cron/планувальники: регулярність, помилки у журналі.
  4. Аудит доступу: підозрілі логіни, sudo, зміни правил фаєрвола.

Порогові значення: як не втонути у фальшивих тривогах

  1. Тиша вночі ≠ тиша вдень. Налаштуйте різні пороги для офф‑піку і піку (або використовуйте відносні пороги: «вище середнього на 50% протягом 10 хвилин»).
  2. Дедуплікація та групування. Одна відмова БД не має сипати 20 алертів від усіх сервісів. Групуйте за кореневою причиною (root cause).
  3. Перевірка з кількох локацій. Один фолс‑позитив із вузла моніторингу не повинен будити чергового. Вимагайте 2/3 «згодних» перевірок.
  4. Затримка оповіщення (grace). 30–60 секунд перед «червоним» алертом відсіюють короткочасний шум.
  5. Вікна техробіт. Правила «мовчання» на час релізів і регламентних робіт.
  6. Шаблони повідомлень. В алерті одразу має бути посилання на дашборд, останні деплоя, плейбук із «першою допомогою».

Канали доставки алертів

  • Email – для несрочних повідомлень і звітів (щоденні/щотижневі дайджести).
  • Месенджери (Slack/Telegram/Discord) – для оперативної команди: канали #alerts, треди по інцидентах, реакції‑квитування.
  • SMS/дзвінок – для критичних інцидентів поза робочим часом (ескалації черговому).
  • Вебхуки – інтеграції зі сторонніми системами (дашборди статусу, тікет‑системи, CI/CD).

Налаштуйте ескалації: якщо немає підтвердження алерта за N хвилин – він іде на вищий рівень. Це захищає від «залипання» тривог.

Практика: базовий стек спостережності

Нижче – один із мінімальних, але робочих наборів інструментів на відкритому ПЗ.

  1. Node Exporter – віддає системні метрики (CPU/RAM/Disk/Net).
  2. Blackbox Exporter – ping/TCP/HTTP‑перевірки ззовні (TLS, пошук ключових слів).
  3. Prometheus – збирає метрики, зберігає часові ряди.
  4. Alertmanager – правила алертів, маршрутизація, дедуплікація, ескалації.
  5. Grafana – дашборди й аннотації релізів.
  6. Filebeat/Vector + ELK/OpenSearch – збір і пошук логів.
  7. Healthcheck‑ендпоїнти – /healthz (життя), /readyz (готовність до трафіку), /metrics (whitebox‑метрики застосунку).

Шаблон правила алерта (Prometheus Alerting)

Заповніть під свій сервіс: – Назва: HighErrorRate – Умова: «частка відповідей 5xx за останні 5 хвилин > 5% по агрегату service» – Вікно утримання: 10 хвилин (захист від коротких сплесків) – Критичність: severity = critical – Повідомлення: {{service}}: 5xx > 5% (10m) – Runbook: посилання на вашу сторінку «як розслідувати високий error rate»

Як перевірити: відкрийте графік частки 5xx за 1–7 днів і підберіть поріг, за якого шум мінімальний, а інциденти ловляться вчасно.

Перевірка TLS‑сертифіката (Blackbox)

Параметри перевірки: – Протокол: HTTPS із очікуванням коду 2xx – Таймаут: 10 секунд – Версії HTTP: HTTP/1.1 і HTTP/2 – Перевірка ланцюжка TLS: увімкнено (сертифікат не прострочений і відповідає домену)

Практика: налаштуйте три зовнішні точки моніторингу в різних регіонах і додайте окремий алерт за 30/14/7 днів до завершення сертифіката.

Алерт на вільне місце на диску

Шаблон правила: – Назва: LowDiskSpace – Умова: «вільне місце на файловій системі < 10%» (виключаючи tmpfs/devtmpfs) – Вікно утримання: 15 хвилин (щоб відсікти короткі піки) – Критичність: warning (підніміть до critical при <5%) – Повідомлення: INSTANCE: <10% вільного диску – очистіть логи/артефакти або збільшіть том – Підказка: перевірте ротацію логів, розмір кешів, винесіть артефакти в об’єктне сховище

Покроковий план на один вечір

Крок 1. Визначте SLO. Наприклад: «аптайм 99,9% за 30 днів; p95 < 300 мс; 5xx < 1%».

Крок 2. Виберіть точки перевірки. 3–5 географій (Європа/США/Азія), по одній на кожен ключовий ендпоїнт (головна, логін, checkout, API‑метод).

Крок 3. Підніміть healthchecks. Додайте /healthz і /readyz у застосунок; перевірка має залежати від БД/кешу, якщо без них сервіс не працює.

Крок 4. Розгорніть стек. Prometheus + Node/Blackbox Exporter, Grafana, Alertmanager. Імпортуйте готові дашборди.

Крок 5. Напишіть 10 ключових алертів. Доступність HTTP, закінчення TLS, 5xx>1–5%, p95>порога, CPU>85% (10 хв), RAM<15% вільно, диск<15%, БД‑реплікація/лаг, черга задач, ріст помилок у логах.

Крок 6. Налаштуйте канали і ескалації. Slack/Telegram + Email + SMS для «червоних». Додайте «тихі години» і вікна техробіт.

Крок 7. Зробіть сторінку статусу. Зовнішню (public) + внутрішню (детально для команди). Автооновлення від Alertmanager.

Крок 8. Проведіть «гру хаосу». Навмисно «уроніть» залежність (наприклад, вимкніть кеш) – перевірте, що алерти прийшли і плейбук зрозумілий.

Крок 9. Заведіть плейбуки. Для кожного алерта – 5–10 кроків діагностики та рішень + контакти відповідальних.

Крок 10. Переглядайте пороги раз на місяць. На основі реальних графіків та інцидентів.

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

  • Занадто багато алертів. Слабкі сигнали забивають сильні. Тримайте компактний набір «червоних» і «жовтих» правил; решта – звіти.
  • Алерти без контексту. Завжди додавайте посилання на дашборд і плейбук. «CPU високий» без графіка – марно.
  • Немає перевірки контенту. HTTP 200 не гарантує, що рендериться правильна сторінка. Шукайте ключове слово/патерн.
  • Один регіон моніторингу. «Ямка» мережі в одному ДЦ дасть фальшсигнали. Потрібні незалежні точки.
  • Все в одному VPS. Моніторинг краще тримати окремо від застосунку, інакше «все впало – ніхто не побачив».
  • Без DR і бекапів. Бекап, який ви не відновлювали, – не бекап. Тестуйте відновлення.

Чому з Unihost простіше тримати аптайм

Мережа та інфраструктура. Низька p95‑латентність завдяки пірингам, DDoS‑фільтрація, приватні VLAN, IPv4/IPv6, передбачуваний uplink. Це зменшує шанс хибних тривог і спрощує ізоляцію prod/stage/dev.

Сховище. Швидкі NVMe Gen4/Gen5 для БД/індексів і логів: стабільні IOPS = менше «мікроінцидентів».

Платформа. Підтримка IaC (Terraform/Ansible), снапшоти/бекапи за політикою, інтеграції з Prometheus/Grafana/ELK/OTel.

Супровід. 24/7 моніторинг майданчиків, SLA за реакцією та аптаймом; допомога інженерів у тюнінгу ядра/мережі/БД і налаштуванні healthcheck‑ендпоїнтів.

Масштабування. Стартуйте на VPS, переходьте на виділені сервери та GPU‑вузли без зміни провайдера і з мінімальними переробками – моніторинг переїде разом з IaC.

Короткий шаблон запуску (TL;DR)

  • Blackbox: HTTP/HTTPS з 3 локацій, TLS‑expiry, DNS.
  • Whitebox: Node Exporter + метрики застосунку /metrics.
  • Алерти: 5xx, p95, CPU/RAM/Disk, TLS, БД, черга.
  • Канали: Slack/Telegram + Email + SMS для критичних.
  • Плейбуки і сторінка статусу.
  • Щомісячний розбір інцидентів і корекція порогів.

Висновок і CTA

Базовий моніторинг – не розкіш і не «ще один проєкт». Це страховка вашого доходу і репутації. Почніть сьогодні: додайте healthchecks, підніміть метрики, зберіть перші алерти та підключіть канали. За тиждень матимете першу статистику, за місяць – впевненість, що сайт переживе пік, реліз і каприз зовнішнього API.

Unihost допоможе пройти шлях швидко й без болю: підібрати конфігурації (VPS або виділені сервери), налаштувати мережу і сховище, увімкнути спостережність і алерти, автоматизувати снапшоти/бекапи та підготувати DR‑план.

Спробуйте сервери Unihost – стабільна інфраструктура для ваших проєктів.
Замовляйте VPS або виділений сервер на Unihost і підніміть аптайм на новий рівень – з метриками, алертами та зрозумілою експлуатацією.