Обычно мы настраиваем телеметрию и мониторинг для внутреннего кода и инфраструктуры. Очень важно собирать эти данные, чтобы понимать, как функционирует наша среда, и отслеживать, когда что-то идет не так.
К сожалению, большинство из нас вряд ли отдает такой же приоритет Frontend Telemetry. Некоторые из вас могут задаться вопросом, действительно ли это необходимо. По крайней мере, у меня было такое же мышление, пока я впервые не начал регистрировать телеметрию JavaScript одностраничного приложения.
Посмотрев на данные, я действительно почувствовал, насколько мы оказались в затруднительном положении, пренебрегая внешней телеметрией все эти годы.
В этой статье я расскажу вам о недавнем опыте сбора телеметрии внешнего интерфейса с помощью Azure App Insights, JavaScript SDK и о возможностях, которые это открыло перед нашим порогом.
Не упустите важную часть головоломки.
В одностраничном приложении большинство внутренних операций запускаются взаимодействиями пользователя, происходящими в веб-браузере. Эти взаимодействия могут варьироваться от одного щелчка до сложного конечного автомата, обрабатываемого вашим кодом JavaScript. Когда мы настраиваем телеметрию только для серверной части, мы теряем общую картину происходящего.
Если вы посмотрите на приведенную выше диаграмму, она показывает, что мы можем сгенерировать из данных телеметрии, когда мы объединяем данные телеметрии внешнего и внутреннего интерфейса.
Например, после того, как я установил SDK App Insight JavaScript внутри одностраничного приложения, стала очевидной задержка каждого запроса. Также мне удалось подключить последовательность действий, происходящих из браузера. Кроме того, эта информация имеет решающее значение для понимания непрерывного поведения веб-приложения.
Ценность фиксации полной последовательности действий
Как только мы начали собирать телеметрию из JavaScript, мы смогли проследить до уровня компонента пользовательского интерфейса, который инициирует HTTP-вызовы Backend. Эта информация позволяет нам отследить любую проблему до компонента пользовательского интерфейса, поскольку некоторые из них используют одни и те же ресурсы и методы Backend.
Кроме того, понимание всей последовательности действий придало мне большей уверенности при исследовании проблем. Например, для меня было естественным начать отслеживать любые ошибки, начиная с триггера действия внутри браузера.
Вы можете увидеть визуальную диаграмму этого в Azure App Insight, где она выделяет стрелку (1) - ›(2) на приведенной выше диаграмме красным цветом, отображая соответствующие коды ошибок на месте. Помимо сбора этой телеметрии не требуется никаких дополнительных настроек с помощью App Insights JavaScript SDK. Это функции по умолчанию.
Использование телеметрии для оценки производительности
После добавления поддержки захвата телеметрии внешнего интерфейса мы начали видеть реальные данные о производительности с точки зрения конечного пользователя. Раньше мы измеряли только производительность серверной части.
Важный вывод, который мы здесь получили, заключался в том, что лучшая производительность серверной части не всегда коррелировала с производительностью от начала до конца. Были случаи, когда объем передаваемых данных был достаточно большим, что приводило к снижению производительности, влияющей на общее время отклика.
Кроме того, на некоторых страницах к бэкэнду передавалось несколько запросов, что приводило к увеличению индивидуального времени ответа в зависимости от пропускной способности сети, используемой конечными пользователями. Хотя позже мы смогли смоделировать их, чтобы найти настоящие первопричины, без сбора этой телеметрической информации HTTP-запросов на уровне браузера, мы не сможем найти эти проблемы в первую очередь.
Azure App Insights позволил нам отсортировать все данные запроса-ответа, чтобы мы могли четко визуализировать, какие действия нарушают критерии производительности, установленные для приложения, на основе статистических данных.
Резюме
Я считаю, что решение о захвате внешней телеметрии является одним из самых эффективных решений, которые я сделал совсем недавно. Сегодня я рекомендую записывать телеметрию JavaScript для всех моих проектных команд.
Одна из первых неудач, с которой я столкнулся, заключалась в неопределенности влияния на общую производительность приложения, когда мы начинаем собирать данные телеметрии внешнего интерфейса. Опробовав это с помощью SDK JavaScript для Azure App Insights, я уверен, что эффект практически незаметен.
Кроме того, настроить телеметрию внешнего интерфейса было почти так же просто, как добавить Google Analytics на веб-страницу. Однако при захвате расширенных данных телеметрии на уровне компонента пользовательского интерфейса потребовалось написать некоторый дополнительный код. Но, тем не менее, сложность будет меньше, если вы можете подключить ее к методам жизненного цикла фреймворка, который вы используете.
Я надеюсь, что эта статья была достаточно убедительной, чтобы вы рассмотрели возможность сбора данных телеметрии JavaScript в одностраничных приложениях. Если у вас есть какие-либо вопросы по какой-либо области, которую я обсуждал, не стесняйтесь оставить комментарий.
Совместное использование и управление повторно используемыми JS-компонентами с помощью Bit
Используйте Bit » ( Github ) для совместного использования, документирования и управления повторно используемыми компонентами из разных проектов. Это отличный способ увеличить повторное использование кода, ускорить разработку и создавать масштабируемые приложения.
Bit поддерживает Node, TypeScript, React, Vue, Angular и другие.
