Моніторинг часу відгуку

Чому час відповіді заслуговує на окремий алерт

Стандартні алерти аптайму ґрунтуються на бінарному сигналі: up або down. Сіра зона між ними — up, але повільно — це саме те місце, де відбувається більшість сучасних збоїв. Неправильно налаштований запит до бази даних починає тривати 4 секунди замість 50 мс. Витік пам’яті спричиняє стрибки garbage collection. Зовнішнє API, до якого звертається бекенд, починає нестабільно працювати. Жодна з цих причин не ламає сайт повністю, але робить його непридатним до використання — і це ранні сигнали аварії, яка трапиться через годину або дві.

Моніторинг часу відповіді фіксує уповільнення до того, як воно стане аварією. Ви налаштовуєте поріг для кожного монітора, і якщо час відповіді перевищує його в кількох поспіль перевірках — отримуєте сповіщення. Перед тим, як алерт буде надіслано, у вас ще є запас часу розібратись у ситуації, додати ресурсів, обмежити проблемний виклик або відкотити деплой, який це спричинив.

Як працюють пороги в DiagnoSEO Uptime Monitoring

Кожен монітор можна налаштувати з двома параметрами: rt_threshold_ms і rt_threshold_breaches. Перший — це час відповіді у мілісекундах, який ви вважаєте прийнятним. Другий — скільки послідовних перевірок має його перевищити, щоб був алерт. За замовчуванням поріг вимкнено, а кількість перевищень — три.

Двопараметричний дизайн захищає від хибнопозитивних сповіщень. Мережевий джиттер трапляється. Пауза під час збірки сміття також. Одиничний стрибок до 1 секунди на тлі 200 мс не вартий дзвінка о 3 ночі. Але три підряд 1-секундні відповіді — це вже стабільне уповільнення, а не випадковість. Обирайте поріг, базуючись на спостережуваній нормальній поведінці плюс безпечний запас: якщо p95 зазвичай 400 мс — поріг 1000 мс. Якщо p95 — 50 мс (внутрішнє API), поріг 200 мс.

З чим добре поєднується

Алерти часу відповіді дають найкращий результат у комбінації з іншими сигналами монітора. Повна картина: поріг часу відповіді сигналізує, що система деградує; HTTP-код показує, коли дійсно ламається; попередження SSL/домену — про аварії, пов’язані з сертифікатами; алерти змін DNS — про дрейф конфігурації. Разом чотири сигнали на одному моніторі перетворюють бінарне "чи працює" на повноцінну observability.

Дашборд теж у цьому допомагає. Кожен монітор показує sparkline останніх значень часу відповіді — швидкий візуальний індикатор патернів деградації. Розгорнутий перегляд показує середні значення за 24 години, 7 діб і 30 днів. Якщо бачите середнє значення, що повзе вгору з тижня в тиждень — це ранній сигнал, вартий перевірки до перевищення алертового порога.

Практичні пороги за типом сторінки

• Маркетингові лендинги: 1500 мс — розумний показник. Вони важкі зображеннями і скриптами-трекерами; абсолютна швидкість менш важлива, ніж стабільність.
• Продуктові сторінки/категорії ecommerce: 800–1200 мс. Повільний ecom вбиває конверсії; тісніші пороги швидше фіксують проблеми.
• Дашборди додатків: 500–800 мс. Користувачі чекають миттєвої реакції. Повільні дашборди створюють ефект поламки продукту.
• Публічні API: 200–400 мс для простих endpoint-ів, вище — для більш складних. Розділіть їх по категоріях.
• Внутрішні health check-и мікросервісів: 50–100 мс. Мають бути майже миттєвими; повільність майже завжди свідчить про реальну проблему.

Що б ви не обрали, не зупиняйтесь на одному разі й не забувайте. Переоцінюйте квартально з урахуванням фактичних трендів. Якщо ви постійно отримуєте алерти про перевищення, які не є реальними проблемами — поріг надто суворий. Якщо виникає аварія без попереднього алерту про перевищення — поріг був надто лояльний.

Маршрутизація алертів

Алерти про перевищення порогу надсилаються тими ж каналами, що й алерти про відновлення/втрату доступу: Email, Telegram, Slack, Discord, SMS. Вони враховують той самий нічний режим. Логуються у тій самій таблиці алертів. Єдина різниця — тип події ("threshold" замість "down") і зміст повідомлення: він містить актуальний час відповіді та налаштований поріг, тож ви одразу бачите розмір перевищення.

Налаштування

Відредагуйте будь-який монітор. У формі встановіть "Поріг часу відповіді (мс)" на потрібне значення. За бажанням змініть "послідовні перевищення", якщо типове значення 3 не підходить до вашої толерантності. Збережіть. Від наступного циклу кожна перевірка порівнює час відповіді з порогом, і після налаштованої кількості перевищень ви отримуєте повідомлення.

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

• Яка метрика часу відповіді реєструється?

  Time To First Byte (TTFB) — мілісекунди між надсиланням запиту та отриманням першого байта відповіді. Плюс загальний час отримання повної відповіді. TTFB — найкорисніша окрема метрика для здоров’я сервера.

• Який "гарний" час відповіді?

  Залежить від локації та вмісту. Для статичної сторінки з CDN: нижче 100 мс — чудово, нижче 300 мс — добре. Для динамічних додатків: нижче 500 мс — добре, нижче 1000 мс — прийнятно, вище 2000 мс уже виглядає повільно. Порівнюйте зі своїми історичними показниками, а не абсолютними числами.

• Чи можу я отримати алерт, якщо час відповіді перевищить поріг?

  Так. Кожен монітор має опціональний поріг часу відповіді. Якщо 3 підряд перевірки перевищать поріг, ви отримаєте алерт "повільна відповідь". Вимога в 3 перевірки захищає від хибних сповіщень через одноразові мережеві збої.

• Звідки вимірюється час відповіді?

  З наших 13 географічних точок перевірок (Європа, Північна Америка, Азія, Південна Америка, Океанія). Для монітора single-region час береться із найближчого регіону. Для multi-region кожен регіон вимірюється окремо — корисно для виявлення регіональних проблем CDN.

• Чи показує дашборд тренди часу відповіді?

  Так — 30-денна ковзна середня, денні max/min та перцентилі (p50, p95). Корисно для планування ємності: якщо p95 зріс з 800 мс до 1500 мс за місяць, ваші сервери перевантажуються навіть якщо uptime % залишився 100%.