TIGr на страже производительности — часть 3

Введение

В предыдущей (второй) части статьи мы более подробно рассмотрели архитектуру компонентов TIGr-а, а также рассказали, как их устанавливать и настраивать в базовой конфигурации.

В этой части (третьей) мы опишем настройку Telegraf на чтение специфических Windows-счетчиков (Perf Counters) нашего продукта, подадим нагрузку на тестируемый сервер (будем «кормить Тигра»), покажем, как отображать показания этих счетчиков в Grafana, а также рассмотрим некоторые вопросы настройки Grafana в части визуализации, переменных и уведомлений (начнем «дрессировку Тигра»).

Часть 3. Приручаем TIGr-а

Кормим TIGr-а (подача нагрузки)

Прежде всего, уточним, что InfluxDB, как и серверная часть Grafana, уже должны к этому времени быть запущенными и работать (например, они у нас выделены на отдельный сервер, где всегда запущены).

Для нашего тестового продукта мы используем нагрузочный клиент, который был создан нами специально для этих целей. У вас наверняка будут свои варианты подачи нагрузки (специализированные инструменты), но в любом случае — снимать метрики будем со счетчиков Windows:

· Счетчики, которые наш продукт создает при установке (ими у нас покрыты все важные места кода)

· Системные счетчики (CPU, Memory, Disk и т.д.) — опционально, в зависимости от задач.

Теперь надо определиться со счетчиками, с которых необходимо снимать метрики. Базовые системные уже есть в нашей конфигурации (мы их оставим), просто добавим свои. Для этого, в самый конец файла конфигурации Telegraf-а нужно вставить следующие строки:

[[inputs.win_perf_counters.object]]

# Имя вашего продукта

ObjectName = “Test Engine — ClientManager”

Instances = [“default”]

Counters = [

“Имя счетчика 1”,

“Имя счетчика 2”,

“Имя счетчика …”

]

Measurement = “Test_CM”

FailOnMissing = true

Жирным шрифтом выделены места, которые необходимо поменять на свои варианты:

· Test Engine — ClientManager и Имя счетчика … — имя категории и непосредственно счетчиков, их можно посмотреть при добавлении в оснастке Системного монитора Windows:

· default — имя экземпляра выбранного объекта (счетчика), пример видно на скриншоте выше

· Test_CM — имя сбора или прогона, фактически — это таблица, куда будут записываться данные (мы это разбирали на схеме InfluxDB во второй части статьи)

· FailOnMissing = true — отладочный параметр (потом его можно убрать или поставить false), прерывает запуск Telegraf-а, если возникли проблемы с поиском каких-то счетчиков при своем запуске.

В противном случае, агент запустится, но не будет собирать такие «проблемные» счетчики, соответственно, ничего не будет отображается в Grafana, что может сбивать с толку — это нагрузки нет, не работает счетчик или что-то случилось с Telegraf-ом.

Сейчас, для упрощения понимания, мы рассматриваем пример с одним нагрузочным сценарием на один прогон автотестов. В «боевом» тестировании, сценариев в одном прогоне может быть и больше (например, «Напряженное рабочее утро», «Спокойный выходной день» и т.д.). Поэтому, в таких случаях для каждого сценария надо как-то разделять поток данных, чтобы в рамках одного прогона можно было различать тестируемые сценарии при визуализации в Grafana (это очень важный момент, по нашему мнению).

Это можно сделать, например, с помощью:

· добавления определенных тэгов в секцию [global_tags] конфигурации агента Telegraf, чтобы потом группировать по ним на графиках:

[global_tags]

scenario = “morning”

· либо сменой имени Measurement-а (таблицы) там же, в конфигурации агента, а затем фильтровать по этим параметрам при построении графиков:

Measurement = “Test_CM_Morning”

Подробнее, мы затронем эту тему в следующих частях статьи, когда начнем автоматизировать сбор данных с учетом номеров сборок продукта (билдов).

Теперь пора подавать нагрузку (у себя мы запускаем наш нагрузочный клиент, про который было сказано в самом начале этой части статьи) и уже после этого можно стартовать агент Telegraf. Если делать наоборот, то некоторое время будут идти нулевые данные, что может «портить» итоговый график. С другой стороны, может быть и сценарий, когда важно «захватить» момент старта нагрузки, поэтому оба варианта запуска могут быть полезны.

Схемы последовательности старта компонентов TIGr-а, в общем случае, выглядят так:

Пока идет нагрузка и собираются данные, пора немного донастроить наш тестовый дашборд в Grafana:

· добавляем новую панель типа «Graph» и заходим в ее настройки

· выбираем Data Source (у нас это Perf_DB, мы создавали его выше)

· ниже, в конструкторе запросов, указываем FROM default Test_CM SELECT field (имя счетчика)

· аналогично, в этом же конструкторе можно добавлять и другие счетчики (кнопка Add Query)

После этого возвращаемся к дашборду:

По минимуму — этого уже достаточно, чтобы увидеть общую картину (в примере на скриншотах выше — два тестовых прогона нагрузки с двумя графиками двух счетчиков).

Но, как это обычно бывает — приходится еще что-то настраивать под свои конкретные задачи (в первой части статьи мы как раз поставили их на своем примере), и теперь займемся доработками.

Дрессируем TIGr-а (визуализация, переменные и алерты)

