Система отчётов: как получать 50 млн. отчетов и сохранить Дзен
Чем сложнее программный продукт, чем больше он взаимодействует со сторонними системами (часто не менее сложными), тем выше вероятность сбоев в работе. Тестирование помогает найти большинство багов перед выкатыванием релиза, но иногда что-то может проскользнуть. И чтобы быстро получать подробную информацию о факте сбоя и сопутствующих условиях, в наших продуктах широко используется система отчётов. О её устройстве мы хотим сегодня рассказать.
Обычно приложения падают из-за багов или непредсказуемых действий пользователей. Чтобы понять причину падения, нужно собрать разную информацию: в каком окружении работает приложение, что сделал пользователь. В общем, данные, которые могут помочь нам решить проблему. Для этого используется система отправки отчётов о работе приложения и о фактах сбоев.
Кроме расследования причин сбоев, мы используем отчёты и для анализа поведения пользователей. Для этого мы примерно раз в три месяца инициируем анонимный сбор статистики использования наших приложений. Мы смотрим, какие функции используются чаще всего и в каких ситуациях, возникают ли у пользователей затруднения. Это помогает нам корректировать планы по развитию продуктов. Возьмём, например, Parallels Desktop. Нам интересно, сколько пользователей запускают одну виртуальную машину, две, четыре и так далее. Если у большинства одна ВМ, то очевидно, что не имеет смысла сильно оптимизировать интерфейс для использования нескольких виртуалок, и так далее.
Подробности реализации
Отчёты отправляются как автоматически, так и по инициативе пользователей. В них включаются логи приложения, крэш-дампы, дампы памяти, информация о конфигурации машины, иногда ещё какая-нибудь служебная информация. Всё это упаковывается в файл tar.gz, размер которого колеблется от единиц до сотен мегабайт, и отправляется на наш сервер. Здесь файл подвергается первичной обработке, в него добавляется служебная информация — IP-адрес отправителя и временная метка, —, а затем файл заливается в MongoDB.
Дальше есть два варианта развития событий:
• Разработчики могут вручную проанализировать XML-файлы, логи и конфигурацию, чтобы понять, в каком окружении работает приложение и что делал пользователь
• Отчёт может быть автоматически классифицирован и включён в общую статистику
Классификация делается так: написанные на Python парсеры получают от RabbitMQ ID отчётов, залитых в MongoDB, извлекают из них state-trace, и по неким правилам присваивают текстовую метку — сигнатуру. Парсеры извлекают из XML файлов необходимые данные и складывают их в виде отдельных документов с проиндексированными полями.
Также у нас есть специальные парсеры, каждый из которых обрабатывает конкретные виды крэш-отчётов. Они проходятся по каждому отчёту и смотрят, есть ли там интересующие их файлы. Например, один парсер ищет только Mac-отчёты, другой — только Windows, и так далее. Затем они точно так же строят сигнатуру.
Компоненты системы отчётов развёртываются с помощью Chef. Отдельная команда devops«ов специально пишет «рецепты» (cookbook), благодаря которым каждый разработчик имеет окружение, очень близкое к рабочему (production). Так мы минимизируем вероятность конфликтов, когда у разработчика что-то работает, а в production — нет.
Общая статистика по отчётам в реальном времени отображается на специальной веб-странице, где можно сортировать данные по сигнатурам и отдельным полям. Например, по версии Mac OS, гостевой ОС и версии продукта. Это помогает быстро понять, какую проблему нужно решать в первую очередь, если количество каких-то сигнатур вдруг начинает резко расти, например, после очередного обновления.
Серверный парк
В среднем мы обрабатываем около 400 000 отчётов в месяц, 100 гигабайт. За 10 лет у нас накопилось более 50 млн разнообразных отчетов. Серверы, принимающие отчёты, расположены в США, потому что там находится большинство наших пользователей. Но обработка и анализ выполняются в России. Раньше иногда случалось, что отчёты поступали быстрее, чем мы успевали обработать и передать через океан. Сейчас мы уже протестировали и начали внедрять систему, использующую очереди и микросервисы для парсинга. Количество микросервисов можно менять в зависимости от текущей нагрузки, так что единственным ограничением может стать только пропускная способность канала.
Сколько серверов обслуживают нашу систему отчётов: 
При необходимости любую из подсистем можно масштабировать, подстраиваясь под растущую нагрузку.
Отчёты — это не только источник подробной информации о сбоях, но и система «раннего предупреждения». Зачастую пользователи обращаются в поддержку не сразу, а лишь столкнувшись с какой-то проблемой несколько раз. Но благодаря автоматическим отчётам быстро увидим рост количества сбоев и сразу начнём решать проблему. Часто мы фиксим баг ещё до того, как в поддержку пойдёт волна обращений.
Комментарии (1)
8 декабря 2016 в 06:19
0↑
↓
Знакомьтесь, это друг упоротого лиса — укуренный пёс.
