Как работать с Sentry: гайд от разработчика

Я Дастан Абдирайым, разработчик в QIC digital hub. В этой статье я расскажу о Sentry — инструменте, который помогает в управлении инцидентами и мониторинге производительности приложений.

Эта статья – своего рода руководство по использованию сервиса, которое будет полезно не только для разработчиков, но также и для менеджеров, QA-инженеров и аналитиков.

Многим знакомо, что такое Sentry, но не все знают о его дополнительных возможностях. Итак, начнем с базы: Sentry — инструмент для построения процессов инцидент-менеджмента. Инцидент — это не только ситуация, когда ломается основной поток, теряются оплаты или возникают другие критические ошибки. Инцидентом может быть любое событие, которое влияет на качество продукта, или, как мы привыкли это называть, на Quality Assurance. Например, баги, плохая оптимизация или несоответствие с макетами.

Переходим к функционалу сервиса. Sentry поможет:

Перед тем как мы начнем, я бы хотел показать, как анализировать ошибки и на какие вещи обращать внимание. Первым делом мы смотрим на следующие параметры:

Релиз: Нам важно удостовериться, что перед нами последняя версия приложения, так как некоторые баги могут быть уже решены, но пользователь еще не перешел на актуальную версию.

Environment: Нас интересует только production. Мы не рассматриваем другие тестовые окружения, чтобы фильтровать обзор.

Страница ошибки: В вебе доступна страница, на которой произошла ошибка. Также важно учитывать используемый браузер (например, Chrome Mobile или Safari), так как они могут иметь свои особенности.

Stack trace: Это участок кода, который вызвал ошибку. К примеру, мы можем увидеть, в каком компоненте и на какой строке находится проблема.

Breadcrumbs: Это «хлебные крошки», показывающие полный путь пользователя, начиная с загрузки страницы и заканчивая взаимодействием с интерфейсом.

Чтобы было проще ориентироваться по ошибкам, есть такая возможность, как Sourcemaps. Возможно, вы слышали, что нужно отключить их генерацию, так как они увеличивают длительность сборки. Однако я нашел применение этой функции и целенаправленно включил ее.

Sourcemaps — файлы, связывающие исходный код с конечной сборкой. Например, если мы пишем на фреймворках Vue или Next, в конечном итоге это все компилируется в JavaScript-код. Это помогает понимать связь между исходниками и конечной сборкой, что упрощает поиск ошибок.

Давайте разберем пример: посмотрим на ошибку TypeError. Мы видим файл, в котором это произошло, но не понимаем, какое у файла название.

Если вы не разработчик и не понимаете, о чем идет речь — не переживайте, многие разработчики могут сталкиваться с подобными трудностями. Именно для этого и были созданы Sourcemaps. Теперь наши ошибки выглядят следующим образом: на дашборде видно, что ошибка TypeError происходит в компоненте DatePicker, который написан на Vue, а не на JavaScript. Мы также видим, что ошибка возникает на 122-й строке кода, при инициализации переменной nextStart. Это позволяет быстрее определять и воспроизводить ошибки, что, в свою очередь, сокращает время выхода фиксов на рынок.

Несмотря на то, что мы используем Nuxt и Vite, и для них есть разные плагины, смысл остается тем же. Во-первых, нужно установить соответствующий Sentry Plugin. Затем отправить следующие параметры: авторизационный токен, название организации, название проекта и путь до наших Sourcemaps.

Теперь перейдем к производительности, а именно к метрикам Web Vitals. Они измеряют загрузку и интерактивность приложений. Прежде, чем перейти к практической части, я покажу ценность данных метрик и их влияние на бизнес.

Так выглядит вкладка Web Vitals в Sentry.

В частности, общее значение Web Vitals для проекта составляет 81%, что выше среднего уровня. Однако мы можем улучшить этот показатель. Ниже представлены усредненные значения метрик: LCP составляет 2,7 секунды — это 70%, FCP - 2.35 секунды. CLS показывает отличный результат на уровне 99%, что радует.

Кроме того, мы можем измерять метрики для каждой страницы отдельно. Например, на начальную страницу потока (выбор дат или стран) зашло более 5 тысяч пользователей, но до чекаут дошли только около 350 человек. Это может указывать на влияние производительности, так как показатели между страницами составляют 50% или 70%, что на уровне средних значений. Мы можем улучшить эти показатели и увидеть их влияние на переход в квоту.

Если необходимо углубиться в загрузку приложений, мы можем выбрать соответствующую страницу и проверить, из чего состоит загрузка. Здесь мы можем наблюдать DNS-резолвинг, операции браузера и видеть, какие именно ресурсы загружаются, и сколько времени занимает этот процесс. На основе этой информации мы можем принимать обоснованные решения по оптимизации.

