Client’s Errors и моментальное реагирование на ошибки в Kolesa Group
Мы живём в неидеальном мире, где на вашем гаджете web-приложение может работать, а вот на тысячах других устройств оно падает. Либо при рефакторинге какого-то большого функционала в рекомендациях к тестированию мы попросту не предусматриваем какие-то кейсы и отправляем на production, лишая этим web-приложение части функционала. По этой причине все продукты Kolesa Group запускаются с системой мониторинга ошибок.
Я Азим Азимов — frontend-разработчик Kolesa Group, а именно продукта Market.kz. Я расскажу вам, как мы в компании реализуем моментальное реагирование на ошибки.
В этом нам помогает система алертов Sentry, которая обеспечивает отслеживание и мониторинг ошибок практически для каждого языка и фреймворка. Аналоги Sentry: Raygun Error Monitoring, Bugsnag, Rollbar, Airbrake, Trackjs, LogRocket, Errorception, CatchJS, Firebase Crashlytics.
Ваши пользователи — лучшие тестировщики, они тщательно проверяют весь функционал, который вы им доставляете. Так давайте же не упускать возможность применить их труд: обнаруживать и чинить всё, то что они смогли найти.
В этой статье вы узнаете про:
- Важность моментального реагирования на ошибки
- Организация нашего процесса работы с клиентскими ошибками
- Расследование причин возникновения ошибки
- Безопасность клиентских данных
- Игнорирование
Важность моментального реагирования на ошибки
Любой проект, который предполагает взаимодействие с пользователями, обязан иметь систему мониторинга ошибок, возникающих на стороне клиента. Тем более, когда речь об участках кода, которые приносят бизнесу пользу и прибыль.
Если нужно будет срочно разобраться, почему не работает та или иная фича в вашем продукте, вы должны уметь заходить в логи и анализировать последние ошибки. После обнаружения той самой ошибки, вы сможете оценить все нюансы этой проблемы и приступить к ее решению.
А что касается Kolesa Group, с появлением в компании команды frontend-разработчиков, возникла необходимость в инструменте для сбора информации о клиентских ошибках с целью дальнейшего анализа и устранения проблем. Я считаю, что к такой необходимости приходит любой продукт после пары крупных багов, которые могли бы быть найдены на самых первых этапах своего возникновения.
Организация процесса работы с клиентскими ошибками
В каждой команде продукта Kolesa Group периодически назначается дежурный разработчик. В его обязанности входит мониторинг и устранение ошибок. Уведомления об ошибках доставляются на почту и дублируются в корпоративный Telegram-канал, так что пропустить их не удастся. Также можно настроить уведомления о возникновении большого количества определённых ошибок в случае, если мы отложили их решение.
Команда QA тоже участвует в процессе отслеживания новых ошибок. Ошибки можно фильтровать по номеру релиза. Каждый раз после deploy в production QA-инженер отслеживает логирование ошибок. И в случае их выявления расследует с дежурным разработчиком причины их возникновения.
Расследование причин возникновения ошибки
Основная функциональность Sentry — предоставление как можно большего количества данных о состоянии приложения на момент возникновения ошибки. Первое, на что здесь обращаем внимание — «хлебные крошки». Это действия пользователя до возникновения ошибки. В этот список логируются сетевые запросы REST, клики по DOM элемента и навигация по страницам.
Если мы заранее знаем, что какой-то участок кода важен, можем разложить набор своих «хлебных крошек». И затем, при создании события, вместо клика по абстрактному селектору будет отображаться клик по конкретной кнопке.
Sentry.addBreadcrumb({ category: "auth", message: "Click pay button", level: "info",});
Если информации недостаточно или мы хотим убедиться в достоверности теории, обращаем внимание на теги события. Тут можно найти абсолютно всё, что потребуется для выявления причин: от версии операционной системы до названия компонента, в которой была инициирована ошибка.
Бывает, что нежелательное поведение пользователей не провоцирует ошибки в консоле и вышеперечисленных инструментов анализа не хватает для выявления причин ошибки. В таком случае мы можем быть инициаторами события и выслать все данные о состоянии события.
Пример генерирования события. Однажды мы смогли найти причины досрочной потери авторизационных данных пользователя. Воспроизвести это было невозможно, но пользователи жаловались на внезапные запросы авторизации. Залогировав процесс авторизации, мы набрали достаточно данных для того, чтобы понять первоисточник причины. Благодаря этой функциональности можно делать debug сложных сценариев поиска багов.
Sentry.captureEvent({ level: Severity.Error, extra: { error }, fingerprint,});
Безопасность клиентских данных
Конечно, на стороне клиента есть персональные данные которые не стоит отправлять в системы логирования. Это логин, номер, пароль, авторизационные токены, сумма баланса, местоположения, адрес и мн. др. На этот случай у нас предусмотрено фильтрация пользовательских данных:
Sentry.init({ beforeSend(event) { // Обнаруживаем что в событие есть пользовательские данные if (event.user) { // Удаляем или можем заменить delete event.user.email; } return event; },});
Таким образом, это даёт все необходимые инструменты для предотвращения несанкционированного раскрытия персональных данных клиента. Ошибки можно решать гораздо быстрее, чем об этом узнают пользователи. Плюс мы в Kolesa Group развернули всю систему Sentry у себя на серверах, чтобы никто кроме сотрудников не имел доступа к данным об ошибках.
Игнорирование
Современное клиентское приложение сопровождается аналитическими инструментами, партнёрской рекламой и набором сторонних библиотек. Зачастую, у всех этих инструментов есть внутренние ошибки, которые не относятся к нашему приложению, но всё же исполняются внутри нашего сайта (web-приложения). В таком случае все назойливые ошибки сторонних инструментов, которые мы не в силах починить, отправляем в игнор-лист. Но предварительно консультируемся с отделом маркетинга на случай, если эта ошибка критична для них. Игнор-лист можно создать при инициализации и в самой админ-панели Sentry.
Sentry.init({ // Добавляем то, что не должно отправлять на сервер вообще ignoreErrors: [ "fb_xd_fragment", /^Exact Match Message$/ ];})
У Kolesa Group 4 основных продукта с ежемесячной аудиторией в 12,5 млн пользователей в Казахстане и Узбекистане: Kolesa.kz, Krisha.kz, Market.kz и Avtoelon.uz. Все эти продукты развёртываются на собственных серверах независимо друг от друга. Но если говорить о системе логирования и сбора ошибок, то она развёрнута централизованно для всех продуктов: так дешевле и легче мониторить состояние всех продуктов из одной админ-панели.
Но у этого подхода есть один нюанс — один из продуктов может стать инициатором большого количества ошибок в систему логирования.
Пример. Market.kz релизит новую фичу на главной экране приложения. Но тут у каждого второго пользователя появляется ошибка, что провоцирует множество логирований в Sentry. Сервера продукта стойкие. Но если сервер не выдержит, это приведёт к тому что, все остальные продукты не получат информацию о новых ошибках в своих приложениях.
Эта проблема также решается правильной конфигурацией Sentry. Достаточно установить лимит обращений в час для каждого проекта.
1. Высчитываем максимальное значение обращений нашего проекта (web-приложения) в час
Так как каждый проект имеет разную нагрузку и разное количество ошибок, то это число обращений в час должно быть индивидуально для каждого. Для этого проекту надо поработать какое-то время без ограничений. Затем в статистике мы выбираем максимальные значения за часы и из них берём среднее.
2. Устанавливаем порог обращений для web-приложения
На основе этого максимального значения мы выставляем лимит обращений в час.
3. Устанавливаем оповещения
С достижением лимита в событиях мы настраиваем уведомления для быстрого реагирования на внезапные всплески ошибок на клиентской стороне.
При достижении лимитов проект лишается данных, при этом остальные продукты Kolesa Group продолжают получать свою статистику. А того избытка событий порой достаточно для диагностирования проблемы.
Итоги
Система мониторинга нужна для компаний, которые хотят отслеживать состояние приложений. Наличие этого или подобного инструмента напрямую влияет на скорость обнаружения ошибок. Это здорово помогает разработчику быстро анализировать и чинить сложные и важные сценарии багов.
Давайте посчитаем сколько это стоит для Kolesa Group.
Событий в день — 123 000.
Событий в неделю — 863 000.
Событий в месяц — 3 690 000.
По примерным расчетам стоимость облачного решения стоило бы $15 000 в год. А Kolesa Group развернула систему бесплатно на собственных серверах. Про самостоятельное развертывание Sentry можно почитать здесь.
