16 сентября 2026 г.
Если вы используете сервисы gRPC или GraphQL в продакшене, вы, вероятно, сталкивались с такой проблемой: в вашей коллекции Postman запрос уже настроен с правильной аутентификацией, переменными и тестовыми скриптами, но когда вы пытаетесь запланировать его как монитор, отображаются только HTTP-запросы. В итоге вам приходится либо писать отдельную синтетическую проверку в другом инструменте, либо создавать небольшой скрипт, который запускает CLI по расписанию cron где-то на сервере. Оба варианта работают, но ни один из них не кажется идеальным.
Этот пробел заполняется. Postman Monitors теперь поддерживают выполнение запросов gRPC и GraphQL в бета-версии. Я расскажу, как запланировать вызов gRPC (включая потоковую передачу), как отслеживать GraphQL-запросы или мутации, как выглядят тестовые скрипты для каждого из них и куда отправлять отзывы, пока функция находится в разработке.
Что входит в бета-версию
Вот что охватывает текущая бета-версия:
- Унарные вызовы gRPC — стандартный шаблон «запрос-ответ».
- Потоковая передача gRPC от сервера к клиенту, от клиента к серверу и двунаправленная потоковая передача (с некоторыми оговорками по поводу потоков, о которых я расскажу позже).
- GraphQL-запросы и мутации по протоколу HTTP.
- Существующая аутентификация, переменные и тестовые скрипты, которые переносятся из вашей коллекции без необходимости переписывания.
Что еще не реализовано: GraphQL-подписки, потоковая передача от клиента с несколькими сообщениями и более продвинутые вспомогательные средства для проверки потоков. Они есть в дорожной карте.
Стоит отметить: это та же модель выполнения мониторов, которую вы уже знаете. Планировщик берет вашу коллекцию, выполняет запросы по порядку, оценивает ваши тестовые скрипты и публикует результаты. Единственное, что изменилось, — это набор протоколов, которые понимает исполнитель.
Мониторинг gRPC-вызова
Начнем с самого простого случая: унарный gRPC-вызов к пользовательскому сервису. У вас уже есть запрос в коллекции, подключенный к файлу .proto, с выбранным методом. Чтобы запланировать его, щелкните правой кнопкой мыши по коллекции, выберите «Создать монитор» (Create a monitor) и установите нужное расписание.
Для проверки ответы gRPC проходят через тот же объект pm.response, который вы используете для HTTP-тестов. Свойства просто адаптированы для gRPC:
Если статус gRPC возвращается как что-то отличное от OK, например UNAVAILABLE, DEADLINE_EXCEEDED или PERMISSION_DENIED, ваш монитор выдаст ошибку, и вы получите уведомление. Это полезное поведение по умолчанию. На практике я также проверяю структуру сообщения, потому что успешный статус с пустым телом ответа для вызывающей стороны все равно означает неисправную конечную точку.
Что касается аутентификации: если вы используете метаданные gRPC для токенов Bearer, настройте их один раз в запросе, и они будут использоваться при запуске монитора. Храните сам токен в переменной окружения монитора, а не в определении запроса.
Мониторинг потоков gRPC
Потоковая передача — это самое интересное. Потоковая передача от сервера к клиенту — это «золотая середина» в бета-версии: вы отправляете одно сообщение, сервер отправляет много, и вы можете проверять сообщения по мере их поступления.
У вас есть два варианта тестирования. Первый — это хук скрипта «On message», который выполняется для каждого сообщения, отправляемого сервером:
Второй — это проверка после завершения потока на вкладке «Tests»:
Я склоняюсь к проверкам после завершения потока именно для мониторов. Проверки каждого сообщения полезны при отладке в реальном времени в клиенте, но когда монитор выдает ошибку в 3 часа ночи, сообщение «поток вернул 2 сообщения вместо 5» является гораздо более понятным сигналом, чем 20 отдельных результатов проверок для каждого сообщения.
Важное замечание по поводу потоковой передачи от клиента и двунаправленной передачи: в настоящее время бета-версия поддерживает одно клиентское сообщение на вызов. Если ваш двунаправленный поток зависит от отправки последовательности сообщений на сервер, дождитесь обновления с поддержкой нескольких сообщений, прежде чем переносить эту проверку в монитор. Унарная передача и потоковая передача от сервера к клиенту — это пути, которые работают полноценно уже сегодня.
Мониторинг GraphQL-запросов или мутаций
GraphQL-запросы по своей сути являются HTTP-запросами, но модель сбоев в них настолько отличается, что стоит обратить на это внимание. GraphQL-сервер может вернуть статус 200 OK с телом, полным ошибок, поэтому одна лишь проверка кода состояния будет показывать успех, в то время как ваш API не работает.
Вот запрос, который я использую в качестве шаблона для мониторов GraphQL:
pm.response.data и pm.response.errors — это два свойства, которые здесь наиболее важны. Вместе они показывают, действительно ли операция прошла успешно с точки зрения клиента, что и должен проверять монитор.
Для мутации я бы также добавил проверку возвращаемой сущности, чтобы выявлять случаи, когда сервер принимает мутацию, но молча отбрасывает поля. Что-то вроде:
Подписки (subscriptions) пока не входят в бета-версию. Если вы полагаетесь на них, пока оставьте свои существующие проверки подписок без изменений.
Настройка расписания
Как только для ваших запросов будут готовы тесты, планирование выполняется так же, как и для любого другого монитора. Выберите частоту (от каждых 5 минут до еженедельной), выберите регион, если вам важно географическое покрытие, прикрепите окружение с вашими учетными данными и включите уведомления. Обычно я начинаю с 15-минутного интервала для нового монитора и сокращаю его, когда увижу неделю стабильной работы. Выполнение ресурсоемких запросов каждую минуту во время настройки быстро расходует лимиты.
Два совета из моего опыта работы с собственными сервисами:
- Используйте выделенное окружение монитора. Не используйте повторно свое локальное окружение разработки. Создайте окружение только с теми переменными, которые нужны монитору, используйте секретные переменные для токенов и обновляйте их с той же периодичностью, с которой обновляете все остальное.
- Держите коллекцию сфокусированной. Монитор должен проверять что-то одно: критическое чтение, мутацию для проверки работоспособности или «сердцебиение» потока. Если он выдает ошибку, вы должны точно знать, что сломалось. Коллекция из 30 запросов с одним неудачным тестом где-то посередине — это упражнение по отладке, которым вы не захотите заниматься в 3 часа ночи.
Отправка отзывов во время бета-тестирования
Это бета-версия, и команда активно прислушивается к пользователям. Если вы столкнулись с трудностями, например, хук скрипта ведет себя не так, как ожидалось, файл .proto не загружается или вам не хватает метрики в отчете о выполнении, откройте issue в репозитории postman-app-support на GitHub. Четко пометьте его (gRPC или GraphQL, Monitors) и приложите структуру коллекции и любые выходные данные об ошибках. Конкретные запросы, которые команда отметила как наиболее полезные:
- Какие шаблоны потоковой передачи вы хотели бы видеть в следующей очереди
- Варианты использования подписок GraphQL, которые вы бы перенесли в мониторы, если бы они были доступны
- Вспомогательные средства для проверок, которые вы хотели бы видеть для потоковых ответов
Дорожная карта уже включает потоковую передачу от клиента с несколькими сообщениями, подписки GraphQL и более продвинутые проверки потоков, но очередность зависит от того, что на самом деле пытаются сделать пользователи.
Заключение
Коротко: если у вас был запрос gRPC или GraphQL в коллекции, который вы хотели запускать по расписанию, теперь вы можете это сделать, не переключаясь между инструментами. Унарные gRPC, потоковая передача gRPC от сервера к клиенту, а также GraphQL-запросы и мутации уже готовы. Потоковая передача от клиента с несколькими сообщениями, двунаправленная потоковая передача с несколькими сообщениями и подписки GraphQL уже в разработке.
Что мне нравится в этом релизе, так это то, что он не требует ничего переписывать. Тот же запрос, та же аутентификация, те же тестовые скрипты — теперь они просто работают по расписанию. Это правильный способ выпуска функций мониторинга.
Попробуйте это на сервисе, который вам действительно важен, понаблюдайте за несколькими запусками и отправьте отзыв о том, что бы вы хотели увидеть дальше. Бета-версии развиваются быстрее, когда отзывы конкретны.
Ресурсы
- Документация по Postman Monitors: обзор принципов работы мониторов, параметров планирования и настройки уведомлений.
- Написание тестов в Postman: справочное руководство по pm.test, pm.response и модели скриптов, используемой в мониторах gRPC и GraphQL.
- gRPC в Postman: как работают запросы gRPC, файлы .proto и потоковая передача в клиенте Postman.
- GraphQL в Postman: как создавать и отправлять запросы и мутации GraphQL в коллекции.
- Проблемы postman-app-support на GitHub: место для отправки отзывов о бета-версиях, сообщений об ошибках и запросов на новые функции.
- Официальная документация gRPC: справочная информация об унарных, серверных потоковых, клиентских потоковых и двунаправленных шаблонах RPC.