На картинке ниже я указал, как мы можем подключить Web Vitals Sentry. Важно всегда проверять параметр TracesSampleRate, который указывает, сколько пользователей будет отправлять свои данные в Sentry. Например, значение 0.5 означает, что 50% пользователей будут отправлять данные.

Кроме Web Vitals в Sentry доступны Mobile Vitals. Вкладка Performance отображает транзакции «Мобильные», включая холодный и горячий запуск приложений, а также информацию о медленных и зависающих фреймах.

Sentry умеет собирать обратную связь от пользователей. Когда происходит ошибка, мы можем спросить у пользователя, как он ее воспроизвел, и отобразить модальное окно. Это стандартный экран Sentry, где пользователь может ввести свое имя, электронную почту и описание ситуации. Кроме того, он может добавить скриншоты. Sentry также отправляет информацию о странице, с которой был отправлен этот фидбэк.

Если мы хотим использовать собственный интерфейс, такая возможность доступна для всех устройств. Мы можем самостоятельно определять, когда открывать данное модальное окно (то есть не только во время ошибок). Возможно, мы внедрили новую функцию и хотим узнать, как она воспринята пользователями на странице успешной квоты.

Профилирование — это инструмент, который позволяет выявлять уязвимые участки кода, такие как утечки памяти или проблемы с оптимизацией. Это позволяет настраивать приложение.

К сожалению, в вебе эта функция находится на стадии бета-тестирования, так как основана на браузерном API, доступном только в последних версиях Chrome.

В мобильных устройствах профилирование доступно в полном объеме. Разработчики часто тестируют код на последних моделях устройств, таких как iPhone 15 Pro Max.

Особенность заключается в том, что полная картина оптимизации приложения может быть не видна, поскольку многие пользователи используют старые устройства. Sentry позволяет учитывать оптимизацию для всех устройств и анализировать множество параметров во время профилирования. Если мы активируем эту функцию, скорость приложения может немного снизиться, как утверждает Sentry, примерно на 1%. Однако это стоит проверить.

Sentry позволяет отслеживать путь пользователя, например, когда он сталкивается с ошибкой. Это помогает ускорить выявление проблем, которые сложно предугадать.

Если включен режим Session Replay, на странице ошибки добавляется блок с видео, показывающим, как пользователь воспроизвел ошибку. Эта функция позволяет забыть о breadcrumbs. Однако, если эта функция отключена, стоит проверять breadcrumbs для дополнительного анализа.

Само видео представляет собой скорее коллекцию снапшотов состояний браузеров пользователя. Снапшоты объединяются и отправляются в Sentry с помощью open-source библиотеки для веб. Оставляю вам ссылку на библиотеку для кастомных решений, например, если мы не хотим зависеть от Sentry и используем другие инструменты.

Настраивать запись сессии можно вручную или с помощью Sample Rate. Если пользователь не взаимодействует со страницей, запись отключается. Запись также останавливается, если достигнут максимальный лимит времени — 60 минут. Мы можем вручную вызывать replay.stop. Кроме того, если потребуется, можно вручную вызывать replay.start, чтобы видеть, как пользователь заполняет информацию на разных экранах.

Все вышеописанные инструменты полезны только, если проверять их хотя бы один раз в день. Но я не хочу проверять их раз в день. Уверен – вы тоже.

С помощью Sentry мы можем настроить алерты на ошибки, чтобы отслеживать, новая это ошибка или нет, увеличилась ли ее частота, была ли она решена ранее. Алерты работают автоматически. Например, в Slack мы получаем уведомление об ошибке с возможностью перейти по ссылке, оценить приоритетность и добавить ее в Jira, чтобы не потерять.

Существуют и другие виды алертов. Например, общее количество ошибок в проекте, среднее время транзакций, запросов на сервер и процент сессий без ошибок (crash-free rate). В последнем релизе этот показатель составил 97%, что является хорошим результатом, но мы можем стремиться к 99%, решив проблемы из бэклога.

Кроме того, можно настроить кастомные метрики. Например, мы сделали алерт на LCP (Largest Contentful Paint), если он превышает какое-то время.

У Sentry есть ряд уникальных функций, которые делают его особенно ценным для разработчиков, менеджеров, QA-инженеров и аналитиков.

Ключевые особенности Sentry включают:

Sentry позволяет эффективно мониторить ошибки и производительность приложения, собирать обратную связь, записывать сессии пользователей и улучшать код с помощью профилирования.

Какие инструменты для мониторинга инцидентов вы используете в работе?