Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to QA Fes 2016. Александр Неделяев. Система мониторинга производительности своими руками
Similar to QA Fes 2016. Александр Неделяев. Система мониторинга производительности своими руками (20)
More from QAFest
More from QAFest (20)
QA Fes 2016. Александр Неделяев. Система мониторинга производительности своими руками
- 1. Киев 2016 Первый в Украине фестиваль тестирования Система мониторинга производительности своими руками Александр Неделяев
- 2. Киев 2016 О себе nedeliaev@gmail.com nedeliaev Alexander Nedeliaev Система мониторинга производительности своими руками
- 3. Киев 2016 С чего все началось Система мониторинга производительности своими руками
- 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. Киев 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. Киев 2016 Готовые решения APM Система мониторинга производительности своими руками
- 7. Киев 2016 Почему нет? • Масштабность • Неготовность приложения • Целесообразность • Стоимость Система мониторинга производительности своими руками
- 8. Киев 2016 Кастомное решение Система мониторинга производительности своими руками
- 9. Киев 2016 Отправная точка Система мониторинга производительности своими руками http://jmeter.apache.org/usermanual/realtime-results.html
- 10. Киев 2016 Что лежит в основе мониторинга? Система мониторинга производительности своими руками Метрика Значение Отметка времени
- 11. Киев 2016 Временные ряды Система мониторинга производительности своими руками
- 12. Киев 2016 В чем недостаток JMeter Чрезмерное потребление ресурсов Слабая визуализация результатов Фрагментарность Неудобство работы с данными Система мониторинга производительности своими руками
- 13. Киев 2016 Инструменты Система мониторинга производительности своими руками
- 14. Киев 2016 Структура Сбор данных из различных источников Запись и хранение данных в базе Визуализация данных Оповещения Система мониторинга производительности своими руками
- 15. Киев 2016 Структура Система мониторинга производительности своими руками
- 16. Киев 2016 Визуализация Система мониторинга производительности своими руками
- 17. Киев 2016 План Система мониторинга производительности своими руками
- 18. Киев 2016 Установка и конфигурация Система мониторинга производительности своими руками https://docs.docker.com https://hub.docker.com
- 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. Киев 2016 Установка InfluxDB и Grafana Система мониторинга производительности своими руками Из папки проекта: docker-compose up -d http://bit.ly/qamonitoring
- 21. Киев 2016 Настраиваем JMeter Система мониторинга производительности своими руками http://jmeter.apache.org/usermanual/realtime-results.html
- 22. Киев 2016 Настраиваем Grafana Система мониторинга производительности своими руками
- 23. Киев 2016 Что я хочу видеть Система мониторинга производительности своими руками
- 24. Киев 2016 Что я хочу видеть Инфраструктурные метрики Метрики производительности приложения События Сравнительный анализ данных Совместная работа, sharing Бизнес метрики Оповещения Система мониторинга производительности своими руками
- 25. Киев 2016 Что я хочу видеть Инфраструктурные метрики Метрики производительности приложения События Сравнительный анализ данных Совместная работа, sharing Бизнес метрики Оповещения Система мониторинга производительности своими руками
- 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. Киев 2016 Инфраструктурные метрики - Windows Система мониторинга производительности своими руками https://hodgkins.io/using-powershell-to-send-metrics-graphite https://github.com/MattHodge/Graphite-PowerShell-Functions
- 28. Киев 2016 Что я хочу видеть Инфраструктурные метрики Метрики производительности приложения События Сравнительный анализ данных Совместная работа, sharing Бизнес метрики Оповещения Система мониторинга производительности своими руками
- 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. Киев 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. Киев 2016 Запускаем Jmeter тест Система мониторинга производительности своими руками jmeter -n -t your_script.jmx где -n: инструкиция запускать Jmeter без GUI -t: путь к .jmx файлу, который нужно запускать
- 32. Киев 2016 Проверяем данные в InfluxDB Система мониторинга производительности своими руками http://<docker-machine ip>:8083
- 33. Киев 2016 Создаем Grafana dashboard Система мониторинга производительности своими руками http://<docker-machine ip>:3000/dashboard/new
- 34. Киев 2016 Добавляем графики Система мониторинга производительности своими руками
- 35. Киев 2016 Настраиваем графики Система мониторинга производительности своими руками
- 36. Киев 2016 Настраиваем графики Система мониторинга производительности своими руками
- 37. Киев 2016 Улучшаем графики Система мониторинга производительности своими руками
- 38. Киев 2016 Устанавливаем зависимости Система мониторинга производительности своими руками
- 39. Киев 2016 Параметры отображения Система мониторинга производительности своими руками
- 40. Киев 2016 Что я хочу видеть Инфраструктурные метрики Метрики производительности приложения События Сравнительный анализ данных Совместная работа, sharing Бизнес метрики Оповещения Система мониторинга производительности своими руками
- 41. Киев 2016 Аннотации Система мониторинга производительности своими руками curl -i -XPOST 'http://<docker-machine ip>:8086/write?db=jmeter' --data-binary 'alerts event="Deploy to prod"'
- 42. Киев 2016 Аннотации Система мониторинга производительности своими руками
- 43. Киев 2016 Что я хочу видеть Инфраструктурные метрики Метрики производительности приложения События Сравнительный анализ данных Совместная работа, sharing Бизнес метрики Оповещения Система мониторинга производительности своими руками
- 44. Киев 2016 Сравнительный анализ данных Система мониторинга производительности своими руками
- 45. Киев 2016 Что я хочу видеть Инфраструктурные метрики Метрики производительности приложения События Сравнительный анализ данных Совместная работа, sharing Бизнес метрики Оповещения Система мониторинга производительности своими руками
- 46. Киев 2016 Совместная работа Система мониторинга производительности своими руками
- 47. Киев 2016 Совместная работа Система мониторинга производительности своими руками
- 48. Киев 2016 Планы на будущее Инфраструктурные метрики Метрики производительности приложения События Сравнительный анализ данных Совместная работа, sharing Бизнес метрики Оповещения Система мониторинга производительности своими руками
- 49. Киев 2016 Что получилось Система мониторинга производительности своими руками
- 50. Киев 2016 Что получилось Система мониторинга производительности своими руками
- 51. Киев 2016 Taurus Система мониторинга производительности своими руками docker run --rm -v <path-to-files>:/bzt-configs undera/bzt:v1.6.5 https://bit.ly/qataurus
- 52. Киев 2016 Taurus Система мониторинга производительности своими руками
- 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: Этого пока нету, но есть варианты Прометеус Яндекс танк
- компонуем разные инструменты (жметр + графит, графана) привязать это к дженкинсу, зашарить снепшот с графаны, запустить таурус или танк, репортинг от тауруса