Моніторинг сайту, що підтверджує простій, перш ніж розбудити вас

Що насправді робить одна HTTP-перевірка

Спочатку Tenium визначає адресу вашого хоста й відхиляє приватні та внутрішні адреси. Потім відкриває з’єднання з отриманою адресою й надсилає простий запит: обраний вами метод (за замовчуванням GET), заголовок Accept зі значенням */*, без стиснення, з User-Agent Tenium-Monitor/1.0 і посиланням на нашу сторінку про бота. Тіло відповіді читається приблизно до 1 МБ. Коли воно отримане повністю, таймер зупиняється, і цей час записується як час відповіді. Тож це «час до повної сторінки», а не до першого байта, і він ближчий до того, скільки насправді чекає відвідувач.

Результат оцінюється за трьома ознаками: чи входить код відповіді в очікуваний діапазон, чи вклався запит у таймаут і, для https-адрес, чи завершилося TLS-рукостискання. Дата закінчення сертифіката зберігається під час кожної https-перевірки, тож попередження, описані в розділі моніторинг SSL, не потребують окремого запиту.

• Таймаут: від 1 до 120 секунд, за замовчуванням 30. Для більшості сайтів краще 10–15 секунд: сторінка, якій потрібно 30 секунд, для користувачів уже зламана.
• Метод: GET, HEAD, POST, PUT, PATCH або DELETE. HEAD швидший, але деякі фреймворки відповідають на HEAD не так, як на GET, тож зелена HEAD-перевірка може приховати зламану сторінку.
• Інтервал: 5 хв на Free, 1 хв на Starter, 30 с на Pro й Agency.
• Basic auth і заголовок X-Tenium-Secret доступні на всіх тарифах; довільні заголовки запиту потребують Pro.

Який діапазон статусів вважати нормою

За замовчуванням це 200-299. Діапазон можна розширити до 200-399, якщо ви не хочете переходити за редиректами, звузити до одного коду або перелічити кілька значень, наприклад 200,301,302. Діапазони й переліки можна поєднувати: 200-204,301.

Це поле потрібне для нестандартних випадків. Тестовий сайт під basic auth, який анонімним відвідувачам відповідає 401, можна відстежувати з очікуваним статусом 401: якщо відповідь зміниться на 200, хтось зняв захист. Сторінку обслуговування, що навмисно повертає 503, на час запланованих робіт краще закрити вікном обслуговування, а не послаблювати діапазон статусів назавжди.

Ланцюжки редиректів і цикли

Перехід за редиректами ввімкнено за замовчуванням, Tenium проходить до п’яти кроків. Кожен крок записується в деталі перевірки. Тож коли правило перезапису веде з /shop на /shop/, потім знову на /shop і далі, інцидент покаже цикл, а не голе «забагато редиректів». Типові причини: CDN примусово вмикає https, а початковий сервер — http; правила для www і без www посилаються одне на одного; мовний плагін перенаправляє за cookie, якої немає в наших перевірок.

Якщо вимкнути перехід за редиректами, оцінюється перша відповідь як є. Це правильне налаштування, коли треба стежити саме за тим, що http://example.com відповідає 301. Але додайте 301 до очікуваного діапазону, інакше монітор завжди показуватиме збій.

Таймаути, повільні сервери й поріг повільної відповіді

Збій за таймаутом виглядає як «Timeout after 15 s» і вважається недоступністю, як і код 500. Повільний, але живий сервер — це інша проблема: на Pro й Agency можна задати поріг повільної відповіді в мілісекундах. Tenium порівнює середнє останніх трьох перевірок із вашим числом і відкриває інцидент про погіршення, а не про недоступність. Для бази даних під навантаженням це правильний рівень серйозності. Поріг і власні заголовки входять у тариф Pro за $29; докладніше — сповіщення про час відповіді.

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

Чому справний сайт може не пройти перевірку

Найчастіше хибні спрацювання спричиняє щось між перевіркою й вашим сервером, а не сам сервер. Найбільша група — сторінки захисту від ботів: перевірку Cloudflare, Akamai, Imperva, Sucuri, DataDome чи AWS WAF Tenium розпізнає й записує як інцидент «заблоковано», а не «недоступно». Так ви відрізните рішення фаєрвола від збою. Обмежувачі частоти запитів і правила fail2ban можуть заблокувати IP-адресу моніторингу після серії повторів. Додайте адреси зі списку IP-адрес перевірок до білого списку (allow-list) або надсилайте заголовок X-Tenium-Secret, за яким ваш фаєрвол упізнає запит.

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

Чого ця перевірка не покаже

Вона не запускає браузер. JavaScript не виконується, тож односторінковий застосунок, який віддає порожню оболонку з кодом 200, виглядатиме справним, хоча користувачі бачать порожній екран. У такому разі спрямуйте моніторинг ключових слів на текст, що формується на сервері, або на JSON-ендпоінт, до якого звертається застосунок. Крім того, за одну перевірку робиться один запит, а не весь шлях через вхід і оформлення замовлення, тож вона не скаже, що відправлення форми не працює. Вважайте її швидкою й дешевою першою лінією: вона показує, що вхідні двері відчиняються.