Автоматизація навантажувального тестування: зв'язка Jmeter + TeamCity + Grafana



Зображення: Flickr

В нашому блозі на Хабре ми продовжуємо розповідати про побудову DevOps-культури в компанії — наприклад, в одному з останніх топіків ми описували те, які завдання вирішуємо за допомогою системи SaltStack. Сьогодні мова піде про іншу цікаву тему — автоматизації навантажувального тестування за допомогою зв'язки декількох готових інструментів.

Як було раніше
Нам потрібно було моніторити сервери, на яких проводилося навантажувальне тестування збирати метрики продуктивності процесора, пам'яті, операційної системи і т. п. Також необхідно було відстежувати стан баз даних, шини та черг, також іноді потрібно було іноді працювати з логами. Всі ці завдання вирішувалися Python-скриптами нашої власної розробки, інформація зберігалася в SQLite-базі, а звіти формувалися з допомогою CSV-файлів.

Ось ця схема:



Мінуси такого підходу:

  • Все, що виділено на картинці фігурною дужкою, згодом мертвим вантажем зберігалося в артифактории, аналізувати дані було вкрай складно.
  • Наша функціональність дозволяла будувати звіт тільки з жорсткою формою — без фільтрів і відображення кореляцій.
  • Головний мінус — звіт генерувався тільки по закінченні тесту.
Нова зв'язка
В кінцевому підсумку ми відмовилися від власних велосипедів і вирішили скористатися плодами чужих праць. У підсумку народилася нова зв'язка з декількох інструментів.

Зберігання даних
В якості системи зберігання даних був використаний продукт InfluxDB. Це одна з небагатьох СУБД, створена для зберігання тимчасових рядів показників продуктивності, аналітики, подій). Вона вміє агрегувати дані на льоту, також системою легко користуватися завдяки тому, що в ній застосовується SQL-like синтаксис. З інших плюсів:

  • Підтримка регулярних виразів.
  • Автоматичне очищення старих даних.
  • Масштабованість.
  • Наявність бібліотек для популярних мов.
  • Легке розгортання і адміністрування.
Розглянемо приклад використання InfluxDB для вимірювань. Припустимо, нам потрібно виміряти температуру машини X типу Y в інтервалі часу.

Для цього у нас є параметри:

  • Вимір: temperature;
  • Теги: machine, type;
  • Поля: internal_temperatre, external_temperature.
Теги використовуються для агрегації і фільтрації, полях містяться дані для зберігання — вони не індексуються, зберігається лише одне значення для комбінації «вимір + тег + timestamp», задається тимчасова точність (с, мс, мкс, нс). Тривалість зберігання даних задається політикою очищення.

Ось як буде виглядати вимір:

temperature, machine-unit42,type=assembly internal=32, external=100 1434055562000000035

Його легко сформувати, легко передати і для цього не потрібно великих витрат ресурсів.

Моніторинг
В якості засобу для моніторингу ми вирішили використовувати Zabbix. Застосовуємо кросплатформені агенти на Windows і Linux-хостах. Використовуються як пасивні, так і активні перевірки. Через активні перевірки реалізований збір метрик з хостів із закритих мереж. Крім того, ми активно використовували функцію autodiscovery для віртуальних машин на хостах з ESXi.

Аналіз
Інструментом для аналізу даних застосовується відкритий проект grafana — він відмінно підходить для створення дашбордов, побудови графіків і шаблонізації запитів і дашбордов. Система вміє будувати запити для різних джерел даних — тих же InfluxDB, Zabbix, Elasticsearch і т. п. Взагалі продукт дійсно зручний можна створювати підписи до записів і плейлисти, здійснювати пошук по дашбордам, здійснювати експорт і імпорт даних.

Ну і не можна не згадати інтерфейс, який не змушує очі кровоточити (привіт, Zabbix).



Кінцева конфігурація
Після розгляду елементів системи, поговоримо про те, як це все в підсумку працює разом.

Всі важливі метрики операційної системи і заліза моніторяться з допомогою Zabbix, а також за допомогою модернізованих скриптів-колекторів на Python. Метрики, зібрані скриптами зберігаються в InfluxDB, інформація відображається в Grafana.



Автоматизація
Підготувавши інфраструктуру, ми зайнялися питаннями автоматизації тестування. Для цього був використаний продукт Apache JMeter. Ось для чого він потрібен:

  • Він може повністю емулювати роботу реальних користувачів з системою — в нашому випадку запитів між сервером і браузером.
  • Система генерує статистичні дані по роботі сервера — наприклад, час обробки вхідних запитів та обробки приходять відповідей.
  • Відправляє результати роботи в InfluxDB і для відображення в Grafana.
На шляху його впровадження необхідно було вирішити кілька проблем.

  • Потрібно було розробити простий механізм розгортання інструменту на серверах.
  • Налагодити легкий процес запуску і проведення навантажувального тестування.
  • Розробити просту інтеграцію результатів тестування в Grafana.
  • Організувати онлайн-моніторинг проведення навантажувального тестування.
Ось, що ми зробили для їх вирішення:

  • Розробили навантажувальний скрипт, який покриває до 80% всіх користувальницьких операцій.
  • Впровадили механізм запуску тестування через TeamCity.
  • Реалізували відображення онлайн-статистики по роботі нашого продукту MaxPatrol UI.
  • Зробили просте оновлення скриптів через Git.
Ось так виглядає інтерфейс запуску задачі тестування в TeamCity:



Для відправки даних в InfluxDB у Jmeter є вбудований плагін (Backend Listener)



Підсумок: як все працює
Зараз процес навантажувального тестування являє собою запуск задачі в TeamCity — потрібно лише вибрати потрібні параметри при старті. Далі статистичні дані по роботі UI відображаються у вигляді готових інтерактивних графіків. Оновлені скрипти автоматично підтягуються через Git в TeamCity.

p.s. Розповідь про наш досвід використання SaltStack був представлений в рамках DevOps-митапа, який відбувся восени 2016 року в Москві.

Відео:



Слайди:



посилання представлені презентації 16 доповідей, представлених в ході заходу. Всі презентації та відео виступів додано в таблицю в кінці цього топіка-анонсу.

Автори: Іван Останін, Сергій Тихонов
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.