Eksportowanie danych z Monitorowania wydajności do BigQuery

Dane z Performance Monitoring z aplikacji na Androida i iOS możesz eksportować do BigQuery w celu dalszej analizy. BigQuery umożliwia analizowanie danych za pomocą BigQuery SQL, eksportowanie ich do innego dostawcy usług w chmurze, a nawet wykorzystywanie danych w niestandardowych modelach ML.

Włączanie eksportuBigQuery

  1. W konsoli Firebase otwórz stronę Integracje, a potem kliknij Połącz na karcie BigQuery.

  2. Postępuj zgodnie z instrukcjami wyświetlanymi na ekranie, aby włączyć BigQuery.

    Gdy włączysz eksport BigQuery w przypadku Performance Monitoring, nastąpią te zmiany:

    • Firebase wyeksportuje kopię Twoich dotychczasowych danych do BigQuery. Początkowe propagowanie danych na potrzeby eksportu może potrwać do 48 godzin.

    • Gdy zostanie on utworzony, jego lokalizacji nie można już zmienić. Możesz natomiast skopiować zbiór danych do innej lokalizacji lub go ręcznie przenieść przez ponowne utworzenie tego zbioru w innej lokalizacji. Więcej informacji znajdziesz w artykule Zmienianie lokalizacji zbioru danych.

    • Firebase skonfiguruje regularną synchronizację danych z projektu Firebase do BigQuery. Te codzienne operacje eksportu zwykle kończą się w ciągu 24 godzin od zaplanowania.

    • Domyślnie wszystkie aplikacje w projekcie są połączone z BigQuery. Wszystkie aplikacje, które dodasz do projektu później, także zostaną automatycznie połączone z BigQuery. Możesz określić, które aplikacje mają wysyłać dane.

Aby wyłączyć eks0port, odłącz projekt w konsoli Firebase.BigQuery

Jakie dane są eksportowane do BigQuery?

W przypadku każdej aplikacji w projekcie eksport tworzy tabelę, która zawiera wszystkie zarejestrowane zdarzenia związane z wydajnością. Każdy wiersz w tabeli to pojedyncze zdarzenie związane z wydajnością, które może być jednym z tych typów:

  • Log czasu trwania – logi czasu, które domyślnie zbierają dane „czasu trwania”, w tym czas uruchamiania aplikacji, czas działania aplikacji na pierwszym planie i w tle, a także wszelkie logi czasu z niestandardowego kodu, które zostały zaimplementowane przez dewelopera.

    • event_type to DURATION_TRACE.
    • event_name jest taka sama jak nazwa logu czasu.

  • Dane logu czasu – dane niestandardowe powiązane z logami czasu z niestandardowego kodu, które zostały zaimplementowane przez dewelopera.

    • event_type to TRACE_METRIC.
    • event_name to nazwa danych.
    • parent_trace_name to nazwa logu czasu, który zawiera te dane.

  • Log czasu ekranu – logi czasu obejmujące cały okres istnienia ekranu (logi czasu renderowania ekranu).

    • event_type to SCREEN_TRACE.
    • event_name to prefiks _st_ oraz rzeczywista nazwa ekranu.

  • Żądanie sieciowe – logi czasu obejmujące cały okres istnienia żądania sieciowego (logi czasu żądań sieciowych HTTP).

    • event_type to NETWORK_REQUEST.
    • event_name to skategoryzowany wzorzec adresu URL żądania sieciowego.

Każde zdarzenie związane z wydajnością zawiera atrybuty zdarzenia (takie jak kraj i operator urządzenia klienta), a także informacje specyficzne dla zdarzenia:

  • Logi czasu trwania, dane logu czasu i logi czasu ekranu zawierają trace_info.
  • Dane logu czasu zawierają trace_info.metric_info.
  • Logi czasu ekranu zawierają trace_info.screen_info.
  • Logi czasu sieci zawierają network_info.

Szczegółowy schemat danych

Nazwa pola Typ Opis
event_timestamp sygnatura czasowa Sygnatura czasowa od początku epoki, gdy zdarzenie rozpoczęło się na urządzeniu klienta (początek logu czasu, początek sieci itp.).
app_display_version ciąg znaków Wersja wyświetlana aplikacji (np. „4.1.7”).
  • W przypadku Androida – VersionName.
  • W przypadku iOS – CFBundleShortVersionString.
app_build_version ciąg znaków Wersja kompilacji aplikacji (np. „1523456”).
  • W przypadku Androida – VersionCode.
  • W przypadku iOS – CFBundleVersion.
os_version ciąg znaków Wersja systemu operacyjnego urządzenia klienta.
  • W przypadku Androida – poziom interfejsu API Androida (np. „26”).
  • W przypadku iOS – wersja iOS (np. „11.4”).
