Eksportowanie danych Firebase Crashlytics do BigQuery

Dane z Crashlytics możesz wyeksportować do BigQuery, aby poddać je dalszej analizie. BigQuery umożliwia analizowanie danych z wykorzystaniem BigQuery SQL, eksportowanie ich do innego dostawcy chmury i używanie ich do wizualizacji i niestandardowych paneli w Studiu danych Google.

Włącz funkcję eksportowania BigQuery

  1. Otwórz stronę Integracje w konsoli Firebase.
  2. Na karcie BigQuery kliknij Połącz.
  3. Postępuj zgodnie z instrukcjami wyświetlanymi na ekranie, aby włączyć BigQuery.

Po połączeniu projektu z BigQuery:

  • Firebase konfiguruje codzienne synchronizacje danych z projektu Firebase z BigQuery.
  • Domyślnie wszystkie aplikacje w projekcie są połączone z BigQuery, a wszelkie aplikacje, które dodasz później do projektu, zostaną automatycznie połączone z BigQuery. Możesz określić, które aplikacje mają wysyłać dane.
  • Firebase eksportuje kopię istniejących danych do BigQuery. W przypadku każdej połączonej aplikacji obejmuje to tabelę wsadową zawierającą dane z codziennej synchronizacji.
  • Jeśli włączysz eksport strumieniowy BigQuery z Crashlytics, wszystkie połączone aplikacje będą miały również tabelę czasu rzeczywistego zawierającą dane o ciągłych aktualizacjach.

Aby wyłączyć funkcję BigQuery Export, odłącz projekt w konsoli Firebase.

Jakie dane są eksportowane do BigQuery?

Dane Firebase Crashlytics są eksportowane do zbioru danych BigQuery o nazwie firebase_crashlytics. Domyślnie poszczególne tabele będą tworzone w zbiorze danych Crashlytics dla każdej aplikacji w projekcie. Firebase nadaje nazwy tabelom na podstawie identyfikatora pakietu aplikacji. Okresy są konwertowane na podkreślenia, a na końcu znajduje się nazwa platformy.

Na przykład dane aplikacji o identyfikatorze com.google.test znajdują się w tabeli o nazwie com_google_test_ANDROID. Ta tabela zbiorcza jest aktualizowana raz dziennie. Jeśli włączysz eksport strumieniowy BigQuery z Crashlytics, dane Firebase Crashlytics będą też przesyłane w czasie rzeczywistym do com_google_test_ANDROID_REALTIME.

Każdy wiersz tabeli przedstawia zdarzenie, które wystąpiło w aplikacji, w tym awarie, błędy niekrytyczne i błędy ANR.

Włącz eksport strumieniowy BigQuery z Crashlytics

Możesz strumieniować dane Crashlytics w czasie rzeczywistym dzięki BigQueryStreaming. Można jej używać do dowolnych celów, które wymagają danych bieżących, np. do prezentowania informacji w panelu transmisji na żywo, obserwowania wdrażania na żywo lub monitorowania problemów z aplikacją, które wywołują alerty i niestandardowe przepływy pracy.

Eksport strumieniowy BigQuery z Crashlytics jest niedostępny w trybie piaskownicy BigQuery.

Gdy włączysz eksport strumieniowy do BigQuery w Crashlytics, oprócz tabeli zbiorczej będziesz też mieć tabelę czasu rzeczywistego. Różnice między tabelami:

Tabela wsadowa Tabela czasu rzeczywistego
  • Dane eksportowane raz dziennie
  • Trwałe przechowywanie zdarzeń przed zapisem wsadowym w BigQuery
  • Można wypełnić do 30 dni przed
  • Dane eksportowane w czasie rzeczywistym
  • Brak możliwości uzupełnienia

Tabela wsadowa idealnie nadaje się do długoterminowej analizy i identyfikowania trendów w czasie, ponieważ bezterminowo przechowujemy zdarzenia przed ich zapisaniem i można je uzupełniać w tabeli przez maksymalnie 30 dni. Gdy zapisujemy dane w tabeli czasu rzeczywistego, są one natychmiast zapisywane w BigQuery, dzięki czemu doskonale sprawdza się w przypadku paneli na żywo i alertów niestandardowych. Te 2 tabele można połączyć za pomocą zapytania łączenia, aby uzyskać korzyści obu. Zobacz zapytanie Przykład 9 poniżej.

