Наблюдаемость фронтенда: что это и зачем она нужна

Наблюдаемость серверной части хорошо развита: журналы фиксируют события, метрики отслеживают использование ресурсов, а распределённые трассировки сопровождают запросы через микросервисы. Такие инструменты, как Datadog, Prometheus и Jaeger, широко применяются в промышленных серверных системах.

Наблюдаемость клиентской части — более новое направление, которое отслеживает опыт пользователя при взаимодействии с вашим приложением React. Она включает запись действий пользователя, измерение производительности отрисовки, наблюдение за сетевыми запросами и перехват ошибок JavaScript в браузере.

Серверная часть может выглядеть полностью исправной — с низкой частотой ошибок и быстрыми запросами к базе данных, — пока пользователи сталкиваются с медленным, дёрганым или сломанным интерфейсом. Наблюдаемость клиентской части устраняет этот пробел, измеряя реальный опыт пользователей, а не только работу сервера.

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

Эквивалентом серверных метрик для клиентской части служат веб-показатели: LCP (отрисовка самого крупного элемента) измеряет скорость загрузки, INP (взаимодействие до следующей отрисовки) — отзывчивость, а CLS (совокупное смещение макета) — визуальную стабильность. Это метрики, которые Google использует для ранжирования по основным веб-показателям.

Журналы клиентской части фиксируют ошибки, предупреждения и информационные события в браузере. Основные сигналы — вызовы console.error, необработанные исключения JavaScript (window.onerror), необработанные отклонения промисов (window.onunhandledrejection) и перехваченные ошибки границами ошибок React.

Мониторинг реальных пользователей собирает данные о наблюдаемости из браузеров настоящих пользователей в рабочей среде. RUM автоматически устанавливает инструменты в браузере, фиксируя показатели производительности, ошибки и действия пользователей по мере их возникновения. Это даёт реальные данные, которые не может воспроизвести ни один синтетический тест.

Синтетический мониторинг использует автоматизированные инструменты (Lighthouse CI, Playwright, WebPageTest), чтобы имитировать действия пользователей в контролируемой среде. Он предсказуем и обнаруживает регрессии до того, как они достигают пользователей, но не отражает разнообразие реальных устройств, сетей и сценариев использования.

Несколько коммерческих инструментов предоставляют RUM для React со всеми необходимыми возможностями: Datadog RUM (интегрируется с Datadog APM для сквозных трассировок), New Relic Browser и Sentry Performance (фиксирует ошибки и производительность в одном SDK). Их легко интегрировать, но при масштабировании они дороги.

OpenTelemetry — проект CNCF, который определяет независимые от поставщика интерфейсы и SDK для сбора трассировок, метрик и журналов. Используя инструменты OpenTelemetry, вы владеете своими данными и можете отправлять их в любую совместимую серверную систему — Jaeger, Grafana Tempo, Honeycomb, Datadog или собственный конвейер.

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

В чём состоит ключевое различие между мониторингом реальных пользователей (RUM) и синтетическим мониторингом?

Наблюдаемость клиентской части применяет к браузеру три опоры — трассировки, метрики и журналы. RUM фиксирует реальный опыт пользователей, а синтетический мониторинг заранее обнаруживает регрессии. Веб-показатели (LCP, INP, CLS) — ключевые метрики клиентской части. OpenTelemetry предоставляет независимый от поставщика стандарт для сбора и экспорта этих данных, позволяя свободно выбирать систему наблюдаемости.