Документация

API Check — это короткий список HTTP-запросов, которые выполняются по порядку. Каждый шаг отправляет один запрос и сверяет ответ с проверками, которые вы описали, а ещё может достать из ответа значения — токен, идентификатор — чтобы их использовали следующие шаги. Монитор UP только тогда, когда прошли все выполненные шаги. Один запрос с одной проверкой — это работа для HTTP-монитора; логин, а за ним вызов, которому нужен токен, — работа для этого.

Для чего подходит

Для чего не подходит

Этот монитор — про последовательность. Если последовательность не нужна, лучше подойдёт другое:

Как выполняется проверка

1. Шаги выполняются в том порядке, в каком перечислены, сверху вниз. В одном мониторе их может быть до 50.
2. Перед каждым запросом плейсхолдеры {{переменная}} заменяются на то, что уже известно: на значения, заданные заранее, и на всё, что достали предыдущие шаги.
3. URL шага проверяется: он должен быть http или https и не должен вести на приватный, локальный или link-local адрес.
4. Запрос отправляется. Редиректы выполняются, если для шага не указано иное.
5. Выполняются все проверки этого шага, а затем извлекаются переменные.
6. Если шаг не прошёл и включена настройка «Остановить при ошибке» — а она включена по умолчанию, — остальные шаги пропускаются.

В результат попадают два числа: время ответа — это длительность всего прогона, всех шагов вместе, а HTTP-код показывается тот, что вернул последний шаг, у которого код вообще был.

Что шаг может проверить

Именно проверки решают, прошёл шаг или нет. Шаг вообще без проверок проходит на любом ответе, включая 500, — поэтому у каждого шага должна быть хотя бы одна.

Операторы такие: равно, не равно, содержит, не содержит, соответствует (регулярное выражение), меньше, меньше или равно, больше, больше или равно, существует, не существует. Всё сравнивается как текст, кроме четырёх операторов сравнения по величине: они читают обе стороны как числа и проваливают проверку, если числом не является хотя бы одна. Поэтому код ответа, записанный как 200 и как "200", ведёт себя одинаково.

Передача значений между шагами

Это то, чего обычный HTTP-монитор не умеет. Шаг объявляет, что достать из своего ответа и под каким именем, а следующие шаги пишут {{имя}} там, где значение нужно. В именах допустимы буквы, цифры и подчёркивание. Имя, которое никто не определил, остаётся в тексте как есть — обычно это хорошо видно по тому, чем закончился шаг.

У каждого извлечения может быть запасное значение — оно подставляется, когда доставать оказалось нечего.

Плейсхолдер подставляется в четырёх местах: URL шага, значения собственных заголовков этого шага, тело запроса и поля аутентификации (токен, имя пользователя, пароль). Он не подставляется в заголовки, заданные сразу для всех шагов, и не подставляется в ожидаемое значение проверки — сравнить ответ с переменной нельзя. Всё, где нужна переменная, кладите в собственные заголовки шага.

Логика статусов

Монитор UP только тогда, когда прошли все выполненные шаги. Состояния «деградация» у этого типа нет: ограниченный по частоте или медленный API либо проваливает ту проверку, которая его ловит, либо проходит.

DOWN и TIMEOUT считаются простоем и открывают инцидент — после порога подтверждения, по умолчанию это три неудачные проверки подряд, чтобы одна неудачная минута деплоя никого не будила.

В результат записывается сообщение того шага, который не прошёл, — до трёх непрошедших проверок подряд, например Status code 500 did not match equals 200. Оно говорит, что именно не сошлось, но не говорит, на каком это было шаге, поэтому давайте шагам узнаваемые названия и держите проверки внутри шага достаточно разными, чтобы их можно было различить. Результаты отдельных шагов вместе с проверкой тоже не сохраняются: один статус, одно общее время, одно сообщение.

Шаг, который PingZen вообще не смог разобрать, роняет всю проверку, и при этом не отправляется ничего: в сообщении назван сам шаг — например, API check misconfigured — 1 of 3 steps are misconfigured (step 2: missing required field(s): url). Достаточно одного нечитаемого шага из нескольких: сценарий, который нельзя выполнить целиком, не имеет права отчитаться «всё хорошо». Форма и API такой конфиг при сохранении тоже не принимают, так что встретить это можно только на мониторах, созданных до появления этой проверки.

Настройки

Поскольку внутри этой конфигурации живут токены и пароли, в CSV-экспорт мониторов она не попадает. При импорте её всё ещё принимают, если заполнить вручную.

Чего нет в форме

Редактор шагов в форме монитора закрывает сами шаги, методы, URL, тело запроса для POST, PUT и PATCH и проверки. Всё остальное, что описано на этой странице, в мониторе есть, но поля в форме не имеет и задаётся через REST API или инструменты MCP на том же мониторе: заголовки запроса, извлечение переменных, начальные переменные, аутентификация, таймауты шагов, обработка редиректов и флаг «продолжать несмотря на ошибку». Правка монитора в форме эти значения не стирает — редактор записывает обратно только те поля, которые знает, а остальное оставляет как есть.

Ещё две вещи, которые стоит знать до того, как собирать сценарий в форме:

• Тело, набранное в форме, отправляется как обычный текст, без заголовка Content-Type. API, которому нужен application/json, такой запрос отклонит. Добавьте заголовок через API — общий или на этот шаг — либо отправляйте тело как JSON-объект, тогда заголовок проставится сам.
• Список операторов в форме короче того, что умеет проверка. «Меньше или равно», «больше или равно», «существует» и «не существует» работают, но только через API.

И две настройки, которые в конфигурации есть, но сегодня ничего не делают, — на них рассчитывать не надо: API-ключ, положенный в строку запроса вместо заголовка, в URL так и не попадает, а отключение проверки сертификата у шага ни на что не влияет — сертификаты проверяются всегда.

Ключевые возможности

• До 50 HTTP-запросов в одном мониторе, по порядку, и вся последовательность проходит или падает как одна проверка
• Значения из ответа — токен, идентификатор, заголовок, cookie — переносятся в следующие шаги как {{переменные}}
• Шесть типов проверок на шаг, включая JSONPath по телу ответа, и одиннадцать операторов
• Аутентификация на каждом шаге (bearer, basic, API-ключ, свой заголовок), которая может использовать добытый токен
• Остановка на первом упавшем шаге — или прогон всех, чтобы увидеть, что именно сломалось
• URL шагов ограничены публичными адресами http и https, так что монитор нельзя направить на внутреннюю инфраструктуру