16.11.2025 21:30
AnotherAnkor 0 541 Источник

Привет, друг. Я тут решил поделиться с тобой простым инструментом, который не требует особых навыков и больших затрат времени для развёртывания или даже использования. По большому счёту при использовании инструмента настройка его делается один раз и забывается. Что за инструмент? На кой он нужен и чем лучше других?

Начну с описания проблемы, которую решает инструмент, что будет описан ниже.

В нагрузочном тестировании есть важный артефакт - отчёт о эксперименте. Помимо целей, выводов, рекомендаций, методики, отчёт содержит разного рода графики о ходе эксперимента. На основании анализа полученных графиков, большей частью, делается вывод о работе объекта. Эти графики получаются обычно из системы мониторинга (хотя откуда ещё их получить?). Есть zabbix, есть графиня, может ещё что-то диковинное, и есть Grafana. Вот она приятна, подключается много к чему, рисует красивые графики, а запросики, из которых получаются красивые графики, можно проанализировать и модифицировать буквально на лету. Думаю, это основная причина популярности.

И вот для отчёта или, может быть, оформления дефекта производительности из промышленной среды, нужно собрать максимально большое количество информации для анализа. И здесь уже не имеет значения кто будет анализировать - сам, или коллега. Нужно показать всё, что происходило и как оно себя вело. Например, для сервиса, который использует какой-нибудь кэш, пусть будет redis, нужно показать как кэш наполнялся и очищался, сколько памяти занимал и как утилизировал ЦПУ, как проходила репликация. Если ко всему используется база данных, то хорошо бы видеть, что оная не стала узким местом. Или напротив. И так далее. Думаю, что мысль понятна.

Ещё хуже, когда используются какие-нибудь виртуалки, которые находятся на другой grafana, которая вообще принадлежит другому ведомству, но утилизация этих виртуальных машин напрямую влияют на результаты эксперимента и, почему-то, эта утилизация может быть высока в некоторые моменты времени и в отчёте нужно чётко показать, что вот прямо в этом эксперименте утилизация или времена отклика увеличились в сравнении с эталоном из-за того, что новая версия использует другую версию spring boot, а не потому, что кластер виртуалок был перегружен и вам просто не повезло с моментом.

Кроме того, может быть даже так, что дисковое пространство для мониторинга в вашем контуре может быть сильно ужато и результаты экспериментов могут быть удалены по времени или по занятому пространству на дисках (а вы точно знаете, как работает ротация на вашем стенде?). И вот для этого в частности вам может быть необходимо сохранить как можно больше информации о проведённых экспериментах в отчётах. Ведь, признайтесь, есть же системы, которые нужно прогнать под нагрузкой раз в полгода или того реже?

Таким образом мы уже определили, что для отчёта хорошо бы собирать: как можно больше информации; с разных досок; по всем задействованным компонентам; иногда даже с разных grafana.

Тут есть несколько путей. Либо договариваться со всеми, что собираем только ключевые моменты и усекаем сбор, либо страдаем с ручным сбором, либо пишем свою чудо-юдо скрипт, вероятно с grafana plugin (который ещё затащить надо), который будет статичным и потребует актуализации при малейшем изменении... Мне даже перечислять все недостатки такого скрипта тошно, если честно.

Роемся в документации и понимаем, что просто передать адрес доски плагину не вариант (или это только я не нашёл?).

А что делать в этом случае? Прикручивать ИИ! Ну, можно попробовать представленный инструмент или подход. Речь дальше пойдёт о cow-grafana. Кто-то мог бы уже сейчас спросить: а почему "корова"? Ну, мне нравятся коровы. Я бы даже не попал в ИТ без них, но это в сторону.

cow-grafana - это простой скрипт, написанный на фреймворке предназначенном для функционального тестирования фронтенда. По сути он имитирует действия пользователя и умеет даже делать как "продвинутый пользователь" - заглядывать в консоль разработчика в браузере и, если нужно, читать разметку, следить за событиями в js или DOM, и даже выполнять произвольный код.

И что же дальше? Как использовать и что это даёт? А вот это самое интересное.

Для того, чтобы начать использовать, нужно выполнить несколько простых шагов

Шаг первый - скачать и установить инструмент (да, оно всё ещё не завёрнуто в docker)

Нужно скачать репозиторий. В наше непростое время приходится искать альтернативы github, так что 

git clone https://gitverse.ru/andrkornienko/cow-grafana.git

Или получите как вам удобно со страницы репозитория cow-grafana.

Само собой, в директории вашей локальной копии, в любимой оболочке, нужно будет выполнить (а перед этим поставить NodeJS, сорян)скрипт

npm install

Если вдруг не получится - расскажите об этом в комментариях. Я пока что выполнил это один раз. Вдруг что-то пойдёт не так или будут полезные уточнения?