Domyślnie tabela czasu rzeczywistego ma okres ważności partycji wynoszący 30 dni. Aby dowiedzieć się, jak to zmienić, zapoznaj się z sekcją na temat aktualizowania daty wygaśnięcia partycji.

Włącz strumieniowe przesyłanie danych z Crashlytics z BigQuery

Aby włączyć strumieniowe przesyłanie danych, przejdź do sekcji Crashlytics na stronie Integracje BigQuery i zaznacz pole wyboru Uwzględnij przesyłanie strumieniowe.

Szablon Studia danych

Aby włączyć w szablonie Studia danych dane w czasie rzeczywistym, wykonaj instrukcje podane w artykule Wizualizacja wyeksportowanych danych Crashlytics w Studiu danych.

Widoki

Możesz przekształcić poniższe przykładowe zapytania w widoki za pomocą interfejsu BigQuery. Szczegółowe instrukcje znajdziesz w artykule Tworzenie widoków.

Co można zrobić z wyeksportowanymi danymi?

Eksporty BigQuery zawierają nieprzetworzone dane o awariach, w tym typ urządzenia, system operacyjny, wyjątki (aplikacje na Androida) lub błędy (aplikacje Apple), a także dzienniki Crashlytics oraz inne dane.

Praca z danymi Firebase Crashlytics w BigQuery

Poniższe przykłady pokazują zapytania, które możesz uruchamiać na danych z Crashlytics. Te zapytania generują raporty, które są niedostępne w panelu Crashlytics.

Przykłady zapytań dotyczących Crashlytics

Poniższe przykłady pokazują, jak generować raporty, które zbierają dane o zdarzeniach awarii w czytelniejszy sposób.

Przykład 1: awarie według dnia

Po wyeliminowaniu jak największej liczby błędów główny deweloper uważa, że jej zespół jest wreszcie gotowy do wprowadzenia nowej aplikacji do udostępniania zdjęć. Zanim to zrobi, chce sprawdzić liczbę awarii dziennie w minionym miesiącu, aby mieć pewność, że dzięki usunięciu błędów aplikacja z czasem stała się bardziej stabilna:

SELECT
  COUNT(DISTINCT event_id) AS number_of_crashes,
  FORMAT_TIMESTAMP("%F", event_timestamp) AS date_of_crashes
FROM
 `projectId.firebase_crashlytics.package_name_ANDROID`
GROUP BY
  date_of_crashes
ORDER BY
  date_of_crashes DESC
LIMIT 30;

Przykład 2. Wyszukiwanie najbardziej powszechnych awarii

Aby odpowiednio nadać planom produkcyjnym priorytety, menedżer projektu zastanawia się, jak wskazać 10 najczęstszych awarii w usłudze. Tworzą zapytanie, które zawiera istotne punkty danych:

SELECT
  DISTINCT issue_id,
  COUNT(DISTINCT event_id) AS number_of_crashes,
  COUNT(DISTINCT installation_uuid) AS number_of_impacted_user,
  blame_frame.file,
  blame_frame.line
FROM
  `projectId.firebase_crashlytics.package_name_ANDROID`
WHERE
  event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(),INTERVAL 168 HOUR)
  AND event_timestamp < CURRENT_TIMESTAMP()
GROUP BY
  issue_id,
  blame_frame.file,
  blame_frame.line
ORDER BY
  number_of_crashes DESC
LIMIT 10;

Przykład 3. 10 urządzeń, na których najczęściej występują awarie

Jesień to nowy sezon telefonów! Deweloper wie, że zbliża się sezon problemów związanych z urządzeniami. Aby uniknąć pojawiających się problemów ze zgodnością, zespół utworzył zapytanie identyfikujące 10 urządzeń, na których wystąpiło najwięcej awarii w ciągu ostatniego tygodnia:

SELECT
  device.model,
COUNT(DISTINCT event_id) AS number_of_crashes
FROM
  `projectId.firebase_crashlytics.package_name_ANDROID`
