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

Editor's Notes

• #4: Небольшой экскурс в историю: - Тихо и спокойно тестировал фронтенд, пока мне не сделали предложение, от которого было сложно отказаться 2 года работы в отделе сервис оперейшнс Подходы у тестировщиков и у админов отличаются, однако нужно брать лучшее друг от друга. Видел, что мониторятся только серверные ресурсы. Такие как память, загрузка процессора, емкость дисков и тд. Но в то же время встречались жалобы со стороны пользователей на недостаточную производительность. Вывод: Нужно мониторить приложение и со стороны пользователя Нужно мониторить при постоянной нагрузге – проактивный мониторинг (или как минимум долгое время)(если правильно сэмулировать нагрузку, мы узнаем о проблемах раньше, чем пользователь)
• #5: Что можно было полезного взять у админов для тестировщика – это мониторинг Подходы у тестировщиков и у админов отличаются, однако нужно брать лучшее друг от друга. Из чего состоит типичная клиент серверная система?
• #6: Видел, что мониторятся только серверные ресурсы. Такие как память, загрузка процессора, емкость дисков и тд. Но в то же время встречались жалобы со стороны пользователей на недостаточную производительность.
• #7: Есть несколько продуктов, которые позволяют мониторить производительность приложения. Что они делают Мониторят железо и поведение пользователя Позволяют понять топологию приложения по слоям – от инфраструктуры, промежуточное по и само приложение Отслеживают связь между компонентами Все они хороши по своему, но Не всегда нужны в таком масштабе нам Стоят много денег Не нужны заказчику
• #8: Масштабность Большие и громоздкие системы Неготовность приложения Нету кастомных метрик Целесообразность Нужно ли такое кол-во метрик Стоимость Дорого
• #9: Гибридное решение
• #10: Однажды создавая тесты для одного приложения в jmeter, я наткнулся на такую полезную вещь как backend listener И после этого началось мое путешествие в захватывающий мир графиков, отчетов и дешбордов
• #11: Для каждой метрики собираются значения в определенный момент времени. Временная отметка – метрика – значение 12,00 – свободной опреативной памяти – 2 гб Jmeter собирает данные по этому же принципу 12,00 – логин – 2 мс Это называется временные ряды
• #12: Временно́й ряд (или ряд динамики) — собранный в разные моменты времени статистический материал о значении каких-либо параметров (в простейшем случае одного) исследуемого процесса. Каждая единица статистического материала называется измерением или отсчётом, также допустимо называть его уровнем на указанный с ним момент времени. Во временном ряде для каждого отсчёта должно быть указано время измерения или номер измерения по порядку. Временной ряд существенно отличается от простой выборки данных, так как при анализе учитывается взаимосвязь измерений со временем, а не только статистическое разнообразие и статистические характеристики выборки[1].
• #13: Очень ресурсоемкий (как можно меньше включенных лисенеров) Тормозит систему (пример с локальными тестами) Выедает свободное место на диске Чтобы поделиться результатом, надо ждать пока добежит тест, чтобы получить лог (если не в ГУИ) Если говорить о том, что мониторить будем долго, то жметер отпадает... Неудобство хранения данных Некрасивые стандартные отчеты И какой смысл в джметре, если есть специальные инструменты? Сейчас есть специальные базы данных для работы с временными рядами. Time series database Поскольку это их основная цель, то они производительны и хорошо справляются со своей задачей. Чтобы все это хранить и обрабатывать, нужен адекватный и производительный инструмент. Сказать о скорости записи на диск и производительности Чрезмерное потребление ресурсов Слабая визуализация результатов Фрагментарность (Сложность скомпоновать все данные на 1 дешборде) Неудобство работы с данными (выборку данных за период)
• #14: Имея базу данных, мы решили вопрос места для хранения данных. Остается 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 вопроса Откуда их получать (сборщик, база, вебморда) Как их визуализировать
• #15: Любому системному администратору постоянно приходится иметь дело с данными, представленными в форме временных рядов (time series): статистика скачивания файлов, статистика запросов к серверам, данные об использовании системных и аппаратных ресурсов виртуальными машинами…Чтобы все это хранить и обрабатывать, нужен адекватный и производительный инструмент. 
• #16: Например в инфлюксе HTTP API Carbon UDP telegraf Несомненным плюсом InfluxDB являются и широкие возможности интеграции с другими программными продуктами — например, инструментом для обработки логов Fluentd, демонами для сбора статистики CollectD и и StatsD, фреймворками для мониторинга Sensu и Shinken.
• #17: Graphite web app Chronograph Prometheus Grafana Немного рассказать о графане Роль визуализации - Добавляет
• #18: Jmeter/ Server  Graphite  InfluxDB --> Grafana
• #19: Коротко о докер
• #25: Мониторинг железа (проц, память, диск, сеть) Сбор бизнес метрик (регистрации, логины, кол-во заказов) Отслеживание событий (деплоймент, изменение конфигурации) Сбор тестовых метрик (время отклика, процент ошибок) 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:
• #26: Мониторинг железа (проц, память, диск, сеть) Сбор бизнес метрик (регистрации, логины, кол-во заказов) Отслеживание событий (деплоймент, изменение конфигурации) Сбор тестовых метрик (время отклика, процент ошибок) 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:
• #27: Рассказать об опыте с опсами
• #28: Демоны, повершелл, jmeter plugin
• #29: Мониторинг железа (проц, память, диск, сеть) Сбор бизнес метрик (регистрации, логины, кол-во заказов) Отслеживание событий (деплоймент, изменение конфигурации) Сбор тестовых метрик (время отклика, процент ошибок) 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:
• #34: Готовы приступить к Графана Сначала я хотел создать стандартный дешборд и поделиться им
• #38: Уровни сервиса (желтая и красная линия) Несколько графика на 1 форме
• #39: Провалиться глубже если что то подозрительное увидел
• #40: Провалиться глубже если что то подозрительное увидел
• #41: Мониторинг железа (проц, память, диск, сеть) Сбор бизнес метрик (регистрации, логины, кол-во заказов) Отслеживание событий (деплоймент, изменение конфигурации) Сбор тестовых метрик (время отклика, процент ошибок) 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:
• #42: Мониторинг железа (проц, память, диск, сеть) Сбор бизнес метрик (регистрации, логины, кол-во заказов) Отслеживание событий (деплоймент, изменение конфигурации) Сбор тестовых метрик (время отклика, процент ошибок) 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:
• #44: Мониторинг железа (проц, память, диск, сеть) Сбор бизнес метрик (регистрации, логины, кол-во заказов) Отслеживание событий (деплоймент, изменение конфигурации) Сбор тестовых метрик (время отклика, процент ошибок) 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:
• #46: Мониторинг железа (проц, память, диск, сеть) Сбор бизнес метрик (регистрации, логины, кол-во заказов) Отслеживание событий (деплоймент, изменение конфигурации) Сбор тестовых метрик (время отклика, процент ошибок) 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:
• #49: Мониторинг железа (проц, память, диск, сеть) Сбор бизнес метрик (регистрации, логины, кол-во заказов) Отслеживание событий (деплоймент, изменение конфигурации) Сбор тестовых метрик (время отклика, процент ошибок) 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: Этого пока нету, но есть варианты Прометеус Яндекс танк
• #52: компонуем разные инструменты (жметр + графит, графана) привязать это к дженкинсу, зашарить снепшот с графаны, запустить таурус или танк, репортинг от тауруса