Последние недели на работе я занимался разработкой системы мониторинга наших сайтов со стороны реальных пользователей. Необходимость такого мониторинга назревала давно и вот, наконец-то, мы его сделали. Если одной фразой о результатах, то она в заголовке, реальная картина, мягко говоря, отличается от того, что мы видим, когда тестируем сайт. Сейчас у нас собирается информация от конечных пользователей сайта по скорости загрузки страниц, ошибках в js скриптах, скорости работы критических сервисов, поиска туров, и ошибках в них. Ниже несколько слов о том, как мы это сделали.
Мониторинг в принципе необходим для любого серьезного интернет проекта. Однако мониторинг со стороны сервера и со стороны реальных клиентов - совершенно разные вещи как по смыслу, так и по технологиям. В нашем случае у нас имеется более 50 млн. актуальных цен на сайте, тысячи туров, миллионы возможностей задавать параметры поиска, которыми пользуются десятки тысяч посетителей в день. Протестировать скорость работы поиска по всем вариантам просто невозможно, поэтому единственный способ - получать информацию о скорости поиска и ошибках от реальных посетителей по их запросам. Конечно, без мониторинга с серверной стороны картина будет не полной, но он у нас был уже давно и для этого применяются вполне стандартные решения.
Итак, каким образом можно реализовать мониторинг со стороны клиентов. Концептуально - после загрузки страницы пользователем исполняется специальный javascript и отправляет необходимые данные обратно к нам на сервер, где мы их собираем и каким-то образом используем. Самый очевидный способ - собирать данные в sql базу данных типа mysql и дальше разбирать их различными sql запросами.
Мы не стали идти этим путем. Во-первых, нам нужен мониторинг, а не аналитика. Нам не нужны все данные ото всех пользователей месячной давности. Во-вторых, база данных требует обслуживания, а это человеческий ресурс и соответственно деньги. В третьих, Sql бд работает медленно. Поэтому первым вариантом было использование rrdtool с его кольцевыми базами данных (в общем-то стандарт де факто для всех систем мониторинга под linux), не требующими обслуживания. Однако этот вариант отпал, поскольку rrdtool требует строго периодичного обновления базы, для живого веб-сайта - это не реально. Проработав еще несколько вариантов выбор пал на in-memory database и в частности redis. Было решено хранить необходимую нам информацию в кольцевом буфере. Т.е. в буфер с одной стороны по кругу пишется информация о последних N (сейчас у нас это 1000) посетителях, а с другой есть скрипты, которые вытаскивают из этого массива различные показатели, такие как скорость загрузки, количество ошибок, среднее время поиска за минуту или 5 минут и т.п. Кроме того архитектура позволяет создавать любое количество кольцевых буферов для хранения разной информации, например у нас отдельно собирается информация по скорости работы сайта, скорости работы поиска и ошибках в JS коде. Сбор и обработка информации реализованы достаточно простыми php скриптами и лежат на отдельном домене (stat.lantatur.ru).
Как мы собираем информацию на клиентах. Для оценки скорости работы наших приложений мы внедрили в них функции отправки мониторинговой информации. Каждый раз, когда человек делает поиск на нашем сайте, мы ajax запросом отправляем обратно время исполнения запроса, количество результата и другие данные.
Время загрузки сайта собирается с помощью открытой библиотечки boomerang. Это client-only библиотека, поэтому она очень лекго безо всяких модификаций подключилась к нашему бэкэнду.
Ошибки в javascript отправляются нам обратно специальным обработчиком, который подвешивается к window.onerror на всех страницах сайта.
В настоящий момент вся информация выводится на самописной панели мониторинга (см скриншот). Но мы планируем добавить протоколирование c помощью Munin, который будет рисовать графики показателей за день неделю и месяц, а также написать проверки для Nagios, чтобы знать о проблемах, даже если они возникнут, когда никто не смотрит на панель.
Как видно, концепутально все достаточно просто, но в результате мы получили возможность посмотреть на наш сайт глазами пользователей. Такую возможность сложно переоценить.
 |
| Панель realtime мониторинга |
Мониторинг в принципе необходим для любого серьезного интернет проекта. Однако мониторинг со стороны сервера и со стороны реальных клиентов - совершенно разные вещи как по смыслу, так и по технологиям. В нашем случае у нас имеется более 50 млн. актуальных цен на сайте, тысячи туров, миллионы возможностей задавать параметры поиска, которыми пользуются десятки тысяч посетителей в день. Протестировать скорость работы поиска по всем вариантам просто невозможно, поэтому единственный способ - получать информацию о скорости поиска и ошибках от реальных посетителей по их запросам. Конечно, без мониторинга с серверной стороны картина будет не полной, но он у нас был уже давно и для этого применяются вполне стандартные решения.
Итак, каким образом можно реализовать мониторинг со стороны клиентов. Концептуально - после загрузки страницы пользователем исполняется специальный javascript и отправляет необходимые данные обратно к нам на сервер, где мы их собираем и каким-то образом используем. Самый очевидный способ - собирать данные в sql базу данных типа mysql и дальше разбирать их различными sql запросами.
Мы не стали идти этим путем. Во-первых, нам нужен мониторинг, а не аналитика. Нам не нужны все данные ото всех пользователей месячной давности. Во-вторых, база данных требует обслуживания, а это человеческий ресурс и соответственно деньги. В третьих, Sql бд работает медленно. Поэтому первым вариантом было использование rrdtool с его кольцевыми базами данных (в общем-то стандарт де факто для всех систем мониторинга под linux), не требующими обслуживания. Однако этот вариант отпал, поскольку rrdtool требует строго периодичного обновления базы, для живого веб-сайта - это не реально. Проработав еще несколько вариантов выбор пал на in-memory database и в частности redis. Было решено хранить необходимую нам информацию в кольцевом буфере. Т.е. в буфер с одной стороны по кругу пишется информация о последних N (сейчас у нас это 1000) посетителях, а с другой есть скрипты, которые вытаскивают из этого массива различные показатели, такие как скорость загрузки, количество ошибок, среднее время поиска за минуту или 5 минут и т.п. Кроме того архитектура позволяет создавать любое количество кольцевых буферов для хранения разной информации, например у нас отдельно собирается информация по скорости работы сайта, скорости работы поиска и ошибках в JS коде. Сбор и обработка информации реализованы достаточно простыми php скриптами и лежат на отдельном домене (stat.lantatur.ru).
Как мы собираем информацию на клиентах. Для оценки скорости работы наших приложений мы внедрили в них функции отправки мониторинговой информации. Каждый раз, когда человек делает поиск на нашем сайте, мы ajax запросом отправляем обратно время исполнения запроса, количество результата и другие данные.
Время загрузки сайта собирается с помощью открытой библиотечки boomerang. Это client-only библиотека, поэтому она очень лекго безо всяких модификаций подключилась к нашему бэкэнду.
Ошибки в javascript отправляются нам обратно специальным обработчиком, который подвешивается к window.onerror на всех страницах сайта.
В настоящий момент вся информация выводится на самописной панели мониторинга (см скриншот). Но мы планируем добавить протоколирование c помощью Munin, который будет рисовать графики показателей за день неделю и месяц, а также написать проверки для Nagios, чтобы знать о проблемах, даже если они возникнут, когда никто не смотрит на панель.
Как видно, концепутально все достаточно просто, но в результате мы получили возможность посмотреть на наш сайт глазами пользователей. Такую возможность сложно переоценить.
0 Комментарии:
Отправить комментарий