device_name ciąg znaków Nazwa urządzenia klienta (np. „Google Pixel”).
country ciąg znaków Dwuliterowy kod kraju, w którym wystąpiło zdarzenie wystąpiło (np. „US” lub „ZZ” w przypadku nieznanego kraju).
carrier ciąg znaków Operator urządzenia klienta.
radio_type ciąg znaków Aktywny typ radia, gdy wystąpiło zdarzenie (np. „WIFI”).
custom_attributes ARRAY<RECORD> Wszystkie atrybuty niestandardowe dołączone do tego zdarzenia.
custom_attributes.key ciąg znaków Klucz atrybutu niestandardowego.
custom_attributes.value ciąg znaków Wartość atrybutu niestandardowego.
event_type ciąg znaków Typ zdarzenia. Możliwe wartości:
  • DURATION_TRACE – logi czasu, które domyślnie zbierają dane „czasu trwania”, w tym czas uruchamiania aplikacji, czas działania aplikacji na pierwszym planie i w tle, a także wszelkie logi czasu z niestandardowego kodu, które zostały zaimplementowane przez dewelopera.
  • SCREEN_TRACE – logi czasu obejmujące cały okres istnienia ekranu (logi czasu renderowania ekranu).
  • TRACE_METRIC – dane niestandardowe powiązane z logami czasu z niestandardowego kodu, które zostały zaimplementowane przez dewelopera.
  • NETWORK_REQUEST – logi czasu obejmujące cały okres istnienia żądania sieciowego (logi czasu żądań sieciowych HTTP) .
event_name ciąg znaków Nazwa zdarzenia.
  • W przypadku DURATION_TRACE – nazwa logu czasu.
  • W przypadku TRACE_METRIC – nazwa danych niestandardowych.
  • W przypadku SCREEN_TRACE – _st_ oraz nazwa logu czasu.
  • W przypadku NETWORK_REQUEST – wzorzec adresu URL żądania sieciowego .
parent_trace_name ciąg znaków Nazwa nadrzędnego logu czasu, który zawiera dane logu czasu
Występuje tylko w przypadku TRACE_METRIC
trace_info REKORD Występuje tylko w przypadku DURATION_TRACE, SCREEN_TRACE, i TRACE_METRIC.
trace_info.duration_us int64
  • W przypadku DURATION_TRACE i SCREEN_TRACE – długość czasu („czas trwania”) od początku do końca logu czasu.
  • W przypadku TRACE_METRIC – długość czasu („czas trwania”) od początku do końca nadrzędnego logu czasu.
Jednostka: mikrosekunda.
trace_info.screen_info REKORD Występuje tylko w przypadku SCREEN_TRACE.
trace_info.screen_info.slow_frame_ratio float64 Współczynnik wolnych klatek w tym logu czasu ekranu, od 0 do 1 (np. wartość 0,05 oznacza, że renderowanie 5% klatek w tej instancji ekranu trwało dłużej niż 16 ms).
trace_info.screen_info.frozen_frame_ratio float64 Współczynnik zablokowanych klatek w tym logu czasu ekranu, od 0 do 1 (np. wartość 0,05 oznacza, że renderowanie 5% klatek w tej instancji ekranu trwało dłużej niż 700 ms).
trace_info.metric_info REKORD Występuje tylko w przypadku TRACE_METRIC.
trace_info.metric_info.metric_value int64 Wartość danych logu czasu.
network_info REKORD Występuje tylko w przypadku NETWORK_REQUEST.
network_info.response_code int64 Kod odpowiedzi HTTP na odpowiedź sieciową (np. 200, 404).
network_info.response_mime_type ciąg znaków Typ MIME odpowiedzi sieciowej (np. „text/html”).
network_info.request_http_method ciąg znaków Metoda HTTP żądania sieciowego (np. „GET” lub „POST”).
network_info.request_payload_bytes int64 Rozmiar ładunku żądania sieciowego
Jednostka: bajt.
network_info.response_payload_bytes int64 Rozmiar ładunku odpowiedzi sieciowej
Jednostka: bajt.
network_info.request_completed_time_us int64 Mikrosekundy po event_timestamp, gdy wysyłanie żądania sieciowego zostało zakończone
Jednostka: mikrosekunda.
network_info.response_initiated_time_us int64 Mikrosekundy po event_timestamp, gdy rozpoczęła się odpowiedź sieciowa
Jednostka: mikrosekunda.
network_info.response_completed_time_us int64 Mikrosekundy po event_timestamp gdy odpowiedź sieciowa została zakończona
Jednostka: mikrosekunda.

Co można zrobić z wyeksportowanymi danymi?

W kolejnych sekcjach znajdziesz przykłady zapytań, które możesz uruchomić w BigQuery na podstawie wyeksportowanych Performance Monitoring danych.

