Настольное приложение не работает как единая страница браузера. Процессы рендерера Chromium отображают интерфейс, в то время как главный процесс Node.js управляет жизненным циклом приложения, интеграцией с ОС, фоновыми задачами и межпроцессным взаимодействием (IPC). Поскольку команды переносят аутентификацию, фоновую синхронизацию, запросы моделей и сетевую оркестрацию в главный процесс, мониторинг только рендерера оставляет критически важное поведение вне поля зрения. Сбой или неуспешный запрос в Node.js могут завершить сеанс пользователя или оставить пользовательский интерфейс со старыми данными без создания данных Real User Monitoring (RUM), необходимых инженерам для расследования.
Datadog Electron SDK расширяет RUM до главного процесса Node.js и объединяет события главного процесса и рендерера в единой временной шкале сеанса. Он фиксирует ошибки, сбои, представления (views) и исходящие сетевые запросы из Node.js как события RUM, в то время как Browser SDK продолжает собирать пользовательскую активность в Chromium. Electron SDK также использует библиотеку трассировки Datadog Node.js для связывания IPC и сетевых задач с бэкенд-трассировками, чтобы команды могли отслеживать запрос от действия пользователя до служб, которые его обрабатывали.
В этой статье мы объясним, как:
- Устранить слепую зону мониторинга главного процесса Electron
Устранить слепую зону мониторинга главного процесса Electron
- Унифицировать сеансы RUM в Node.js и Chromium
Унифицировать сеансы RUM в Node.js и Chromium
- Перехватывать сбои и сетевые запросы из главного процесса
Перехватывать сбои и сетевые запросы из главного процесса
- Трассировать работу от рендерера до бэкенд-сервисов
Трассировать работу от рендерера до бэкенд-сервисов
Устранить слепую зону мониторинга главного процесса Electron
Представьте настольное приложение, которое закрывается во время ночной фоновой синхронизации. Служба поддержки получает сообщения от пользователей, но сеанс RUM из рендерера просто обрывается. Сбой произошел в главном процессе, поэтому временная шкала на уровне браузера не содержит ошибки, неудачного ресурса или стектрейса, объясняющего выход из программы. Инженерам приходится воспроизводить проблему локально или собирать воедино несвязанные логи и бэкенд-трассировки.
Этот пробел возникает из-за процессной модели Electron. Каждый рендерер запускает веб-контент в Chromium, в то время как главный процесс управляет окнами, нативными модулями, доступом к файловой системе, подпроцессами и IPC между компонентами приложения. Клик пользователя может начаться в рендерере, инициировать работу в Node.js, а затем вызвать бэкенд API. Мониторинг только первой и последней частей оставляет процесс, координировавший запрос, без наблюдения.
Эта отсутствующая середина имеет тем большее значение, чем больше настольных приложений переносят работу из рендерера. Например, оборванное соединение WebSocket в главном процессе может остановить фоновые обновления, даже если интерфейс остается отзывчивым. Пользователи видят устаревшие данные, в то время как телеметрия фронтенда предполагает, что приложение работает исправно. Сбор активности главного процесса наряду с активностью рендерера дает инженерам контекст для определения того, где разошлось поведение.
Унифицировать сеансы RUM в Node.js и Chromium
Electron SDK использует компонент Node.js в главном процессе для управления сеансом RUM, сопоставления событий, пакетной обработки данных и отправки их в Datadog. Browser SDK продолжает работать на страницах рендерера, но перенаправляет события рендерера через мост Electron, чтобы оба слоя выполнения использовали один и тот же контекст сеанса. В результате получается единый сеанс RUM, который включает представления, действия, ошибки и ресурсы со всего настольного приложения.
События сохраняют контекст о процессе и среде выполнения, которые их создали. Это позволяет различать активность Node.js и активность Chromium, сохраняя обе на одной временной шкале. Информация о версиях Electron, Node.js и Chromium также помогает изолировать проблемы, затрагивающие конкретный выпуск настольного приложения или комбинацию сред выполнения.
В примере с фоновой синхронизацией сбой главного процесса теперь отображается в том же сеансе, что и предшествующая активность пользователя в рендерере. Инженеры могут просмотреть действия и ресурсы, приведшие к сбою, без сопоставления отдельных идентификаторов сеансов или переключения между несвязанными наборами данных. Этот общий контекст делает сеанс RUM удобной отправной точкой для техподдержки настольных ПК и расследования инцидентов.
Перехватывать сбои и сетевые запросы из главного процесса
Сбои главного процесса особенно деструктивны, так как они могут закрыть все приложение. Electron SDK автоматически сообщает необработанные исключения и критические сбои нативных дампов памяти (minidump) как ошибки RUM. Datadog помещает эти ошибки в контекст сеанса, поэтому инженеры могут изучить сбой вместе с предшествовавшей ему активностью, вместо того чтобы видеть только внезапно завершенный сеанс.
SDK также записывает исходящие HTTP-запросы из главного процесса как ресурсы RUM и создает представление RUM для экземпляра главного процесса. Это объединяет фоновые вызовы API, запросы синхронизации и другую сетевую активность Node.js в тот же рабочий процесс анализа, что и ресурсы рендерера. Когда запрос завершается ошибкой или замедляется, вы можете сравнить его с окружающими ошибками, представлениями и действиями пользователя.
Это более широкое покрытие событий помогает командам отличать симптом в UI от причины в главном процессе. Например, рендерер может продолжать отображать кэшированные данные после сбоя запроса Node.js, или приложение может завершить работу после необработанного исключения во время операции на уровне ОС. В обоих случаях сеанс содержит свидетельства из слоя, где возник сбой.
Трассировать работу от рендерера до бэкенд-сервисов
События RUM объясняют, что почувствовал пользователь, но для некоторых расследований требуются замеры времени на уровне кода между границами процессов и служб. Electron SDK использует библиотеку трассировки Datadog Node.js (dd-trace) для захвата трассировок сетевых вызовов главного процесса, выполнения команд и сообщений IPC. Когда действие рендерера инициирует работу в Node.js, контекст трассировки может следовать за этой работой в инструментированный бэкенд-сервис.
SDK связывает спаны мониторинга производительности приложений (APM) из приложения Electron с сеансом RUM. Из действия пользователя или ресурса в RUM Explorer инженеры могут перейти к связанной трассировке и изучить водопад спанов в главном процессе и бэкенде. Это сохраняет контекст пользователя и одновременно выявляет задержки, ошибки и зависимости на каждом шаге.
Предположим, клик по кнопке отправляет сообщение IPC главному процессу, который затем вызывает API, возвращающий ошибку. Мониторинг только рендерера может показать клик и общую ошибку UI, в то время как мониторинг бэкенда показывает ошибку API без четкого пользовательского контекста. С Electron SDK трассировка связывает работу IPC и запрос бэкенда с сеансом RUM, упрощая отслеживание пути.
Начало работы с Electron SDK
Объединяя ошибки главного процесса, ресурсы и трассировки в том же контексте, что и события RUM рендерера, Datadog Electron SDK помогает командам расследовать сбои, которые раньше исчезали на границе между Chromium и Node.js. Один сеанс может показать, что сделал пользователь, что обработал главный процесс и какие бэкенд-сервисы участвовали, уменьшая объем ручного сопоставления, необходимого для отладки настольных приложений через границы процессов.
Начало работы состоит из двух шагов: установите @datadog/electron-sdk и инициализируйте его в основном процессе, а также добавьте Datadog Browser SDK на каждую страницу рендерера. После этого RUM Explorer и APM предоставляют единый рабочий процесс для перехода между пользовательской сессией и стоящей за ней трассировкой.
Datadog Electron SDK общедоступен для Electron версии 39 и более поздних. Если вы впервые используете Datadog,
