Performance Monitoring использует трассировки для сбора данных о контролируемых процессах в вашем приложении. Трассировка — это отчёт, содержащий данные, собранные между двумя моментами времени в вашем приложении.
Для всех типов приложений Performance Monitoring автоматически собирает трассировку каждого сетевого запроса, отправленного вашим приложением, называемую трассировкой сетевого запроса HTTP/S . Эти трассировки собирают метрики за время между отправкой приложением запроса к конечной точке сервиса и получением ответа от этой конечной точки. Для любой конечной точки, к которой ваше приложение отправляет запрос, Performance Monitoring собирает несколько метрик:
Время ответа — время между отправкой запроса и получением полного ответа.
Размер полезной нагрузки ответа — размер сетевой полезной нагрузки, загруженной приложением, в байтах.
Размер полезной нагрузки запроса — размер сетевой полезной нагрузки, загруженной приложением, в байтах.
Показатель успешности — процент успешных ответов (коды ответов в диапазоне от 100 до 399) по сравнению с общим количеством ответов.
Вы можете просмотреть данные этих трассировок на вкладке «Сетевые запросы» таблицы трассировок, которая находится в нижней части панели мониторинга производительности (подробнее об использовании консоли см . далее на этой странице).
Performance Monitoring автоматически собирает метрики для сетевых запросов, которые используют следующие сетевые библиотеки:
- URLSession
- URLConnection
- NSURLSession
- NSURLConnection
Настройте агрегацию данных сетевых запросов
Помимо готовых инструментов и агрегации данных для сетевых запросов, Performance Monitoring также поддерживает следующие возможности:
- Ручная инструментация трассировки сетевых запросов: встроенный мониторинг охватывает большинство сетевых запросов вашего приложения. Однако некоторые запросы могут не быть зарегистрированы, или вы можете использовать другую библиотеку для выполнения сетевых запросов. В этих случаях вы можете использовать API Performance Monitoring для ручной инструментации трассировки пользовательских сетевых запросов .
- Агрегируйте данные по пользовательским шаблонам URL-адресов: если существуют определенные URL-адреса, которые Firebase не фиксирует с помощью своего автоматического сопоставления шаблонов URL-адресов, вы можете создать пользовательские шаблоны URL-адресов для отслеживания определенного набора URL-адресов с течением времени.
- Настройте способ расчёта показателя успешности: иногда для определённых конечных точек API ожидается код ошибки или он уже обрабатывается в вашем приложении. В таких случаях вы можете настроить способ расчёта показателя успешности и более точно отслеживать показатель успешности сетевых вызовов вашего приложения.
Агрегация данных по шаблонам URL
Firebase Performance Monitoring автоматически агрегирует данные по схожим сетевым запросам, помогая вам понять тенденции в производительности сетевых запросов.
Для каждого запроса Firebase проверяет, соответствует ли URL-адрес сетевого запроса шаблону URL. Если URL-адрес запроса соответствует шаблону URL, Firebase автоматически агрегирует данные запроса по этому шаблону URL. Firebase отображает шаблоны URL и их агрегированные данные на вкладке «Сеть» панели мониторинга производительности консоли Firebase .
Что такое шаблон URL?
Шаблон URL содержит домен и шаблон, который может соответствовать пути URL, например: example.com/*/animals/**
.
Шаблоны URL могут содержать следующие сегменты пути:
- простой текст — соответствует точной строке
-
*
— соответствует любой строке в одном сегменте пути -
**
— соответствует произвольному суффиксу пути
Шаблоны URL могут быть:
- Шаблоны, полученные из Firebase, — называемые автоматическими шаблонами URL
- Пользовательские шаблоны — называемые пользовательскими шаблонами URL
Например: любой из следующих URL-запросов может соответствовать шаблону URL example.com/*/animals/**
.
-
example.com/singapore/animals
-
example.com/australia/animals/spiders
-
example.com/australia/animals/marsupials/koala.png
Домен для шаблона URL также может содержать *
в качестве своего первого сегмента, например: *.example.com/*/fruits/**
.
Firebase сопоставляет каждый запрос только с одним шаблоном URL . Если вы настроили какие-либо пользовательские шаблоны URL , Firebase сначала попытается сопоставить URL-адреса запроса с этими шаблонами. Если Firebase не находит подходящего пользовательского шаблона URL, он сопоставляет URL-адрес запроса с наиболее репрезентативным автоматическим шаблоном URL . Подробнее об автоматических и пользовательских шаблонах URL читайте в следующих разделах.
Автоматические шаблоны URL
Без какой-либо настройки с вашей стороны Performance Monitoring пытается отразить последнее поведение использования вашего приложения, сопоставляя запросы вашего приложения с автоматическими шаблонами URL .
Как работает автоматическое сопоставление шаблонов URL?
Firebase сопоставляет каждый запрос с наиболее репрезентативным шаблоном автоматического URL-адреса, полученным из запросов, отправленных вашим приложением. Обратите внимание, что Firebase сначала пытается сопоставить URL-адреса запросов с любыми настроенными пользовательскими шаблонами URL-адресов .
Ниже приведен простой пример того, как Firebase пытается сопоставить запросы с наиболее репрезентативным шаблоном автоматического URL-адреса для вашего приложения.
Ваше приложение отправляет множество запросов на URL-адреса, такие как:
-
example.com/germany/animals/bears
-
example.com/germany/animals/birds
-
example.com/germany/cars
Firebase определяет, что
example.com/germany/**
является распространенным шаблоном запроса для вашего приложения, и добавляет его как автоматический шаблон URL в ваш проект.Для всех новых соответствующих запросов к этому шаблону URL Firebase агрегирует данные запросов в соответствии с автоматическим шаблоном URL
example.com/germany/**
.-
Через неделю большинство запросов вашего приложения будут адресоваться на
example.com/germany/animals/bears
иexample.com/germany/animals/birds
. Поэтому Firebase формирует более репрезентативный шаблон URL:example.com/germany/animals/**
.Для всех новых запросов, соответствующих этому новому шаблону URL, Firebase агрегирует данные запросов только по новому шаблону URL. Firebase продолжает агрегировать данные запросов к
example.com/germany/cars
поexample.com/germany/**
.Однако в течение следующих нескольких недель количество запросов вашего приложения к
example.com/germany/animals/bears
иexample.com/germany/animals/birds
существенно сократится. Firebase определяет, чтоexample.com/germany/animals/**
не отражает последние данные об использовании вашего приложения, поэтому Firebase начинает сопоставлять эти два запроса сexample.com/germany/**
.Firebase не агрегирует дополнительные данные о запросах по адресу
example.com/germany/animals/**
, поскольку он больше не является наиболее репрезентативным шаблоном автоматического URL-адреса.
Поскольку автоматическое сопоставление шаблонов URL является динамическим, имейте в виду следующее:
Совпадения и агрегированные данные из предыдущих запросов не изменяются из-за новых шаблонов URL. Firebase не выполняет ретроспективное повторное агрегирование данных запросов.
Новые шаблоны URL влияют только на будущие запросы. Firebase сопоставляет каждый новый запрос с наиболее репрезентативным автоматическим шаблоном URL. Обратите внимание, что Firebase сначала пытается сопоставить URL-адреса запросов с любыми настроенными пользовательскими шаблонами URL .
Просмотр автоматических шаблонов URL и их данных
Firebase отображает все шаблоны URL и их агрегированные данные на вкладке «Сетевые запросы» таблицы трассировок, которая находится в нижней части панели «Производительность» консоли Firebase .
Вы можете увидеть шаблоны URL с меткой «Без категории» . Это «широкие» автоматические шаблоны URL, на основе которых Firebase может агрегировать данные по запросам, не соответствующим ни одному более конкретному шаблону URL.
По истечении срока хранения данных , агрегированных по шаблону URL, Firebase удаляет эти данные из шаблона URL. Если срок хранения всех данных, агрегированных по автоматическому шаблону URL, истекает, Firebase удаляет этот шаблон URL из консоли Firebase .
Пользовательские шаблоны URL
Вы можете создать пользовательские шаблоны URL-адресов для отслеживания определённых шаблонов URL-адресов, которые Firebase не регистрирует с помощью своего автоматического сопоставления шаблонов URL-адресов . Например, вы можете использовать пользовательский шаблон URL-адресов для диагностики определённого URL-адреса или для отслеживания определённого набора URL-адресов с течением времени.
Более подробную информацию можно узнать в разделе Создание пользовательских шаблонов URL .
Отслеживайте, просматривайте и фильтруйте данные о производительности
Для просмотра данных о производительности в режиме реального времени убедитесь, что ваше приложение использует версию Performance Monitoring SDK, совместимую с обработкой данных в режиме реального времени. Подробнее о данных о производительности в режиме реального времени …
Отслеживайте конкретные показатели на панели управления
Чтобы отслеживать динамику ключевых показателей, добавьте их на панель показателей в верхней части панели «Производительность» . Вы можете быстро выявлять регрессии, просматривая еженедельные изменения, или убедиться, что недавние изменения в коде повышают производительность.

Чтобы добавить метрику на доску метрик, выполните следующие действия:
- Перейдите на панель управления производительностью в консоли Firebase .
- Щелкните пустую карточку метрики, затем выберите существующую метрику для добавления на доску.
- Нажмите на заполненной карточке метрики, чтобы увидеть дополнительные параметры, например, чтобы заменить или удалить метрику.
На доске показателей отображаются собранные метрические данные с течением времени, как в графической форме, так и в виде числового процентного изменения.
Подробнее об использовании панели инструментов .
Просмотр следов и их данных
Чтобы просмотреть свои трассировки, перейдите на панель управления «Производительность» в консоли Firebase , прокрутите вниз до таблицы трассировок и выберите соответствующую вкладку. В таблице отображаются некоторые основные метрики для каждой трассировки, и вы даже можете отсортировать список по процентному изменению конкретной метрики.
Performance Monitoring предоставляет страницу устранения неполадок в консоли Firebase , где отображаются изменения метрик, что позволяет быстро устранять и минимизировать влияние проблем с производительностью на ваши приложения и пользователей. Вы можете использовать страницу устранения неполадок, когда узнаете о потенциальных проблемах с производительностью, например, в следующих ситуациях:
- Вы выбираете соответствующие показатели на панели управления и замечаете большую разницу.
- В таблице следов вы сортируете так, чтобы самые большие дельты отображались вверху, и видите значительное процентное изменение.
- Вы получите уведомление по электронной почте о проблеме с производительностью.
Доступ к странице устранения неполадок можно получить следующими способами:
- На панели показателей нажмите кнопку Просмотреть сведения о показателях .
- На любой метрической карте выберите
В таблице трасс щелкните имя трассы или любое значение метрики в строке, связанной с этой трассой. В оповещении по электронной почте нажмите кнопку Расследовать сейчас .

- Фильтруйте по версии приложения , чтобы просмотреть данные о предыдущей версии или вашей последней версии.
- Фильтр по устройству , чтобы узнать, как старые устройства работают с вашим приложением
- Фильтр по стране , чтобы убедиться, что местоположение вашей базы данных не влияет на определенный регион.
Узнайте больше о просмотре данных по вашим следам .
Следующие шаги
Узнайте больше об использовании атрибутов для изучения данных о производительности.
Узнайте больше о том, как отслеживать проблемы производительности в консоли Firebase .
Настройте оповещения о сетевых запросах, снижающих производительность вашего приложения. Например, вы можете настроить оповещение по электронной почте для своей команды, если время ответа для определённого шаблона URL превысит заданное вами пороговое значение.
- Просматривайте подробные отчеты о сеансах пользователей , в которых вы можете увидеть определенный след в контексте временной шкалы других следов, собранных в ходе того же сеанса.