Successfully reported this slideshow.

QA Fes 2016. Александр Неделяев. Система мониторинга производительности своими руками

2

Share

1 of 53
1 of 53

QA Fes 2016. Александр Неделяев. Система мониторинга производительности своими руками

2

Share

Как известно, то, что не может быть измерено, не может быть улучшено.
В своем докладе я расскажу вам о том, как с помощью open source инструментов можно построить систему мониторинга производительности приложения, а также представить полученные данные в доступной и наглядной форме. А технология контейнеров Docker поможет сделать это максимально быстро и просто.

Как известно, то, что не может быть измерено, не может быть улучшено.
В своем докладе я расскажу вам о том, как с помощью open source инструментов можно построить систему мониторинга производительности приложения, а также представить полученные данные в доступной и наглядной форме. А технология контейнеров Docker поможет сделать это максимально быстро и просто.

More Related Content

More from QAFest

Related Books

Free with a 14 day trial from Scribd

See all

QA Fes 2016. Александр Неделяев. Система мониторинга производительности своими руками

  1. 1. Киев 2016 Первый в Украине фестиваль тестирования Система мониторинга производительности своими руками Александр Неделяев
  2. 2. Киев 2016 О себе nedeliaev@gmail.com nedeliaev Alexander Nedeliaev Система мониторинга производительности своими руками
  3. 3. Киев 2016 С чего все началось Система мониторинга производительности своими руками
  4. 4. Киев 2016 Слои мониторинга •OS •CRM •ERP •Email Application •Database: Oracle, SQL Server, MySQL •Web servers: IIS, Apache •Application servers: WebSphere, Tomcat, JBoss, MS .Net Middleware •Servers: Windows Server, Solaris, Linux •Virtualization: VMware, Hyper-V, Citrix XenServer •Storage: SAN, NAS, RAID, S.M.A.R.T •Network: LAN, WLAN, VPN Hardware Система мониторинга производительности своими руками
  5. 5. Киев 2016 Слои мониторинга •OS •CRM •ERP •Email Application •Database: Oracle, SQL Server, MySQL •Web servers: IIS, Apache •Application servers: WebSphere, Tomcat, JBoss, MS .Net Middleware •Servers: Windows Server, Solaris, Linux •Virtualization: VMware, Hyper-V, Citrix XenServer •Storage: SAN, NAS, RAID, S.M.A.R.T •Network: LAN, WLAN, VPN Hardware Система мониторинга производительности своими руками
  6. 6. Киев 2016 Готовые решения APM Система мониторинга производительности своими руками
  7. 7. Киев 2016 Почему нет? • Масштабность • Неготовность приложения • Целесообразность • Стоимость Система мониторинга производительности своими руками
  8. 8. Киев 2016 Кастомное решение Система мониторинга производительности своими руками
  9. 9. Киев 2016 Отправная точка Система мониторинга производительности своими руками http://jmeter.apache.org/usermanual/realtime-results.html
  10. 10. Киев 2016 Что лежит в основе мониторинга? Система мониторинга производительности своими руками  Метрика  Значение  Отметка времени
  11. 11. Киев 2016 Временные ряды Система мониторинга производительности своими руками
  12. 12. Киев 2016 В чем недостаток JMeter  Чрезмерное потребление ресурсов  Слабая визуализация результатов  Фрагментарность  Неудобство работы с данными Система мониторинга производительности своими руками
  13. 13. Киев 2016 Инструменты Система мониторинга производительности своими руками
  14. 14. Киев 2016 Структура  Сбор данных из различных источников  Запись и хранение данных в базе  Визуализация данных  Оповещения Система мониторинга производительности своими руками
  15. 15. Киев 2016 Структура Система мониторинга производительности своими руками
  16. 16. Киев 2016 Визуализация Система мониторинга производительности своими руками
  17. 17. Киев 2016 План Система мониторинга производительности своими руками
  18. 18. Киев 2016 Установка и конфигурация Система мониторинга производительности своими руками https://docs.docker.com https://hub.docker.com
  19. 19. Киев 2016 Команды Docker • docker pull [image] • docker run -d -e [environmentVariable] -p [ports] • docker start / stop [containerID] • docker-machine ip • docker images -a • docker ps -a • docker rm [containerID] • docker rmi [image] Система мониторинга производительности своими руками
  20. 20. Киев 2016 Установка InfluxDB и Grafana Система мониторинга производительности своими руками Из папки проекта: docker-compose up -d http://bit.ly/qamonitoring
  21. 21. Киев 2016 Настраиваем JMeter Система мониторинга производительности своими руками http://jmeter.apache.org/usermanual/realtime-results.html
  22. 22. Киев 2016 Настраиваем Grafana Система мониторинга производительности своими руками
  23. 23. Киев 2016 Что я хочу видеть Система мониторинга производительности своими руками
  24. 24. Киев 2016 Что я хочу видеть  Инфраструктурные метрики  Метрики производительности приложения  События  Сравнительный анализ данных  Совместная работа, sharing  Бизнес метрики  Оповещения Система мониторинга производительности своими руками
  25. 25. Киев 2016 Что я хочу видеть  Инфраструктурные метрики  Метрики производительности приложения  События  Сравнительный анализ данных  Совместная работа, sharing  Бизнес метрики  Оповещения Система мониторинга производительности своими руками
  26. 26. Киев 2016 Инфраструктурные метрики - Linux CollectD: • CPU used/ free/ idle/ etc • Free disk (via mounting hosts '/' into container, eg: -v /:/hostfs:ro) • Disk performance • Load average • Memory used/ free/ etc • Uptime • Network interface • Swap https://github.com/andreasjansson/docker-collectd-write-graphite Система мониторинга производительности своими руками
  27. 27. Киев 2016 Инфраструктурные метрики - Windows Система мониторинга производительности своими руками https://hodgkins.io/using-powershell-to-send-metrics-graphite https://github.com/MattHodge/Graphite-PowerShell-Functions
  28. 28. Киев 2016 Что я хочу видеть  Инфраструктурные метрики  Метрики производительности приложения  События  Сравнительный анализ данных  Совместная работа, sharing  Бизнес метрики  Оповещения Система мониторинга производительности своими руками
  29. 29. Киев 2016 Метрики производительности приложения <rootMetricsPrefix>test.minAT Min active threads <rootMetricsPrefix>test.maxAT Max active threads <rootMetricsPrefix>test.meanAT Mean active threads <rootMetricsPrefix>test.startedT Started threads <rootMetricsPrefix>test.endedT Finished threads Система мониторинга производительности своими руками
  30. 30. Киев 2016 <rootMetricsPrefix><samplerName>.a.count Number of responses for sampler name <rootMetricsPrefix><samplerName>.a.min Min response time for responses of sampler name <rootMetricsPrefix><samplerName>.a.max Max response time for responses of sampler name <rootMetricsPrefix><samplerName>.h.count Server hits per seconds <rootMetricsPrefix><samplerName>.a.pct<percentile> Percentile computed for responses of sampler name Метрики производительности приложения Система мониторинга производительности своими руками
  31. 31. Киев 2016 Запускаем Jmeter тест Система мониторинга производительности своими руками jmeter -n -t your_script.jmx где -n: инструкиция запускать Jmeter без GUI -t: путь к .jmx файлу, который нужно запускать
  32. 32. Киев 2016 Проверяем данные в InfluxDB Система мониторинга производительности своими руками http://<docker-machine ip>:8083
  33. 33. Киев 2016 Создаем Grafana dashboard Система мониторинга производительности своими руками http://<docker-machine ip>:3000/dashboard/new
  34. 34. Киев 2016 Добавляем графики Система мониторинга производительности своими руками
  35. 35. Киев 2016 Настраиваем графики Система мониторинга производительности своими руками
  36. 36. Киев 2016 Настраиваем графики Система мониторинга производительности своими руками
  37. 37. Киев 2016 Улучшаем графики Система мониторинга производительности своими руками
  38. 38. Киев 2016 Устанавливаем зависимости Система мониторинга производительности своими руками
  39. 39. Киев 2016 Параметры отображения Система мониторинга производительности своими руками
  40. 40. Киев 2016 Что я хочу видеть  Инфраструктурные метрики  Метрики производительности приложения  События  Сравнительный анализ данных  Совместная работа, sharing  Бизнес метрики  Оповещения Система мониторинга производительности своими руками
  41. 41. Киев 2016 Аннотации Система мониторинга производительности своими руками curl -i -XPOST 'http://<docker-machine ip>:8086/write?db=jmeter' --data-binary 'alerts event="Deploy to prod"'
  42. 42. Киев 2016 Аннотации Система мониторинга производительности своими руками
  43. 43. Киев 2016 Что я хочу видеть  Инфраструктурные метрики  Метрики производительности приложения  События  Сравнительный анализ данных  Совместная работа, sharing  Бизнес метрики  Оповещения Система мониторинга производительности своими руками
  44. 44. Киев 2016 Сравнительный анализ данных Система мониторинга производительности своими руками
  45. 45. Киев 2016 Что я хочу видеть  Инфраструктурные метрики  Метрики производительности приложения  События  Сравнительный анализ данных  Совместная работа, sharing  Бизнес метрики  Оповещения Система мониторинга производительности своими руками
  46. 46. Киев 2016 Совместная работа Система мониторинга производительности своими руками
  47. 47. Киев 2016 Совместная работа Система мониторинга производительности своими руками
  48. 48. Киев 2016 Планы на будущее  Инфраструктурные метрики  Метрики производительности приложения  События  Сравнительный анализ данных  Совместная работа, sharing  Бизнес метрики  Оповещения Система мониторинга производительности своими руками
  49. 49. Киев 2016 Что получилось Система мониторинга производительности своими руками
  50. 50. Киев 2016 Что получилось Система мониторинга производительности своими руками
  51. 51. Киев 2016 Taurus Система мониторинга производительности своими руками docker run --rm -v <path-to-files>:/bzt-configs undera/bzt:v1.6.5 https://bit.ly/qataurus
  52. 52. Киев 2016 Taurus Система мониторинга производительности своими руками
  53. 53. Киев 2016 Спасибо nedeliaev@gmail.com nedeliaev Alexander Nedeliaev Система мониторинга производительности своими руками