WHERE
  event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 168 HOUR)
  AND event_timestamp < CURRENT_TIMESTAMP()
GROUP BY
  device.model
ORDER BY
  number_of_crashes DESC
LIMIT 10;

Przykład 4. Filtrowanie według klucza niestandardowego

Deweloper gier chce wiedzieć, na którym poziomie występuje najwięcej awarii. Aby pomóc im śledzić te statystyki, ustawili niestandardowy klucz Crashlytics current_level i aktualizują go za każdym razem, gdy użytkownik osiągnie nowy poziom.

Objective-C

CrashlyticsKit setIntValue:3 forKey:@"current_level";

Swift

Crashlytics.sharedInstance().setIntValue(3, forKey: "current_level");

Java

Crashlytics.setInt("current_level", 3);

Mając ten klucz w eksporcie BigQuery, tworzy zapytanie, które zgłasza rozkład wartości current_level powiązanych z poszczególnymi zdarzeniami awarii:

SELECT
COUNT(DISTINCT event_id) AS num_of_crashes,
  value
FROM
  `projectId.firebase_crashlytics.package_name_ANDROID`
UNNEST(custom_keys)
WHERE
  key = "current_level"
GROUP BY
  key,
  value
ORDER BY
  num_of_crashes DESC

Przykład 5. Wyodrębnianie identyfikatorów użytkownika

Deweloper ma aplikację w ramach wcześniejszego dostępu. Większość użytkowników je uwielbia, ale 3 z nich doświadczyło niezwykłej liczby awarii. Aby dotrzeć do sedna problemu, tworzy zapytanie, które pobiera wszystkie zdarzenia awarii dotyczące tych użytkowników, za pomocą ich identyfikatorów:

SELECT *
FROM
  `projectId.firebase_crashlytics.package_name_ANDROID`
WHERE
  user.id IN ("userid1", "userid2", "userid3")
ORDER BY
  user.id
 

Przykład 6. Znajdowanie wszystkich użytkowników, u których występuje konkretny problem z awarią

Pewien deweloper zgłosił krytyczny błąd grupie beta-testerów. Zespół mógł wykorzystać zapytanie z przykładu 2 powyżej, aby zidentyfikować konkretny identyfikator problemu z awarią. Teraz chce uruchomić zapytanie, aby wyodrębnić listę użytkowników aplikacji, których dotyczy ta awaria:

SELECT user.id as user_id
FROM
  `projectId.firebase_crashlytics.package_name_ANDROID`
WHERE
  issue_id = "YOUR_ISSUE_ID"
  AND application.display_version = ""
  AND user.id != ""
ORDER BY
  user.id;

Przykład 7. Liczba użytkowników, których dotyczy awaria, z podziałem na kraje

Teraz zespół wykrył błąd krytyczny podczas wdrażania nowej wersji. Udało mu się użyć zapytania z przykładu 2 powyżej, aby zidentyfikować konkretny identyfikator problemu awarii. Nasz zespół chce teraz sprawdzić, czy awaria nie rozpowszechniła się użytkowników w różnych krajach na całym świecie.

Aby napisać to zapytanie, zespół musi:

  1. Włącz eksportowanie danych do BigQuery w Google Analytics. Zobacz Eksportowanie danych projektu do BigQuery.

  2. Zaktualizuj aplikację, aby przekazywał identyfikator użytkownika zarówno do pakietu SDK Google Analytics, jak i pakietu SDK Crashlytics.

    Objective-C
    CrashlyticsKit setUserIdentifier:@"123456789";
    FIRAnalytics setUserID:@"12345678 9";
    
    Swift
    Crashlytics.sharedInstance().setUserIdentifier("123456789");
    Analytics.setUserID("123456789");
    
    Java
    Crashlytics.setUserIdentifier("123456789");
    mFirebaseAnalytics.setUserId("123456789");
    
  3. Utwórz zapytanie, które korzysta z pola identyfikatora użytkownika w celu złączenia zdarzeń w zbiorze danych BigQuery z Google Analytics zawierającym awarie w zbiorze danych BigQuery Crashlytics:

    SELECT DISTINCT c.issue_id, a.geo.country, COUNT(DISTINCT c.user.id) as num_users_impacted
    FROM `projectId.firebase_crashlytics.package_name_ANDROID` c
    INNER JOIN  `projectId.analytics_YOUR_TABLE.events_*` a on c.user.id = a.user_id
    WHERE
     c.issue_id = "YOUR_ISSUE_ID"
     AND a._TABLE_SUFFIX BETWEEN '20190101'
     AND '20200101'
    GROUP BY
     c.issue_id,
     a.geo.country,
     c.user.id
    