Dopasowywanie danych widocznych w konsoli

Panel Firebase agreguje dane dzienne w strefie czasowej America/Los_Angeles. Aby dopasować dane widoczne w konsoli, funkcje daty powinny wyraźnie ustawiać America/Los_Angeles jako strefę czasową. W przeciwnym razie funkcja daty domyślnie będzie używać strefy czasowej UTC.

SELECT
  DATE(event_timestamp, 'America/Los_Angeles') AS daily_date,
  APPROX_QUANTILES(trace_info.duration_us, 100)[OFFSET(90)] / 1000000 AS p90_seconds,
FROM `TABLE_NAME`
WHERE
  DATE(event_timestamp, 'America/Los_Angeles')
    >= DATE_SUB( PARSE_DATE('%Y%m%d', 'YYYY-MM-DD'), INTERVAL 7 DAY)
  AND DATE(event_timestamp, 'America/Los_Angeles')
    <= PARSE_DATE('%Y%m%d', 'YYYY-MM-DD')
  AND event_name = '_app_start'
GROUP BY 1
ORDER BY 1 DESC;

Wyświetlanie średniego opóźnienia uruchamiania aplikacji według kraju

SELECT AVG(trace_info.duration_us), country
FROM `TABLE_NAME`
WHERE _PARTITIONTIME > TIMESTAMP("YYYY-MM-DD")
AND event_type = "DURATION_TRACE"
AND event_name = "_app_start"
GROUP BY 2;

Sprawdzanie współczynnika zablokowanych klatek w różnych warunkach

Możesz na przykład sprawdzić współczynnik zablokowanych klatek oraz czas, jaki użytkownicy spędzają na poszczególnych ekranach aplikacji, gdy korzystają z różnych typów radia (Wi-Fi, 4G itp.).

SELECT
  AVG(trace_info.duration_us / 1000000) AS seconds_on_screen,
  AVG(trace_info.screen_info.frozen_frame_ratio) AS frozen_frame_ratio,
  event_name,
  radio_type
FROM `TABLE_NAME`
WHERE _PARTITIONTIME > TIMESTAMP("YYYY-MM-DD")
AND event_type = "SCREEN_TRACE"
GROUP BY event_name, radio_type
ORDER BY event_name, radio_type;

Obliczanie współczynnika trafień w pamięci podręcznej podczas wczytywania określonych typów plików z dysku

Ta analiza zakłada, że zaimplementowano log czasu z niestandardowego kodu na potrzeby wczytywania z dysku z atrybutem niestandardowym o nazwie file-extension oraz danymi niestandardowymi (TRACE_METRIC) o nazwie cache-hit, które są ustawione na 1, jeśli wystąpiło trafienie w pamięci podręcznej, i na 0, jeśli nie.

Możesz na przykład obliczyć współczynnik trafień w pamięci podręcznej podczas wczytywania plików PNG z dysku:

SELECT AVG(trace_info.metric_info.metric_value) AS cache_hit_rate
FROM `TABLE_NAME`
WHERE _PARTITIONTIME > TIMESTAMP("YYYY-MM-DD")
AND event_type = "TRACE_METRIC"
AND event_name = "cache-hit"
AND parent_trace_name = "loadFromDisk"
AND STRUCT("file-extension", "png") IN UNNEST(custom_attributes);

Sprawdzanie, o której porze dnia użytkownicy wysyłają żądania sieciowe

Możesz na przykład sprawdzić, o której godzinie użytkownicy z Polski wysyłają żądania sieciowe z Twojej aplikacji:

SELECT
  count(1) AS hourly_count,
  EXTRACT(HOUR FROM event_timestamp) AS hour_of_day
FROM `TABLE_NAME`
WHERE _PARTITIONTIME > TIMESTAMP("YYYY-MM-DD")
AND event_type = "NETWORK_REQUEST"
AND country = "US"
GROUP BY 2 ORDER BY 2;

Przenoszenie danych z Performance Monitoring w dowolne miejsce

Czasami chcesz uzyskać dostęp do danych Performance Monitoring po stronie serwera lub przesłać je do innego rozwiązania innej firmy. Eksportowanie danych jest obecnie bezpłatne.

Dane możesz eksportować:

  • za pomocą interfejsu internetowego BigQuery

  • za pomocą polecenia CLI bq extract

  • przesyłając zadanie wyodrębniania za pomocą interfejsu API lub bibliotek klienckich.

Ceny

Eksportowanie danych z Performance Monitoring jest bezpłatne, a BigQuery oferuje duże limity bezpłatnego użytkowania. Szczegółowe informacje znajdziesz w BigQuery cenniku lub w BigQuery piaskownicy.