Моніторинг доступності
Метод запиту
GET або POST. POST дозволяє перевіряти ендпоінт, який приймає лише операції запису (наприклад, власну перевірку працездатності приймача вебхуків).
Перевірка TCP-порту
Не все спілкується по HTTP — база даних, поштовий сервер, ігровий сервер. Замість http(s):// вкажіть у URL tcp://host:port, і Dumza перевірятиме, чи приймає цей порт з'єднання, замість HTTP-запиту. Метод, очікуваний статус, ключове слово та поріг часу відповіді до TCP-перевірки не застосовуються і приховані у формі; алертинг, інциденти й усе інше працюють так само.
Очікуваний код статусу
Будь-яка відповідь ендпоінта, що відрізняється від очікуваного коду, вважається недоступністю. Це не обов'язково 200 — багато API коректно повертають 201, 204 і навіть 401/503 для здорової перевірки (наприклад, ендпоінт, який ПОВИНЕН вимагати автентифікації). Вкажіть той статус, який ваш ендпоінт справді повертає, коли все гаразд.
Перевірка ключового слова
За бажанням можна вимагати (або забороняти) наявність певного тексту в тілі відповіді — це корисно для ендпоінтів, які повертають 200 навіть тоді, коли всередині сторінки щось зламано (наприклад, CMS віддає загальну сторінку помилки зі статусом 200). Оберіть «містить», щоб вимагати текст, або «не містить», щоб перевірка провалювалась, якщо текст з'явився (зручно для виявлення банера режиму обслуговування, який ваш застосунок показує, продовжуючи повертати 200).
Поріг часу відповіді
Задайте максимально прийнятний час відповіді — і перевірка, яка відповідає коректно, але надто повільно, позначається як «погіршена», а не «недоступна»: вона видима на дашборді й враховується в статистиці доступності, але НЕ відкриває інцидент і не надсилає сповіщення. «Погіршено» — це сигнал для спостереження, а не привід будити команду.
Інтервал перевірки
Як часто Dumza перевіряє ендпоінт. На безкоштовному тарифі перевірка відбувається кожні 5 хвилин; на платних тарифах — аж до кожної хвилини. Коротший інтервал означає швидше виявлення збою ціною більшої кількості запитів до вашого сервера.
Таймінг сповіщень: notifyAfter і повторні сповіщення
Параметр «Сповіщати після N невдач поспіль» визначає, скільки поганих перевірок підряд потрібно, щоб відкрити інцидент (мінімум 2 — щоб уникнути хибних тривог через одиничний збій). Окремо параметр «Повторювати сповіщення кожні N хвилин» (необов'язковий, мінімум 30) повторює сповіщення, поки монітор залишається недоступним — корисно, якщо перше сповіщення команда пропустила.
Значення статусів монітора
up — остання перевірка пройшла успішно. down — відкрито інцидент. degraded — відповідає, але повільніше за встановлений поріг. pending — жодної перевірки ще не виконано (щойно створено або на паузі). auth_error — токен входу монітора з автентифікацією було відхилено; дивіться «Автентифікований моніторинг».
Призупинення монітора
Призупинений монітор повністю перестає перевірятися, а будь-який відкритий за ним інцидент закривається автоматично — він не продовжуватиме сповіщати вас про те, що ви свідомо вимкнули (планове обслуговування, виведення з експлуатації). Відновіть його будь-коли, щоб знову почати моніторинг.