Русский
Русский
English
Статистика
Реклама

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

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

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

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

  2. Пройти по интерфейсу, зафиксировать запросы, которые стоят за каждым действием пользователя.

  3. Подготовить скрипты, которые будут имитировать пользовательские действия, выполняя цепочки запросов.

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

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

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

  • Окружения содержат значения переменных, с которыми мы работаем в рамках сценариев адреса серверов, имена папок и т.д. Фактически одно окружение это один продукт.

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

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

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

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

  • Сценарии экспортируются в JSON-файлы и сохраняются в Git-репозиторий TFS.

  • В пайплайне TFS прописывается проверка по расписанию. Стоит отметить, что для нас интеграция с TFS это ещё одно преимущество Postman, поскольку с этого года все наши команды работают именно здесь. В TFS можно сразу увидеть результат выполнения запросов, что очень удобно, если Postman используется для отладки продукта. У нас речь про мониторинг, так что не будем углубляться.

  • JSON-файл вызывается через утилиту Newman это инструмент для запуска коллекций из командной строки, который также разработала команда Postman. Он умеет выполнять запросы, принимать ответы на них, высчитывать метрики, которые указаны в сценарии.

  • Результаты выполнения сценариев сохраняются в БД Influx, откуда данные отправляются в дашборды Grafana. Здесь можно настроить критические пороги, чтобы автоматически сообщать, если какой-то показатель выходит за заданное значение.

Итого

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

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

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

Источник: habr.com
К списку статей
Опубликовано: 26.02.2021 10:11:26
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Управление продуктом

Мониторинг

Работоспособность по

Мониторинг ит-продуктов

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru