В части 1 я рассказал о философии k6 и особенностях первого теста. В этом посте рассказывается о том, как все стало по—настоящему - о тестовом наборе производственного уровня, запущенном в реальном времени с приложением для микросервисов в кластере homelab Kubernetes, в том числе о том, что пошло не так при первом запуске и как я это отладил.

Netstat давно считается устаревшим, ps aux может обрезать командные строки, а стандартный top придётся донастраивать… Однако мы всё равно набираем эти три команды для проверки, потому что так было написано в учебниках.

Для тех, кто не в теме, top, ps и netstat — это классическая троица из каждого Linux-учебника. Эти утилиты нужны, чтобы следить за процессами, памятью и сетевыми соединениями. 

Недавно мы перенесли наш производственный кластер GKE с традиционного контроллера Ingress на API Kubernetes Gateway — и, честно говоря, нам следовало сделать это раньше.

Если merge queue гарантирует, что каждый коммит в main прошёл тесты, любой последующий сбой полного прогона на main можно считать нестабильным тестом. Поэтому не отключайте такой прогон после слияния изменений.

Собирайте свежие падения на main в один доступный список. Он покажет, какие сбои повторяются чаще, и поможет увидеть связь между ними. Начинайте исправление с причин, которые ломают больше всего прогонов.

Причиной бывает ошибка в допущениях о порядке выполнения или сбой инфраструктуры: например, не скачался релиз с GitHub либо Windows не удалила каталог. В заметке Catch Flakes On Main автор объясняет, почему этот процесс отделяет нестабильность от настоящих регрессий.

Один лог CI не показывает, какой тест постепенно замедляется или периодически падает. В Cypress 14.x хук after:spec после каждого файла со сценариями получает число успешных и неуспешных тестов и их длительность. Код преобразует данные в метрики Prometheus.

Короткий процесс Cypress нельзя опросить напрямую, поэтому он отправляет метрики в Prometheus Pushgateway. Тот хранит их между запусками, а Alloy периодически забирает и пересылает в Grafana Cloud Metrics. Общий run_id объединяет файлы одного запуска на дашборде.

Ошибку отправки ловят через try/catch, чтобы сбой мониторинга не ронял успешный прогон. Код, конфигурация и набор метрик есть в пошаговом разборе Grafana Labs.