Editor's Notes

  • Небольшой экскурс в историю:
    - Тихо и спокойно тестировал фронтенд, пока мне не сделали предложение, от которого было сложно отказаться
    2 года работы в отделе сервис оперейшнс

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

    Вывод:
    Нужно мониторить приложение и со стороны пользователя
    Нужно мониторить при постоянной нагрузге – проактивный мониторинг (или как минимум долгое время) (если правильно сэмулировать нагрузку, мы узнаем о проблемах раньше, чем пользователь)
  • Что можно было полезного взять у админов для тестировщика – это мониторинг
    Подходы у тестировщиков и у админов отличаются, однако нужно брать лучшее друг от друга.
    Из чего состоит типичная клиент серверная система?

  • Видел, что мониторятся только серверные ресурсы. Такие как память, загрузка процессора, емкость дисков и тд.
    Но в то же время встречались жалобы со стороны пользователей на недостаточную производительность.
  • Есть несколько продуктов, которые позволяют мониторить производительность приложения.
    Что они делают
    Мониторят железо и поведение пользователя
    Позволяют понять топологию приложения по слоям – от инфраструктуры, промежуточное по и само приложение
    Отслеживают связь между компонентами

    Все они хороши по своему, но
    Не всегда нужны в таком масштабе нам
    Стоят много денег
    Не нужны заказчику
  • Масштабность
    Большие и громоздкие системы

    Неготовность приложения
    Нету кастомных метрик

    Целесообразность
    Нужно ли такое кол-во метрик

    Стоимость
    Дорого
  • Гибридное решение
  • Однажды создавая тесты для одного приложения в jmeter, я наткнулся на такую полезную вещь как backend listener
    И после этого началось мое путешествие в захватывающий мир графиков, отчетов и дешбордов
  • Для каждой метрики собираются значения в определенный момент времени.
    Временная отметка – метрика – значение
    12,00 – свободной опреативной памяти – 2 гб

    Jmeter собирает данные по этому же принципу
    12,00 – логин – 2 мс

    Это называется временные ряды

  • Временно́й ряд (или ряд динамики) — собранный в разные моменты времени статистический материал о значении каких-либо параметров (в простейшем случае одного) исследуемого процесса. Каждая единица статистического материала называется измерением или отсчётом, также допустимо называть его уровнем на указанный с ним момент времени. Во временном ряде для каждого отсчёта должно быть указано время измерения или номер измерения по порядку. Временной ряд существенно отличается от простой выборки данных, так как при анализе учитывается взаимосвязь измерений со временем, а не только статистическое разнообразие и статистические характеристики выборки[1].
  • Очень ресурсоемкий (как можно меньше включенных лисенеров)
    Тормозит систему (пример с локальными тестами)
    Выедает свободное место на диске
    Чтобы поделиться результатом, надо ждать пока добежит тест, чтобы получить лог (если не в ГУИ)
    Если говорить о том, что мониторить будем долго, то жметер отпадает...

    Неудобство хранения данных
    Некрасивые стандартные отчеты

    И какой смысл в джметре, если есть специальные инструменты?
    Сейчас есть специальные базы данных для работы с временными рядами. Time series database
    Поскольку это их основная цель, то они производительны и хорошо справляются со своей задачей.
    Чтобы все это хранить и обрабатывать, нужен адекватный и производительный инструмент.

    Сказать о скорости записи на диск и производительности


    Чрезмерное потребление ресурсов

    Слабая визуализация результатов

    Фрагментарность (Сложность скомпоновать все данные на 1 дешборде)

    Неудобство работы с данными (выборку данных за период)
  • Имея базу данных, мы решили вопрос места для хранения данных.
    Остается 2 вопроса
    Откуда их получать
    Как их визуализировать

    The architecture in a nutshell
    Graphite consists of 3 software components:
    carbon - a Twisted daemon that listens for time-series data
    whisper - a simple database library for storing time-series data (similar in design to RRD)
    graphite webapp - A Django webapp that renders graphs on-demand using Cairo
    Feeding in your data is pretty easy, typically most of the effort is in collecting the data to begin with. As you send datapoints to Carbon, they become immediately available for graphing in the webapp. The webapp offers several ways to create and display graphs including a simple URL API for rendering that makes it easy to embed graphs in other webpages.


    InfluxDB
    Graphite
    Prometheus
    OpenTSDB



    Имея базу данных, мы решили вопрос места для хранения данных.
    Остается 2 вопроса
    Откуда их получать (сборщик, база, вебморда)
    Как их визуализировать
  • Любому системному администратору постоянно приходится иметь дело с данными, представленными в форме временных рядов (time series): статистика скачивания файлов, статистика запросов к серверам, данные об использовании системных и аппаратных ресурсов виртуальными машинами… Чтобы все это хранить и обрабатывать, нужен адекватный и производительный инструмент. 
  • Например в инфлюксе
    HTTP API
    Carbon
    UDP
    telegraf

    Несомненным плюсом InfluxDB являются и широкие возможности интеграции с другими программными продуктами — например, инструментом для обработки логов Fluentd, демонами для сбора статистики CollectD и и StatsD, фреймворками для мониторинга Sensu и Shinken.
  • Graphite web app
    Chronograph
    Prometheus
    Grafana

    Немного рассказать о графане

    Роль визуализации - Добавляет
  • Jmeter/ Server  Graphite  InfluxDB --> Grafana
  • Коротко о докер
  • Мониторинг железа (проц, память, диск, сеть)
    Сбор бизнес метрик (регистрации, логины, кол-во заказов)
    Отслеживание событий (деплоймент, изменение конфигурации)
    Сбор тестовых метрик (время отклика, процент ошибок)

    This looks like a lot of stuff, so why are we doing all this? The key motivation is to bring metrics together from various sources and look at them side by side so we can correlate the data and understand cause and effect. The various data sources of interest are:
  • Мониторинг железа (проц, память, диск, сеть)
    Сбор бизнес метрик (регистрации, логины, кол-во заказов)
    Отслеживание событий (деплоймент, изменение конфигурации)
    Сбор тестовых метрик (время отклика, процент ошибок)

    This looks like a lot of stuff, so why are we doing all this? The key motivation is to bring metrics together from various sources and look at them side by side so we can correlate the data and understand cause and effect. The various data sources of interest are:
  • Рассказать об опыте с опсами
  • Демоны, повершелл, jmeter plugin
  • Мониторинг железа (проц, память, диск, сеть)
    Сбор бизнес метрик (регистрации, логины, кол-во заказов)
    Отслеживание событий (деплоймент, изменение конфигурации)
    Сбор тестовых метрик (время отклика, процент ошибок)

    This looks like a lot of stuff, so why are we doing all this? The key motivation is to bring metrics together from various sources and look at them side by side so we can correlate the data and understand cause and effect. The various data sources of interest are:
  • Готовы приступить к Графана
    Сначала я хотел создать стандартный дешборд и поделиться им
  • Уровни сервиса (желтая и красная линия)
    Несколько графика на 1 форме
  • Провалиться глубже если что то подозрительное увидел
  • Провалиться глубже если что то подозрительное увидел
  • Мониторинг железа (проц, память, диск, сеть)
    Сбор бизнес метрик (регистрации, логины, кол-во заказов)
    Отслеживание событий (деплоймент, изменение конфигурации)
    Сбор тестовых метрик (время отклика, процент ошибок)

    This looks like a lot of stuff, so why are we doing all this? The key motivation is to bring metrics together from various sources and look at them side by side so we can correlate the data and understand cause and effect. The various data sources of interest are:
  • Мониторинг железа (проц, память, диск, сеть)
    Сбор бизнес метрик (регистрации, логины, кол-во заказов)
    Отслеживание событий (деплоймент, изменение конфигурации)
    Сбор тестовых метрик (время отклика, процент ошибок)

    This looks like a lot of stuff, so why are we doing all this? The key motivation is to bring metrics together from various sources and look at them side by side so we can correlate the data and understand cause and effect. The various data sources of interest are:
  • Мониторинг железа (проц, память, диск, сеть)
    Сбор бизнес метрик (регистрации, логины, кол-во заказов)
    Отслеживание событий (деплоймент, изменение конфигурации)
    Сбор тестовых метрик (время отклика, процент ошибок)

    This looks like a lot of stuff, so why are we doing all this? The key motivation is to bring metrics together from various sources and look at them side by side so we can correlate the data and understand cause and effect. The various data sources of interest are:
  • Мониторинг железа (проц, память, диск, сеть)
    Сбор бизнес метрик (регистрации, логины, кол-во заказов)
    Отслеживание событий (деплоймент, изменение конфигурации)
    Сбор тестовых метрик (время отклика, процент ошибок)

    This looks like a lot of stuff, so why are we doing all this? The key motivation is to bring metrics together from various sources and look at them side by side so we can correlate the data and understand cause and effect. The various data sources of interest are:
  • Мониторинг железа (проц, память, диск, сеть)
    Сбор бизнес метрик (регистрации, логины, кол-во заказов)
    Отслеживание событий (деплоймент, изменение конфигурации)
    Сбор тестовых метрик (время отклика, процент ошибок)

    This looks like a lot of stuff, so why are we doing all this? The key motivation is to bring metrics together from various sources and look at them side by side so we can correlate the data and understand cause and effect. The various data sources of interest are:

    Этого пока нету, но есть варианты
    Прометеус
    Яндекс танк
  • компонуем разные инструменты (жметр + графит, графана) привязать это к дженкинсу, зашарить снепшот с графаны, запустить таурус или танк, репортинг от тауруса
  • ×