Przykład 8. 5 najważniejszych do tej pory tematów na dziś

Wymaga włączenia eksportu strumieniowego BigQuery Crashlytics

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM
  `your_project.firebase_crashlytics.package_name_ANDROID_REALTIME`
WHERE
  DATE(event_timestamp) = CURRENT_DATE()
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

Przykład 9: 5 najważniejszych problemów od DATE, w tym dziś

Wymaga włączenia eksportu strumieniowego BigQuery Crashlytics.

W tym przykładzie łączymy tabele wsadowe i w czasie rzeczywistym, aby dodać informacje w czasie rzeczywistym do niezawodnych danych wsadowych. Ponieważ event_id jest kluczem podstawowym, za pomocą DISTINCT event_id możemy usunąć z obu tabel duplikaty wspólnych zdarzeń.

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM (
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `your_project.firebase_crashlytics.package_name_ANDROID_REALTIME`
  UNION ALL
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `your_project.firebase_crashlytics.package_name_ANDROID`)
WHERE
  event_timestamp >= "2020-01-13"
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

Schemat Firebase Crashlytics w BigQuery

Gdy połączysz Crashlytics z BigQuery, Firebase eksportuje ostatnie zdarzenia (awarie, błędy niekrytyczne i błędy ANR), w tym zdarzenia z ostatnich 2 dni przed połączeniem. Opcja uzupełnienia danych może trwać do 30 dni.

Od tego momentu do momentu wyłączenia połączenia Firebase będzie codziennie eksportować zdarzenia Crashlytics. Po każdym eksporcie dane mogą być dostępne w BigQuery po kilku minutach.

Zbiory danych

Firebase Crashlytics tworzy w BigQuery nowy zbiór danych na potrzeby danych Crashlytics. Zbiór danych obejmuje cały projekt, nawet jeśli obejmuje on kilka aplikacji.

Tabele

Firebase Crashlytics tworzy w zbiorze danych tabelę dla każdej aplikacji w Twoim projekcie, chyba że zrezygnujesz z eksportowania danych tej aplikacji. Firebase nadaje nazwy tabelom na podstawie identyfikatora pakietu aplikacji, z kropkami przekształconymi w podkreślenia, a na końcu z nazwą platformy.

Na przykład dane aplikacji na Androida o identyfikatorze com.google.test znajdują się w tabeli com_google_test_ANDROID, a dane w czasie rzeczywistym (jeśli są włączone) – w tabeli o nazwie com_google_test_ANDROID_REALTIME.

Tabele zawierają standardowy zestaw danych Crashlytics oraz wszelkie niestandardowe klucze Crashlytics zdefiniowane przez programistów.

Wiersze

Każdy wiersz w tabeli oznacza błąd napotkany przez aplikację.

Kolumny

Kolumny w tabeli są identyczne w przypadku awarii, błędów niekrytycznych i błędów ANR. Jeśli włączony jest eksport strumieniowy do BigQuery, tabela czasu rzeczywistego będzie zawierać te same kolumny co tabela wsadowa. Kolumny w ramach eksportu są wymienione poniżej.

Bez zrzutów stosu

Kolumny występujące w wierszach reprezentujących zdarzenia bez zrzutów stosu.

