Дополнительные опции
На этой странице описаны опции, специфичные для типа, которые выходят за рамки базовой проверки up/down: формирование HTTP-запроса и валидация ответа, оповещения об истечении SSL и проверки DNS-записей. Об общих полях и целях по каждому типу см. Типы мониторов.
Опции HTTP / HTTPS
Мониторы HTTP и HTTPS позволяют формировать запрос и валидировать ответ, чтобы проверка отражала реальную работоспособность приложения, а не просто «сервер ответил».
Метод запроса
Поле method управляет HTTP-глаголом. Допустимые значения:
GET (default), POST, PUT, DELETE, HEAD, OPTIONS- GET — по умолчанию; запрашивает страницу или эндпоинт.
- HEAD — проверяет доступность без загрузки тела (более лёгкий вариант).
- POST / PUT — обращаются к эндпоинту, ожидающему тело запроса (см. Тело запроса).
Ожидаемый код статуса
По умолчанию монитор считает 200 успехом. Установите expected_status в любой код от 100 до 599, когда ваш эндпоинт возвращает что-то иное:
| Поведение эндпоинта | Установите ожидаемый статус в |
|---|---|
| Обычная страница или API | 200 |
| Редирект, который вы хотите подтвердить (не следуя за ним) | 301 / 302 |
| Health-эндпоинт, возвращающий «no content» | 204 |
| Защищённый авторизацией эндпоинт, который должен отклонять | 401 / 403 |
Ответ, чей код статуса отличается от expected_status, записывается как неудача.
Ожидаемая строка
Установите expected_string в подстроку, которая должна присутствовать в теле ответа для прохождения проверки. Это ловит случай, когда сервер возвращает 200, но страница сломана, пуста или показывает ошибку.
expected_string: "Welcome to Example"
expected_string: "\"status\":\"ok\""Если статус ответа совпадает, но ожидаемая строка отсутствует, проверка не проходит.
Пользовательские заголовки
Добавляйте заголовки запроса по одному на строку в формате Key: Value. Полезно для аутентификации, согласования контента или обращения к конкретному виртуальному хосту.
Authorization: Bearer abc123
Accept: application/json
X-Api-Key: my-key
Host: app.internal.example.comЗаголовки разбираются в пары ключ/значение и отправляются с каждой проверкой.
Тело запроса
Для мониторов POST/PUT необязательное поле body отправляется как полезная нагрузка запроса — например, JSON-документ, который ожидает health-эндпоинт. Сочетайте его с заголовком Accept/Content-Type для корректного согласования контента.
Следование редиректам
follow_redirects по умолчанию выключено. Когда выключено, ответ 3xx оценивается как есть — удобно для подтверждения, что редирект возвращает именно 301/302. Когда включено, probe следует за редиректами и оценивает статус и тело конечного назначения. Включайте его, когда ваш канонический URL редиректит (например HTTP→HTTPS или apex→www) и вам важна конечная страница.
Оповещения об истечении SSL
Мониторы SSL отслеживают срок действия TLS-сертификата и предупреждают вас до того, как он истечёт, чтобы забытое обновление никогда не превратилось в сбой.
| Опция | По умолчанию | Диапазон | Описание |
|---|---|---|---|
alert_days_before_expiry |
7 |
1-90 | За сколько дней до истечения начинать оповещать. |
Монитор считывает даты действительности сертификата при каждой проверке и переходит в состояние оповещения, как только до истечения сертификата остаётся alert_days_before_expiry дней. Задайте более широкое окно (например 30 дней), чтобы дать себе достаточно времени на обновление.
Распространённый шаблон — запускать два монитора на одном хосте:
- Монитор HTTPS для подтверждения, что сайт работает и обслуживает корректно.
- Монитор SSL с окном истечения 30 дней, чтобы заранее ловить проблемы обновления.
Проверки DNS-записей
Мониторы DNS подтверждают, что домен разрешается и, необязательно, что он разрешается в ожидаемое вами значение — выявляя неправильно настроенные записи, неудавшуюся пропагацию или перехваченный DNS.
| Опция | По умолчанию | Описание |
|---|---|---|
dns_record_type |
A |
Тип записи для запроса. |
dns_expected |
— | Необязательное ожидаемое значение, которому должна соответствовать запись. |
Типы записей
Выберите dns_record_type, соответствующий тому, что вы хотите проверить:
| Тип | Что проверяет |
|---|---|
A |
IPv4-адрес, на который указывает имя хоста. |
AAAA |
IPv6-адрес. |
CNAME |
Цель канонического псевдонима. |
MX |
Хост(ы) почтового обмена. |
TXT |
Текстовые записи (SPF, DKIM, верификация домена). |
NS |
Авторитетные nameserver'ы. |
Поведение сопоставления
dns_expectedпусто — проверка проходит, пока запись вообще разрешается. Используйте это для обнаружения записи, которая исчезает или не разрешается.dns_expectedзадано — разрешённая запись должна соответствовать ожидаемому значению. Используйте это, чтобы поймать запись, которая меняется на неправильную цель.
dns_record_type: A dns_expected: 203.0.113.10
dns_record_type: MX dns_expected: mail.example.com
dns_record_type: TXT dns_expected: v=spf1 include:_spf.example.com ~allПоведение при отказе и восстановлении
Во всех типах два порога управляют тем, когда меняется статус и срабатывают оповещения:
- Порог отказа — число последовательных неудачных проверок, необходимое, чтобы пометить монитор как down и (если включено) открыть инцидент.
- Порог восстановления — число последовательных успешных проверок, необходимое, чтобы снова пометить его как up и закрыть инцидент.
Они работают совместно с повторами, подавляя ложные срабатывания. Уведомления управляются параметрами notify_on_failure и notify_on_recovery. О сигнализации об аномалиях времени отклика для мониторов HTTP/HTTPS см. Обнаружение аномалий.
Дальнейшие шаги
- Типы мониторов - Цели и опции по каждому типу
- Интервалы и probe - Частота проверок, таймаут, повторы, probe
- Оповещения: пороги - Настройка триггеров отказа и восстановления
- Обнаружение аномалий - ML-сигнализация по времени отклика
- Обзор мониторов - Жизненный цикл и общие поля