В прошлом нашем посте внимательный читатель dovg отметил скриншот с красивым графиком. На нем было отражено время выполнения различных операций поиска. А поскольку статистика и анализ производительности высоконагруженных проектов – тема довольно актуальная, мы решили рассказать про систему, которую используем для сбора и анализа статистики «Мамбы». Как и в случае поиска, мы используем собственное решение, но в отличие от него BTP (никто не помнит, как эта аббревиатура появилась на свет, но почему-то именно она стала названием) находится в открытом доступе, и при желании вы можете установить её на своих серверах.
Система выдает следующие виды статистики:
- по операциям на сервисе (например, «mysql» или «memcache»)
- по операциям на сервере конкретного сервиса (например, сервис mysql и сервер db7)
- по скриптам, которые используют какую-то операцию сервиса (например, «update» сервиса «mysql»)
- по сервисам/операциям, которые использует конкретный скрипт
Чтобы получить наиболее полную картину работы приложений, мы использовали представление информации в двух иерархиях. Первая вполне традиционна: сервис-сервер-операция. Она позволяет определить нагрузку на сервисы, равномерность распределения нагрузки по серверам и частоту использования конкретных операций.
Здесь отражается, например, количество запросов к кластеризованным БД. Контроль времени отклика каждой из них позволяет понять эффективность работы в целом, а в случае проблем, выяснить какая конкретно база тормозит больше всех. В этой же иерархии мы смотрим, возросли только селекты или также и апдейты; нормальна или повышена нагрузка на кэш и т.п. Иными словами, в случае проблем здесь мы определяем точку отказа — какой сервис/сервер снижает общую производительность. При этом, обрабатывая информацию, веб-интерфейс берёт также данные и из второй иерархии, отображая, какие скрипты больше всего используют интересующую нас операцию какого-либо определенного сервиса.
Вторую иерархию — скрипт-сервис-операция — можно использовать, чтобы выяснить конкретную “причину засора”, а именно: к чему тормозящий скрипт обращается и на что тратит время. В этой иерархии можно определить, какие конкретно сервисы скрипт использует, сколько запросов делает и каково время ответа на эти запросы. Именно так можно, например, определить, почему изменение кода скрипта привело к росту нагрузки на определённую БД.
Наиболее распространенный показатель производительности веб-приложений — время отклика. Многие системы ограничивают аналитику средним и пограничными временем отклика, но на практике эти данные могут оказаться “сферическим конем в вакууме”. Предположим, что 10% посетителей получают нужную страницу в 10-20 раз медленнее остальных 90%. Это не скажется сильно на среднем показателе, однако при миллионной аудитории выльется в сотни тысяч недовольных пользователей. Поэтому мы используем отчеты по перцентилям и можем посмотреть не только средние показатели, но и значения, в которые укладываются 50, 80, 95 и 99 процентов операций. Это позволяет нам получить намного более релевантный результат с точки зрения “удовлетворенности пользователей”.
Разрабатывая систему, мы сразу предполагали, что количество и состав измеряемых параметров могут меняться. Кроме того, долговременная аналитика невозможна без анализа сохраненных за какой-то промежуток времени данных, поэтому хранению имеющейся статистики мы тоже уделили отдельное внимание.
В результате с технической точки зрения система состоит из следующих частей:
- Демон
Принимает и обрабатывает данные счётчиков; считает, хранит и выдаёт статистику. Работает по протоколу JSON-RPC, а для хранения использует библиотеку kyoto cabinet (встраиваемое key-value хранилище). - Веб-интерфейс
Собственно интерфейс просмотра статистики. Рисует графики (подробнее о графиках ниже). - Клиент
Это та часть, которая интегрируется в ваше приложение. Отправляет счётчики в демон. При этом можно использовать уже готовый клиент на PHP или Python, а также, при желании, написать свой собственный.
Когда вы заходите в веб-интерфейс, то сразу видите статистику по счётчикам из вашего скрипта. Статистика за последние ~2 часа обсчитывается с разрешением в 5 секунд. Сутки — с разрешением в 1 минуту (ну и есть, естественно, статистика за месяц и год с разрешением в 30 минут и в 6 часов соответственно).
Для рисования графиков веб-интерфейс использует клиентские шаблоны, Backbone.js и dygraphs и почти весь написан на javascript, за исключением маленького http-to-json-rpc-прокси файлика js.php, и index.php (который собирает на страницу клиентские шаблоны из отдельной директории).
Собственно на графиках стоит остановиться отдельно. Для их генерации и вывода мы пробовали использовать несколько разных библиотек, в том числе highcharts, raphael.js и envision.js, но остановились на dygraphs. Рассуждали мы примерно следующим образом:
Raphael: svg-based библиотека, в которой практически всё приходится делать руками. В том числе чертить координатную сетку в виде отрезков SVG. И при этом она не отличается высокой скоростью.
Highcharts: сильно проще, чем Raphael, тоже svg-based, но при кастомизации появляются свои сложности. И тоже не очень быстрая (3-4 графика по 1.5 тысячи точек ощутимо тормозят).
Envision.js: canvas-based, чуть шустрее (если не использовать всякие интересные штуки типа мини-навигации). В целом неплохой вариант.
Dygraphs: самый шустрый. Имеющийся функционал реализуется относительно просто, однако некоторых возможностей не хватает (например, не получилось сделать вывод на одном экране двух графиков в разных представлениях: в виде закрашенной области и простой линией). Тем не менее, скорость работы в разы превысила таковую у остальных библиотек. В результате выбор был остановлен именно на Dygraphs.
Естественно, существуют и другие системы сбора статистики, например, New Relic и Pinba. Но BTP имеет несколько выгодных отличий.
От New Relic она отличается тем, что, во-первых, является открытым продуктом, а во-вторых, ориентирована именно на мониторинг параметров приложения (то, что в new relic называется custom metrics). Ну и в третьих, не нужна установка php extension и java proxy agent. Хотя стоит признать, что интерфейс у New Relic более “вылизан”.
От Pinba наша система отличается, во-первых, более простой установкой (не нужен плагин к MySQL, не нужен extension), а во-вторых, тем, что пинба занимается только подсчётом статистики. Pinba не хранит и не отображает данные, а чтобы это делать, к Пинбе приходится прикручивать крон-скрипты, rrdtool с кучей параметров командной строки и средства для рисования графиков. И естественно, при добавлении новых счётчиков нужно не забыть сохранять данные и с них тоже.
Ссылки:
BTP/ Демон
https://github.com/mambaru/btp-daemon
Картинки
BTP/Веб-интерфейс
https://github.com/mambaru/btp-webui
BTP/Наш клиент
https://github.com/mambaru/btp-api
BTP/Python-клиент
https://github.com/mastergenius/pybtp
New Relic
https://newrelic.com/docs/php/the-php-api
Pinba
http://pinba.org/wiki/Main_Page
Автор: Julia_Gryzunova