Nazwa pola Typ danych Opis
platform CIĄG ZNAKÓW Aplikacje Apple lub na Androida
identyfikator_pakietu CIĄG ZNAKÓW Identyfikator pakietu, np.com. google.gmail.
identyfikator_zdarzenia CIĄG ZNAKÓW Unikalny identyfikator wydarzenia.
is_fatal (krytyczny) WARTOŚĆ LOGICZNA Wskazuje, czy aplikacja uległa awarii
typ błędu CIĄG ZNAKÓW Typ błędu zdarzenia (FATAL, NON_FATAL, ANR)
identyfikator_problemu CIĄG ZNAKÓW Problem związany ze zdarzeniem
wariant_id CIĄG ZNAKÓW Wariant problemu powiązany z tym zdarzeniem
Pamiętaj, że nie wszystkie zdarzenia mają powiązany wariant problemu.
event_timestamp SYGNATURA CZASOWA czas wystąpienia zdarzenia;
device REKORD Urządzenie, na którym wystąpiło zdarzenie
device.Producer, CIĄG ZNAKÓW Producent urządzenia
urządzenie.model CIĄG ZNAKÓW Model urządzenia
device.Architecture CIĄG ZNAKÓW X86_32, X86_64, ARMV7, ARM64, ARMV7S lub ARMV7K
pamięć REKORD Stan pamięci urządzenia
Pamięć.używana INT64 Wykorzystane bajty pamięci
storage.free INT64 Pozostałe bajty pamięci
magazynowanie REKORD Pamięć trwała urządzenia
miejsce na dane.wykorzystane INT64 Zajęte bajty miejsca na dane
miejsce na dane.bezpłatnie INT64 Wolne bajty miejsca na dane
System operacyjny REKORD Szczegółowe informacje o systemie operacyjnym na urządzeniu
wersja_systemu_operacyjnego.wersja_wyświetlana CIĄG ZNAKÓW Wersja systemu operacyjnego urządzenia.
operating_system.name CIĄG ZNAKÓW Nazwa systemu operacyjnego na urządzeniu
stan_systemu_operacyjnego.modyfikacja_stanu_modyfikacji CIĄG ZNAKÓW Określa, czy urządzenie zostało zmodyfikowane, na przykład po jailbreaku/zrootowaniu (MODIFIED lub UNMODIFIED).
ChromeOS.type [typ_systemu_operacyjnego] CIĄG ZNAKÓW Typ systemu operacyjnego działającego na urządzeniu (np. IOS, MACOS). Dostępny tylko w przypadku aplikacji platform Apple
operacyjny_system.device_type CIĄG ZNAKÓW Typ urządzenia (np. URZĄDZENIE MOBILNE, TABLET, telewizor itp.), nazywane też „kategorią urządzenia”.
aplikacja REKORD Aplikacja, która wygenerowała zdarzenie
application.build_version CIĄG ZNAKÓW Wersja kompilacji aplikacji
application.display_version CIĄG ZNAKÓW
użytkownik REKORD Opcjonalnie: informacje zebrane o użytkowniku aplikacji
user.name CIĄG ZNAKÓW Opcjonalnie: nazwa użytkownika
user.email CIĄG ZNAKÓW Opcjonalnie: adres e-mail użytkownika
user.id CIĄG ZNAKÓW Opcjonalnie: identyfikator aplikacji powiązany z użytkownikiem
klucze_niestandardowe POWTÓRZONY REKORD Pary klucz-wartość zdefiniowane przez programistę
klucze_niestandardowe.klucz CIĄG ZNAKÓW Klucz zdefiniowany przez dewelopera
niestandardowe_klucze.wartość CIĄG ZNAKÓW Wartość określona przez programistę
instalacja_uuid CIĄG ZNAKÓW Identyfikator określający unikalną instalację aplikacji i urządzenia
Crashlytics_sdk_versions CIĄG ZNAKÓW Wersja pakietu SDK Crashlytics, która wygenerowała zdarzenie
app_orientation, CIĄG ZNAKÓW PORTRAIT, LANDSCAPE, FACE_UP lub FACE_DOWN
device_orientation, CIĄG ZNAKÓW PORTRAIT, LANDSCAPE, FACE_UP lub FACE_DOWN
stan_procesu CIĄG ZNAKÓW WPROWADZENIE lub FOREGROUND
logi POWTÓRZONY REKORD Wiadomości logu oznaczone sygnaturą czasową generowane przez rejestrator Crashlytics (jeśli są włączone).
Logging.timestamp SYGNATURA CZASOWA data utworzenia dziennika,
Logi.message CIĄG ZNAKÓW Zapisany komunikat
menu nawigacyjne POWTÓRZONY REKORD Menu nawigacyjne Google Analytics oznaczone sygnaturą czasową (jeśli jest włączone)
breadcrumbs.timestamp SYGNATURA CZASOWA Sygnatura czasowa powiązana z menu nawigacyjnym
breadcrumbs.name CIĄG ZNAKÓW Nazwa powiązana z menu nawigacyjnym
menu nawigacyjne.params POWTÓRZONY REKORD Parametry powiązane z menu nawigacyjnym
menu nawigacyjne.params.klucz CIĄG ZNAKÓW Klucz parametru powiązany z menu nawigacyjnym
menu nawigacyjne.params.value CIĄG ZNAKÓW Wartość parametru powiązana z menu nawigacyjnym
przyczyna_przynależności REKORD Ramka zidentyfikowana jako główna przyczyna awarii lub błędu
rama_blame.line INT64 Numer wiersza pliku ramki.
rama_blame.file CIĄG ZNAKÓW Nazwa pliku ramki
ramka_wina.symbol CIĄG ZNAKÓW symbol nawodnienia lub symbol surowej wody, jeśli nie jest nawodniony;
blame_frame.offset INT64 Odsunięcie bajtów na obraz binarny zawierający kod, nieskonfigurowana w przypadku wyjątków w języku Java
adres_ramki_blame.adres INT64 Adres obrazu binarnego, który zawiera kod, bez ustawienia dla ramek Java
rama_blame.library CIĄG ZNAKÓW Wyświetlana nazwa biblioteki zawierającej ramkę
blame_frame.owner CIĄG ZNAKÓW DEWELOPER, DOSTAWCA, DZIAŁANIE, PLATFORMA lub SYSTEM
blame_frame.blamed, WARTOŚĆ LOGICZNA Czy według analizy Crashlytics ta ramka jest przyczyną awarii lub błędu
wyjątki POWTÓRZONY REKORD Tylko Android: wyjątki, które wystąpiły podczas tego zdarzenia. Zagnieżdżone wyjątki są przedstawiane w odwrotnej kolejności chronologicznej (odczyt: ostatni rekord to pierwszy wyjątek)
wyjątki.typ CIĄG ZNAKÓW Typ wyjątku, np. java.lang.IllegalStateException
wyjątek.exception_message CIĄG ZNAKÓW Komunikat powiązany z wyjątkiem
wyjątki.nested WARTOŚĆ LOGICZNA Prawda dla wszystkich oprócz ostatniego zgłoszonego wyjątku (tj. pierwszego rekordu)
wyjątki.title CIĄG ZNAKÓW Tytuł wątku
wyjątki.podtytuł CIĄG ZNAKÓW Podtytuł wątku
messages.blamed (wyjątki) WARTOŚĆ LOGICZNA Prawda, jeśli Crashlytics ustali, że wyjątek jest odpowiedzialny za błąd lub awarię
wyjątki.frames POWTÓRZONY REKORD Klatki powiązane z wyjątkiem
wyjątki.frames.line INT64 Numer wiersza pliku ramki.
wyjątki.ramki.file CIĄG ZNAKÓW Nazwa pliku ramki
wyjątki.ramki.symbol CIĄG ZNAKÓW symbol nawodnienia lub symbol surowej wody, jeśli nie jest nawodniony;
wyjątki.frames.offset INT64 Odsunięcie bajtów na obraz binarny zawierający kod, nieskonfigurowana w przypadku wyjątków w języku Java
wyjątki.ramki.adres INT64 Adres obrazu binarnego, który zawiera kod, bez ustawienia dla ramek Java
wyjątki.frames.library, CIĄG ZNAKÓW Wyświetlana nazwa biblioteki zawierającej ramkę
wyjątki.frames.owner CIĄG ZNAKÓW DEWELOPER, DOSTAWCA, DZIAŁANIE, PLATFORMA lub SYSTEM
wyjątek.frames.blamed WARTOŚĆ LOGICZNA Czy według analizy Crashlytics ta ramka jest przyczyną awarii lub błędu
error POWTÓRZONY REKORD Tylko aplikacje Apple: błędy niekrytyczne
error.queue_name CIĄG ZNAKÓW Kolejka, w której działał wątek
kod błędu. INT64 Kod błędu powiązany z niestandardowym zapisanym błędem NSError aplikacji
błąd.tytuł CIĄG ZNAKÓW Tytuł wątku
error.podtytuł CIĄG ZNAKÓW Podtytuł wątku
error.blamed WARTOŚĆ LOGICZNA Czy według analizy Crashlytics ta ramka jest przyczyną błędu
error.frames POWTÓRZONY REKORD Ramki zrzutu stosu
error.frames.line INT64 Numer wiersza pliku ramki.
error.frames.file CIĄG ZNAKÓW Nazwa pliku ramki
error.frames.symbol CIĄG ZNAKÓW symbol nawodnienia lub symbol surowej wody, jeśli nie jest nawodniony;
error.frames.offset INT64 Wartość przesunięcia bajtów na obraz binarny zawierający kod
error.frames.address INT64 Adres w obrazie binarnym, który zawiera kod
error.frames.library CIĄG ZNAKÓW Wyświetlana nazwa biblioteki zawierającej ramkę
error.frames.owner CIĄG ZNAKÓW DEWELOPER, DOSTAWCA, DZIAŁANIE, PLATFORMA lub SYSTEM
error.frames.blamed WARTOŚĆ LOGICZNA Czy według analizy Crashlytics ta ramka jest przyczyną błędu
wątki POWTÓRZONY REKORD Wątki obecne w momencie wydarzenia
threads.crashed WARTOŚĆ LOGICZNA Czy wątek uległ awarii
threads.nazwa_wątku CIĄG ZNAKÓW Nazwa wątku
threads.queue_name CIĄG ZNAKÓW Tylko aplikacje Apple: kolejka, w której działał wątek
threads.signal_name CIĄG ZNAKÓW Nazwa sygnału, który spowodował awarię aplikacji, występujący tylko w wątkach natywnych, w których wystąpiła awaria
threads.signal_code CIĄG ZNAKÓW Kod sygnału, który spowodował awarię aplikacji; występuje tylko w wątkach natywnych, w których wystąpiła awaria
threads.crash_address INT64 Adres sygnału, który spowodował awarię aplikacji; występuje tylko w wątkach natywnych, w których wystąpiła awaria
threads.code INT64 Tylko aplikacje Apple: kod błędu niestandardowego zapisanego błędu NSError aplikacji
threads.title CIĄG ZNAKÓW Tytuł wątku
threads.Caption CIĄG ZNAKÓW Podtytuł wątku
threads.blamed WARTOŚĆ LOGICZNA Czy według analizy Crashlytics ta ramka jest przyczyną awarii lub błędu
threads.frames POWTÓRZONY REKORD Ramki wątku.
threads.frames.line INT64 Numer wiersza pliku ramki.
threads.frames.file CIĄG ZNAKÓW Nazwa pliku ramki
threads.frames.symbol CIĄG ZNAKÓW Symbol nawodnienia lub symbol nieprzetworzony, jeśli nie jest hydromasażowy.
threads.frames.offset INT64 Wartość przesunięcia bajtów na obraz binarny zawierający kod
threads.frames.address INT64 Adres w obrazie binarnym, który zawiera kod
threads.frames.library, CIĄG ZNAKÓW Wyświetlana nazwa biblioteki zawierającej ramkę
threads.frames.owner CIĄG ZNAKÓW DEWELOPER, DOSTAWCA, DZIAŁANIE, PLATFORMA lub SYSTEM
threads.frames.blamed WARTOŚĆ LOGICZNA Czy według analizy Crashlytics ta ramka jest przyczyną błędu
unity_metadata.unity_version CIĄG ZNAKÓW Wersja Unity działająca na tym urządzeniu
kompilacja_jednostek_metadanych.debug WARTOŚĆ LOGICZNA Jeśli jest to kompilacja do debugowania
unity_metadata.processor_type CIĄG ZNAKÓW Typ procesora
unity_metadata.processor_count INT64 Liczba procesorów (rdzeni)
jednostkowe_metadane.procesor_częstotliwość_mhz INT64 Częstotliwość procesorów w MHz
jednostki_metadanych.systemu_memory_rozmiar_mb INT64 Rozmiar pamięci systemu w MB
jednostkowe_metadane.grafiki_rozmiar_pamięci_MB INT64 Pamięć karty graficznej w MB
identyfikator_jednostki_metadane.grafiki INT64 Identyfikator urządzenia graficznego
identyfikator_dostawcy_jednostek_metadanych.graficznych INT64 Identyfikator dostawcy procesora graficznego
jednostka_metadanych.grafiki_nazwa_urządzenia CIĄG ZNAKÓW Nazwa urządzenia graficznego
dostawca_metadanych_jednostek.graficznych_urządzenie_dostawcy CIĄG ZNAKÓW Dostawca urządzenia graficznego
wersja_metadanych_jednostek.graficzna_wersja_urządzenia CIĄG ZNAKÓW Wersja karty graficznej.
unity_metadata.graphics_device_type CIĄG ZNAKÓW Typ urządzenia graficznego
poziom_metadanych_jednostek.grafikas_shadera INT64 Poziom cieniowania grafiki
unity_metadata.graphics_render_target_count INT64 Liczba celów renderowania graficznego
obsługa_metadanych_jednostek.grafikas_kopii_tekstu_jednostkowej CIĄG ZNAKÓW możliwość kopiowania tekstury grafiki zgodnie z definicją w interfejsie Unity API;
unity_metadata.graphics_max_texture_size INT64 Maksymalny rozmiar przeznaczony do renderowania tekstury
metadane_jednostek.rozmiar_ekranu_piks. CIĄG ZNAKÓW Rozmiar ekranu w pikselach podany jako szerokość x wysokość.
metadane_jednostek.rozdzielczości_ekranu_dpi CIĄG ZNAKÓW Wartość DPI ekranu w postaci liczby zmiennoprzecinkowej.
jednostkowe_metadane.ekran_odświeżania_częstotliwości_hz INT64 Częstotliwość odświeżania ekranu w Hz

