Снова про мониторинг: как Postman избавляет поддержку от написания кода

Некоторое время назад мы уже рассказывали про технологию, по которой мы ставим продукты на мониторинг. На верхнем уровне план действий следующий:

Составить карту пользовательских сценариев – описать по шагам все действия, которые пользователи выполняют в продукте.
Пройти по интерфейсу, зафиксировать запросы, которые стоят за каждым действием пользователя.
Подготовить скрипты, которые будут имитировать пользовательские действия, выполняя цепочки запросов.

Postman отвечает за последний шаг в этом процессе, при этом использовать его фактически может даже инженер с нулевым опытом и без знания кода. Мы проверили – чтобы научиться делать сценарии в этой программе, достаточно пары часов. После этого специалист поддержки может самостоятельно готовить новые запросы, ставить их в расписание и контролировать результаты.

Как работать с Postman

Итак, вы определились со сценариями, которые хотите мониторить, и подготовили список запросов, которые соответствуют действиям пользователя. В Postman сценарии собираются из этих запросов, как из конструктора. Помимо запросов, такими кирпичиками являются коллекции и окружения.

Окружения содержат значения переменных, с которыми мы работаем в рамках сценариев – адреса серверов, имена папок и т.д. Фактически одно окружение – это один продукт.
Коллекция описывает, что с этими переменными делать. Это набор запросов, и в нашем случае одна коллекция – это один сценарий мониторинга. Одну коллекцию можно использовать в разных окружениях, подставляя нужные переменные. Не нужно для каждой системы писать новый сценарий авторизации – можно одним кликом вызвать уже готовую коллекцию.

Таким образом, механика следующая: пишем запрос, сохраняем в коллекцию, выбираем нужное окружение – и вперёд. При необходимости можно сразу добавить тесты, которые нужно выполнять в каждом запросе или на каждом шаге мониторинга. Наша задача – чтобы система по расписанию проверяла модули на работоспособность, поэтому в этом случае мы обошлись без дополнительных тестов.

Как мы встроили Postman в свой процесс

Мы применяем Postman для разработки сценариев мониторинга, тестирования и проработки интеграционных взаимодействий.

Сценарии экспортируются в JSON-файлы и сохраняются в Git-репозиторий TFS.
В пайплайне TFS прописывается проверка по расписанию. Стоит отметить, что для нас интеграция с TFS – это ещё одно преимущество Postman, поскольку с этого года все наши команды работают именно здесь. В TFS можно сразу увидеть результат выполнения запросов, что очень удобно, если Postman используется для отладки продукта. У нас речь про мониторинг, так что не будем углубляться.
JSON-файл вызывается через утилиту Newman – это инструмент для запуска коллекций из командной строки, который также разработала команда Postman. Он умеет выполнять запросы, принимать ответы на них, высчитывать метрики, которые указаны в сценарии.
Результаты выполнения сценариев сохраняются в БД Influx, откуда данные отправляются в дашборды Grafana. Здесь можно настроить критические пороги, чтобы автоматически сообщать, если какой-то показатель выходит за заданное значение.

Итого

Когда мы отрабатывали технологию мониторинга, мы планировали использовать Zabbix. При ближайшем рассмотрении выяснилось, что для наших целей он не подходит – написать сценарий нативными средствами невозможно, приходится готовить их на Python. Причём без такого инструмента, как Postman-овские коллекции, делать это приходится каждый раз заново.

Здесь же вся логика зашита в интерфейс. Так что инженеру достаточно подставлять нужные данные в отдельные участки кода. Это существенно снижает порог входа для всех, кому нужно работать с запросами, будь то разработчики, аналитики, тестировщики или кто-то ещё.

Результат – поддержка становится надёжнее, не зависит от того, как тот или иной инженер владеет кодом. И при этом легко переносить опыт от команды к команде и никаких компромиссов с точки зрения качества процессов.