Шаг второй - конфигурим конфиг инструмента

Далее для запуска нам потребуется правка конфигурационного файла. Он называется playwright.config.js Здесь не изменено ничего относительно поставки по-умолчанию.

И вот в конфигурационном файле нас будет интересовать секция projects.

projects: [
    { //начало блока для вашего заполнения
      name: 'service-api',
      use: {
        ...devices['Desktop Chrome'],
        launchOptions: {
          args: ['--enable-gpu']
        },
        grafanaURL: 'http://localhost:3000', //url grafana
        //адрес доски для сбора
        baseURL: 'http://localhost:3000/d/rYdddlPWk/node-exporter-full?orgId=1&from=2025-05-13T13:07:36.000Z&to=2025-05-13T15:02:56.000Z&timezone=browser&var-ds_prometheus=aels39097fe2od&var-job=&var-nodename=&var-node=&refresh=1d',
        exceptPanels: ['CPU'], //панели, которые хочется исключить при сборе
        authData: {login: 'viewer', password: 'viewer'}, //учётные данные для аутентификации
        
        // Настройки разрешения экрана с панелью (не равно конечному разрешению панели)
        viewport: { width: 1280, height: 720 },
        deviceScaleFactor: 1,
        isMobile: false,
        hasTouch: false,
      }
    }, //конец блока для вашего заполнения. Эти блоки можно копировать как показано ниже и менять только нужные параметры.
    {
      name: 'service-api',
      use: {
        ...devices['Desktop Chrome'],
        launchOptions: {
          args: ['--enable-gpu']
        },
        grafanaURL: 'http://localhost:3000',
        baseURL: 'http://localhost:3000/d/c8f73eec-67d9-44cf-88ba-bb1c6d4dc409/new-dashboard?orgId=1&from=now-6h&to=now&timezone=browser',
        exceptPanels: ['CPU'],
        authData: {login: 'viewer', password: 'viewer'},
        // Настройки разрешения экрана с панелью (не равно конечному разрешению панели)
        viewport: { width: 1280, height: 720 },
        deviceScaleFactor: 1,
        isMobile: false,
        hasTouch: false,
      }
    }
  ]
}

Кажется, что всё просто, но давайте поясню.

Например, name - это, по сути, имя директории, что будет создана. Внутри этой директории будут создаваться директории с названиями досок, что вы укажете. Я считаю, что это очень удобно. Например, если нас интересуют метрики JVM, то мы будем их искать на доске с метриками JVM. И здесь эта логика и структура сохраняется. Есть альтернативное мнение, которое заключается в том, что нужно вот прямо всё запихнуть на одну мегадоску, но оставим это мнение профильным работникам.

Далее, в блоке use можно видеть grafanaURL. Это url вашей grafana. Он нужен, чтобы правильно определить версию вашей grafana. Я дальше покажу, где это используется и как.

baseURL - это адрес вашей доски. Можно было назвать иначе, но так оно было в конфиге после установки playwright в примере и оно просто не переименовано.

exceptPanels - это для тех, кто не хочет редактировать доску и убирать лишние панели, либо эти панели не нужны в отчётах. Просто перечислите их по именам в кавычках через запятую. Скрипт просто не будет делать их снимки, но будет заходить на них посмотреть.

authData - данные для аутентификации на доске. По идее будет работать и без аутентификации, если это возможно на вашей grafana. Надо попробовать.

viewport - это про разрешение экрана. Здесь именно экрана браузера. Вы же помните, что скрипт имитирует человека? Так что придётся подбирать, пока не понравится результат, ибо разрешение снимков будет, очевидно, ниже.

Ну и всё. Базово конфиг разобран по пунктам. Остальное можно оставлять без изменений.

Шаг третий - ищем XPath'ы для своей версии Grafana

Помните, я говорил про версию? Так вот. Весь принцип работы крутится вокруг XPath'ов. И у разных версий grafana пути будут разными. (Иногда одинаковыми, если версии не далеко друг от друга.) И в случае демонстрируемого инструмента пути для конкретной версии прописаны в файле grafanaVersionsXPathes.env . Таким образом, вам с вашей более новой или более старой версией нужно будет только найти XPath'ы и вписать их по шаблону в этот файл. Далее скрипт всё сделает сам - подставит и воспользуется. Там есть пара замещающих слов (placeholder, если русский для вас не родной), но они описаны в README.md

Итого

И кто-то спросит: "и насколько ж быстро оно работает?" И я могу ответить, что оно само решит во сколько потоков собирать ваши доски, если их больше одной. Если мощности хоста хватит, то хоть сколько вам надо. А что до времени сбора доски node exporter full, например, на моём старом ноутбуке собирается за 2,7 минуты. А это, на минуточку, 122 панели.

Комментарии (0)