Wizualizacja wyeksportowanych danych z Crashlytics w Studiu danych

Studio danych Google przekształca zbiory danych Crashlytics w BigQuery w raporty, które można łatwo odczytywać, udostępniać i w pełni dostosowywać.

Więcej informacji o korzystaniu ze Studia danych znajdziesz w krótkim przewodniku po Studiu danych: Witamy w Studiu danych.

Korzystanie z szablonu raportu Crashlytics

Studio danych zawiera przykładowy raport dotyczący Crashlytics, który zawiera kompleksowy zestaw wymiarów i danych z wyeksportowanego schematu BigQuery z Crashlytics. Jeśli masz włączony eksport strumieniowy BigQuery z Crashlytics, możesz wyświetlać te dane na stronie Trendy w czasie rzeczywistym w szablonie Studia danych.Możesz użyć przykładu jako szablonu, aby szybko utworzyć nowe raporty i wizualizacje na podstawie nieprzetworzonych danych o awariach Twojej aplikacji:

  1. Otwórz szablon panelu Studia danych Crashlytics.
  2. Kliknij Użyj szablonu w prawym górnym rogu.
  3. W menu Nowe źródło danych wybierz Utwórz nowe źródło danych.
  4. Na karcie BigQuery kliknij Wybierz.
  5. Wybierz tabelę zawierającą wyeksportowane dane z Crashlytics. W tym celu kliknij Moje projekty > [nazwa-projektu] > firebase_crashlytics > [nazwa-twojej-tabeli]. Twoja tabela wsadowa jest zawsze dostępna do wyboru. Jeśli eksport strumieniowy BigQuery jest włączony, możesz zamiast tego wybrać tabelę czasu rzeczywistego.
  6. W sekcji Configuration (Konfiguracja) ustaw opcję Crashlytics level level (Poziom szablonu Crashlytics) na Default (Domyślny).
  7. Kliknij Połącz, aby utworzyć nowe źródło danych.
  8. Kliknij Add to Report (Dodaj do raportu), aby wrócić do szablonu Crashlytics.
  9. Na koniec kliknij Utwórz raport, aby utworzyć kopię szablonu panelu Studia danych Crashlytics.