HTTP

Перейти в личный кабинет

HTTP монитор проверяет доступность веб-сайтов и API, отправляя HTTP запросы из нескольких географических регионов.

---

Принцип работы

1. Система отправляет HTTP запрос на указанный URL из выбранных регионов
2. Проверяется код ответа, заголовки и тело ответа
3. При несоответствии условиям — отправляется уведомление

┌─────────────┐              ┌─────────────┐              ┌─────────────┐
│   Регион 1  │ ──────────▶  │  Ваш сайт   │ ◀────────── │   Регион 2  │
│  (Москва)   │    HTTP      │             │    HTTP      │  (Франкфурт)|
└─────────────┘              └─────────────┘              └─────────────┘
       │                            │                            │
       └────────────────────────────┼────────────────────────────┘
                                    ▼
                             ┌─────────────┐
                             │    Tuna     │
                             │   Monitor   │
                             └─────────────┘

---

Параметры

Основные настройки

Параметр	Описание	Обязательный
Название	Уникальное имя монитора	Да
URL	Адрес для проверки (http:// или https://)	Да
Описание	Примечание о назначении	Нет

HTTP параметры

Параметр	Описание	По умолчанию
Метод	HTTP метод запроса	GET
Заголовки	Дополнительные HTTP заголовки	—
Тело запроса	Тело для POST/PUT/PATCH запросов	—
Follow Redirects	Следовать ли перенаправлениям (3xx)	Да

Поддерживаемые методы:

• GET
• POST
• PUT
• PATCH
• DELETE
• HEAD
• OPTIONS
• TRACE

Параметры проверки

Параметр	Описание	По умолчанию
Интервал	Частота проверок	5 минут
Таймаут	Максимальное время ожидания ответа	30 секунд
Повторы	Количество повторных попыток при ошибке	0

Регионы

Выберите один или несколько регионов для проверки. Монитор будет отправлять запросы из каждого выбранного региона.

---

Проверки (Assertions)

HTTP монитор поддерживает различные проверки ответа:

Проверка статус-кода

Проверяет HTTP код ответа:

Компаратор	Пример	Описание
equals	200	Код равен 200
less_than	400	Код меньше 400
greater_than	199	Код больше 199

Проверка заголовков

Проверяет наличие и значение HTTP заголовков ответа:

Компаратор	Пример	Описание
equals	application/json	Точное совпадение
contains	json	Содержит подстроку
not_contains	error	Не содержит подстроку
starts_with	application/	Начинается с
ends_with	/json	Заканчивается на

Примеры:

• Content-Type equals application/json
• Cache-Control contains no-cache

Проверка тела ответа

Проверяет содержимое тела ответа:

Компаратор	Пример	Описание
contains	"status":"ok"	Тело содержит строку
not_contains	"error"	Тело не содержит строку
equals	OK	Точное совпадение

---

SSL/TLS мониторинг

HTTP монитор автоматически проверяет SSL сертификаты для HTTPS адресов.

Информация о сертификате

При проверке HTTPS сайта собирается информация:

• Issuer Common Name — издатель сертификата
• Not Before — дата начала действия
• Not After — дата окончания действия

---

WHOIS мониторинг

Для доменов система может отслеживать WHOIS информацию:

• Registrar Name — регистратор домена
• Expiration Date — дата истечения регистрации

---

Примеры

Проверка REST API

URL: https://api.example.com/health
Метод: GET
Проверки:
  - Status Code equals 200
  - Body contains "status":"healthy"

Проверка с авторизацией

URL: https://api.example.com/protected
Метод: GET
Заголовки:
  - Authorization: Bearer your-token
Проверки:
  - Status Code equals 200

POST запрос с JSON

URL: https://api.example.com/webhook
Метод: POST
Заголовки:
  - Content-Type: application/json
Тело:
  {"test": true}
Проверки:
  - Status Code less_than 300

Проверка главной страницы сайта

URL: https://example.com
Метод: GET
Follow Redirects: Да
Проверки:
  - Status Code equals 200
  - Body contains "Welcome"

---

Статусы

Статус	Описание
New	Монитор создан, ожидается первая проверка
Up	Все проверки успешны
Down	Одна или несколько проверок не прошли

---

Алерты

Причина	Описание
Fail	Проверка не прошла (таймаут, ошибка соединения, assertion failed)
Recovery	Проверка восстановилась после ошибки

---

Лучшие практики

1. Используйте dedicated health endpoint — создайте специальный /health или /status endpoint для мониторинга
2. Проверяйте критичные функции — health check должен проверять подключение к БД, кэшу и другим зависимостям
3. Настройте несколько регионов — для критичных сервисов используйте проверки из разных географических точек
4. Используйте разумный таймаут — слишком короткий таймаут может вызвать ложные срабатывания
5. Добавьте retry — один неудачный запрос не всегда означает проблему