Давайте начнем с алертов (alert) — это предупреждения, отправляемые по заранее настроенному транспорту (в Grafana — это каналы), которые генерируются по определенному триггеру. Каналов достаточно:

Почта, мессенджеры, webhook и др., все рассматривать сейчас не будем — там все просто, а в нашем тестовом примере уведомления настроены на почту, при этом отметим, что параметры SMTP устанавливаются в конфигурационном файле Grafana — defaults.ini

Рассмотрим пример — присылать нам письмо, если загрузка процессора на сервере с тестовым продуктом превысила 50% в определенный промежуток времени.

Заходим в свойство панели «CPU Usage» на нашем тестовом дашборде, вкладка Alert и создаем правило:

Стрелками показано, что изменено из дефолтных значений:

· установлено пороговое значение 50 (%, как у вертикальной шкалы графика)

· в выражении query(A,5m,now) — 5m заменено на 1m,

здесь А — порядковый номер запроса из конструктора (отображается в конструкторе, на вкладке «Metrics», рядом с запросами)

5m (1m) и now — просматривать период от текущего времени до минус 5-ти (1-й) минут(ы) назад.

В итоге, согласно настройкам, мы должны получать алерты на почту, если в каждый такой промежуток времени (между текущим и минус одна минута) среднее значение (avg) всех результатов запроса «А» (в этой панели для CPU он там один) будет превышать 50%.

Проще говоря: подали нагрузку, прошла одна минута, если средняя загрузка CPU в эту минуту была выше 50%, то придет письмо. И так каждую минуту — алерт либо будет, либо нет. Это, конечно же, только пример, в реальности с такими настройками нас может «засыпать» письмами (если CPU загружен, как это часто бывает в тестах), поэтому настройки надо подбирать опытным путем, исходя из своих требований к уведомлениям.

С остальными параметрами алертов разобраться не сложно, поэтому их описывать не будем.

На практике получается так: подаем нагрузку на процессор рабочей станции (где установлен агент Telegraf), чтобы было периодически более 50% и скоро на почту получим письмо с темой «[Alerting] Cpu Usage alert», в которое приложен снимок графика, в интервале которого сработал этот алерт:

Вертикальная красная прерывистая линия — здесь сработал алерт, горизонтальная — пороговое значение алерта (в нашем примере — 50%).

Важный момент: в конструкторе запроса метрик не должно быть переменных (типа /^server$/ или $server):

Иначе алерты работать не будут, т.к. в подсистеме запросов для алертов использование переменных в метриках не поддерживается:

На эту проблему или недоработку есть очень много жалоб в официальном багтрекере (например, здесь), но до сих пор разработчики никак её не исправят или не реализуют (официально про это ограничение здесь).

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

То надо использовать переменную, например «Build»:

Теперь, если мы захотим добавить алерт на этот график, то нам будет выдано сообщение, что «Template variables are not supported in alert queries» (пример есть на скриншоте чуть выше).

Немного про переменные в Grafana. Они предназначены для настройки отображения панелей и других единиц визуализации дашборда по заранее определенным фильтрам, например: источник данных, имя станции, диска или сетевого адаптера, номер сборки продукта и многое другое. Их область действия ограничена только своим дашбордом. Подробнее про переменные можно почитать в официальной документации.

Управление переменными находится в настройках дашборда:

Здесь мы можем создавать переменные разных типов:

В показанном примере мы получаем из тегов результатов запросов: имя сервера, букву диска, имя адаптера и номер сборки продукта. Затем, эти переменные можно использовать в конструкторе запросов метрик, а также при фильтрации данных дашборда (см. несколько скриншотов выше на примере переменной «Build»).

В конце этой части статьи, хотелось бы еще уточнить, какие в Grafana есть панели, таблицы и другие блоки отображения данных, которые можно добавлять на дашборд:

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

Каждую панель можно гибко настраивать под разную логику отображения данных. Мы еще к этому вернемся, когда рассмотрим пример расчета количества поддерживаемых «виртуальных клиентов» нашего тестового продукта в следующих частях статьи, при автоматизации нагрузочных автотестов.

В качестве домашнего задания, попробуйте «поиграться» со встроенными панелями: добавлять и настраивать их под свои задачи и предпочтения. Посмотреть множество образцов различных типов дашбордов и панелей, а также «поиграться» с их настройками можно и на демо-портале Grafana.

Итоги

В третьей части статьи мы описали настройку Telegraf на чтение определенных счетчиков нашего продукта, с помощью нагрузочного клиента подали нагрузку на тестируемый сервер, продемонстрировали отображение показаний этих счетчиков в Grafana, а также рассмотрели некоторые вопросы настройки Grafana в части визуализации, переменных и уведомлений.

Далее, в четвертой части, мы начнем автоматизировать работу компонентов TIGr-а с подключением сервера автоматизации тестов («учить TIGr-а выступать самостоятельно»), а также произведем конфигурирование Telegraf и Grafana с целью наглядной демонстрации динамики производительности нашего тестового продукта, как в различных сценариях прогона тестов, так и при каждой сборке («Наблюдать за успехами TIGr-а»).

Ссылки

TIGr на страже производительности — часть 1

TIGr на страже производительности — часть 2

Автор статьи: Евгений Климов, Системный инженер, ITA Labs