/)
Если в вашем наборе тестов Cypress есть тесты, которые часто падают или работают медленно, вы знаете, как трудно выявить закономерность по результатам одного запуска. Это может быть один спецификационный файл, который замедлился, один упавший тест или, возможно, весь набор тестов постепенно становится медленнее. Первопричиной может быть ошибка в приложении, нестабильный (flaky) тест или что-то еще. Вывод терминала и логи CI покажут, что произошло за один запуск, но это не поможет заметить более масштабные тенденции — особенно учитывая, что эти данные теряются сразу после завершения задания.
К счастью, Cypress, фреймворк для автоматизированного тестирования веб-интерфейсов, уже предоставляет все необходимое через свои хуки плагинов. После завершения каждого спецификационного файла Cypress передает объект результатов с количеством пройденных и упавших тестов, длительностью каждого теста и их статусами. Вам нужно лишь превратить это в метрики и отправить в надежное хранилище.
В этой статье вы узнаете, как отслеживать тесты Cypress, преобразуя результаты в метрики Prometheus внутри хука Cypress, отправляя их в Prometheus Pushgateway и позволяя Alloy собирать данные из шлюза и пересылать их в Grafana Cloud Metrics — используя только бесплатные уровни подписки.
К концу статьи у вас будет настроен конвейер со следующей архитектурой:
Что вам понадобится
Это руководство предполагает выполнение всех действий в рамках вашего существующего проекта Cypress. Перед началом убедитесь, что у вас есть:
- Проект Cypress (в этом примере используется Cypress 14.x) с файлом cypress.config.js, который вы можете редактировать
Проект Cypress (в этом примере используется Cypress 14.x) с файлом cypress.config.js, который вы можете редактировать
- Prometheus Pushgateway. Запуски Cypress — это кратковременные пакетные задания, поэтому их нельзя собрать напрямую — Pushgateway хранит метрики между запусками, чтобы сборщик мог их забрать. Настройте Prometheus Pushgateway в своей инфраструктуре
Prometheus Pushgateway. Запуски Cypress — это кратковременные пакетные задания, поэтому их нельзя собрать напрямую — Pushgateway хранит метрики между запусками, чтобы сборщик мог их забрать. Настройте Prometheus Pushgateway в своей инфраструктуре
- Alloy, наш коллектор с открытым исходным кодом, который мы используем для сбора данных из Pushgateway и удаленной записи в Grafana Cloud
Alloy, наш коллектор с открытым исходным кодом, который мы используем для сбора данных из Pushgateway и удаленной записи в Grafana Cloud
- Учетная запись Grafana Cloud. Бесплатный уровень включает Grafana Cloud Metrics и конечную точку для удаленной записи Prometheus. Если у вас нет учетной записи, вы можете зарегистрироваться здесь
Учетная запись Grafana Cloud. Бесплатный уровень включает Grafana Cloud Metrics и конечную точку для удаленной записи Prometheus. Если у вас нет учетной записи, вы можете зарегистрироваться
- Ваш URL для удаленной записи Grafana Cloud, числовой ID пользователя и токен политики доступа с областью действия metrics:write
Ваш URL для удаленной записи Grafana Cloud, числовой ID пользователя и токен политики доступа с областью действия metrics:write
Отправка метрик из хуков Cypress
1a. Хуки, которые делают это возможным
Плагины Cypress работают в Node.js и могут подписываться на события жизненного цикла в setupNodeEvents. Два хука дают нам все необходимое:
- before:run запускается один раз, перед выполнением любого спецификационного файла. Мы используем его, чтобы присвоить единый run_id для всего набора тестов и очистить состояние от предыдущего запуска. В этом примере run_id — это временная метка (epoch) начала выполнения набора тестов.
before:run запускается один раз, перед выполнением любого спецификационного файла. Мы используем его, чтобы присвоить единый run_id для всего набора тестов и очистить состояние от предыдущего запуска. В этом примере run_id — это временная метка (epoch) начала выполнения набора тестов.
- after:spec запускается после завершения каждого спецификационного файла и получает объект результатов этого файла. Именно здесь находятся количество тестов, их статусы и длительность, поэтому здесь мы формируем и отправляем метрики.
after:spec запускается после завершения каждого спецификационного файла и получает объект результатов этого файла. Именно здесь находятся количество тестов, их статусы и длительность, поэтому здесь мы формируем и отправляем метрики.
Отправка обернута в блок try/catch, чтобы сбой мониторинга никогда не превращал успешный запуск теста в провальный — телеметрия является побочным эффектом, а не блокирующим фактором. Во-вторых, run_id устанавливается один раз в before:run и повторно используется каждым спецификационным файлом, поэтому все спецификации из одного запуска набора тестов имеют один идентификатор и могут быть сгруппированы позже для каждого запуска.
1b. Преобразование объекта результатов Cypress в метрики Prometheus
Объект результатов, который Cypress передает в after:spec, включает блок статистики (passes, failures, pending, skipped, tests и duration в миллисекундах) и массив тестов, каждый из которых содержит заголовок, статус и длительность. Мы отображаем их на небольшой набор метрик, используя метки для разделения по спецификации, запуску и отдельному тесту:
Каждая серия содержит общий набор меток: spec (какой файл), run_id (временная метка, установленная в before:run) и ci_run_id (запуск CI, если присутствует) — так что вы можете отфильтровать дашборд до одной спецификации или одного запуска CI. Результатом является компактный набор метрик:
- cypress_tests_total: количество тестов по результатам (пройденные, упавшие, ожидающие, пропущенные) для каждой спецификации
cypress_tests_total: количество тестов по результатам (пройденные, упавшие, ожидающие, пропущенные) для каждой спецификации
- cypress_tests_run_total: общее количество тестов, выполненных для каждой спецификации
cypress_tests_run_total: общее количество тестов, выполненных для каждой спецификации
- cypress_spec_duration_seconds: сколько времени заняла каждая спецификация
cypress_spec_duration_seconds: сколько времени заняла каждая спецификация
- cypress_spec_success: 1, если в спецификации не было ошибок; 0, если в спецификации были ошибки
cypress_spec_success: 1, если в спецификации не было ошибок; 0, если в спецификации были ошибки
- cypress_test_success и cypress_test_duration_seconds: та же идея на уровне отдельных тестов, чтобы вы могли отслеживать динамику одного нестабильного теста с течением времени
cypress_test_success и cypress_test_duration_seconds: та же идея на уровне отдельных тестов, чтобы вы могли отслеживать динамику одного нестабильного теста с течением времени
1c. Отправка в Pushgateway
Обычная настройка Prometheus собирает данные с долгоживущих сервисов через определенные интервалы. Запуск Cypress — это противоположность. Это кратковременное пакетное задание, которое завершается до того, как сборщик успеет к нему обратиться. Prometheus Pushgateway существует именно для этого случая: ваше задание отправляет метрики на шлюз, шлюз удерживает их, а Prometheus (или Alloy) собирает данные со шлюза по своему собственному расписанию.
Сама отправка представляет собой обычный HTTP POST метрик в текстовом формате Prometheus:
Job и instance в пути формируют ключ группировки Pushgateway (здесь job="cypress" и instance="local"; которые могут быть назначены любыми значениями в зависимости от проекта или модуля вашего запускаемого набора тестов).
Поскольку мы накапливаем метрики каждой спецификации в карту specMetrics и повторно отправляем полное тело запроса после каждой спецификации, шлюз всегда содержит полный, актуальный снимок набора тестов. А очистка этой карты в before:run означает, что новый запуск начинается с чистого листа, а не переносит устаревшие данные спецификаций.
Вся интеграция находится в cypress.config.js и активируется только при установке PROMETHEUS_PUSHGATEWAY_URL, поэтому локальные вызовы cypress run остаются нетронутыми, если вы не решите их использовать:
Отправка в Grafana Cloud с помощью Alloy
Pushgateway теперь содержит ваши метрики, но это локальный буфер, а не долгосрочное хранилище. Alloy связывает их: он собирает данные со шлюза и выполняет удаленную запись в Grafana Cloud Metrics.
Укажите свои учетные данные Grafana Cloud в качестве переменных окружения и запустите Alloy:
Запустите тесты и проверьте результат
Запустите Pushgateway и Alloy, а затем выполните свой набор тестов, указав в качестве цели шлюз:
По завершении каждой спецификации Cypress записывает в лог строку вида: Pushed metrics for spec "login.cy.js" (run_id="1753100000000") to Pushgateway. В течение интервала сбора данных эти ряды появляются в Grafana Cloud.
Отсюда вы можете создать дашборд, который выявляет тенденции в количестве пройденных и проваленных тестов, длительности спецификаций и успешности отдельных тестов. Вы также можете настроить Grafana Alerting, чтобы получать уведомления, когда уровень успешности набора тестов падает или критически важная спецификация начинает выдавать ошибку.
На основе собранных метрик мы можем визуализировать время выполнения каждой спецификации, а также отдельных тестов.
Запуск в CI
Тот же механизм работает без изменений в CI — единственная разница заключается в том, откуда поступают метрики.
Например, в рабочем процессе GitHub Actions установите PROMETHEUS_PUSHGATEWAY_URL на Pushgateway, доступный вашему раннеру, и Cypress сделает все остальное:
Поскольку код считывает GITHUB_RUN_ID, если он присутствует, каждый запуск CI помечается своим ci_run_id — так вы можете перейти от всплеска метрик прямо к запуску рабочего процесса, который его вызвал.
Несколько советов, которые сэкономят ваше время:
- Используйте Pushgateway, а не цель для сбора (scrape target). Запуски Cypress завершаются за секунды; скрапер никогда не успеет их зафиксировать. Pushgateway — это буфер, который делает кратковременные задачи наблюдаемыми.
Используйте Pushgateway, а не цель для сбора (scrape target). Запуски Cypress завершаются за секунды; скрапер никогда не успеет их зафиксировать. Pushgateway — это буфер, который делает кратковременные задачи наблюдаемыми.
- Никогда не позволяйте телеметрии приводить к сбою запуска. Оберните отправку данных в блок try/catch. Сбой в системе мониторинга никогда не должен приводить к тому, что успешный набор тестов будет помечен как проваленный.
Никогда не позволяйте телеметрии приводить к сбою запуска. Оберните отправку данных в блок try/catch. Сбой в системе мониторинга никогда не должен приводить к тому, что успешный набор тестов будет помечен как проваленный.
- Экранируйте значения меток. Названия тестов — это произвольный текст, который может содержать кавычки и символы переноса строки, нарушающие текстовый формат Prometheus. Экранируйте их перед записью метрик.
Экранируйте значения меток. Названия тестов — это произвольный текст, который может содержать кавычки и символы переноса строки, нарушающие текстовый формат Prometheus. Экранируйте их перед записью метрик.
- Присваивайте один run_id на весь набор тестов. Установка его в before:run и повторное использование в спецификациях позволяют группировать и сравнивать результаты запусков целиком в дальнейшем.
Присваивайте один run_id на весь набор тестов. Установка его в before:run и повторное использование в спецификациях позволяют группировать и сравнивать результаты запусков целиком в дальнейшем.
Grafana Assistant — это самый простой способ начать работу с метриками, логами, трассировками, дашбордами и многим другим в Grafana Cloud. У нас есть щедрый бесплатный тарифный план и варианты для любых задач. Зарегистрируйтесь бесплатно прямо сейчас!
Теги