Eksportowanie danych z Firebase Crashlytics do BigQuery

Dane Firebase Crashlytics możesz wyeksportować do pliku BigQuery, aby przeanalizować je dokładniej. BigQuery umożliwia analizowanie danych za pomocą BigQuery SQL, eksportowanie ich do innego dostawcy usług w chmurze oraz wykorzystywanie do wizualizacji i paneli niestandardowych w Studiu danych Google.

Włącz eksport do usługi BigQuery

  1. W konsoli Firebase otwórz stronę Integracje.

  2. Na karcie BigQuery kliknij Połącz.

  3. Aby umożliwić eksportowanie do BigQuery, postępuj zgodnie z instrukcjami wyświetlanymi na ekranie.

    Jeśli chcesz mieć dostęp do danych Crashlytics w BigQuery w czasie zbliżonym do rzeczywistego, rozważ użycie eksportu strumieniowego.

Co się stanie, gdy włączysz eksport?

  • Wybierasz lokalizację zbioru danych. Po utworzeniu zbioru danych jego lokalizacji nie można już zmienić. Możesz natomiast skopiować zbiór danych do innej lokalizacji lub ręcznie przenieść (ponownie utworzyć) zbiór danych w innej lokalizacji. Więcej informacji znajdziesz w artykule Zmienianie lokalizacji dotychczasowych eksportów.

    Ta lokalizacja dotyczy tylko danych eksportowanych do BigQuery. Nie ma wpływu na lokalizację danych przechowywanych na potrzeby korzystania w panelu Crashlytics w konsoli Firebase lub w Android Studio.

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

  • Firebase konfiguruje codzienną synchronizację danych z usługą BigQuery.

    • Po połączeniu projektu musisz zwykle zaczekać do następnej synchronizacji, aby pierwszy zestaw danych został wyeksportowany do BigQuery.

    • Codzienna synchronizacja odbywa się raz dziennie, niezależnie od harmonogramu eksportu BigQuery. Pamiętaj, że czas i długość trwania zadania synchronizacji mogą się zmienić, więc nie zalecamy planowania dalszych operacji ani zadań na podstawie określonego czasu eksportu.

  • Firebase eksportuje kopię Twoich dotychczasowych danych do usługi BigQuery. Początkowa propagacja danych na potrzeby eksportu może potrwać do 48 godzin.

    • W przypadku każdej połączonej aplikacji ten eksport obejmuje tabelę zbiorczą z danymi z codzienniej synchronizacji.

    • Możesz ręcznie zaplanować uzupełnianie danych w tabeli zbiorczej z ostatnich 30 dni lub z daty ostatniego włączenia eksportu do BigQuery (w zależności od tego, która z tych dat jest najnowsza).

    Pamiętaj, że jeśli eksport danych Crashlytics został włączony przed połową października 2024 r., możesz też uzupełnić dane z 30 dni poprzedzających dzień włączenia eksportu.

  • Jeśli włączysz eksport strumieniowy Crashlytics do BigQuery, wszystkie połączone aplikacje będą też mieć tabelę w czasie rzeczywistym z ciągle aktualizowanymi danymi.

Aby dezaktywować eksport do usługi BigQuery, 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 w przypadku każdej aplikacji w projekcie zostaną utworzone osobne tabele w zbiorze danych Crashlytics. Firebase nadaje nazwy tabelom na podstawie identyfikatora aplikacji, przy czym kropki są zamieniane na podkreślenia, a na końcu dodawana jest nazwa platformy.

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

Każdy wiersz w tabeli odpowiada zdarzeniu, które wystąpiło w aplikacji, m.in. awariom, niekrytycznym błędom i zgłoszeniom ANR.

Eksport strumieniowy Crashlytics do BigQuery

Dane Crashlytics możesz przesyłać strumieniowo w czasie rzeczywistym za pomocą BigQuery. Możesz go używać do dowolnego celu, który wymaga danych na żywo, np. prezentowania informacji w panelu na żywo, obserwowania wdrażania na żywo lub monitorowania problemów z aplikacją, które powodują alerty i niestandardowe przepływy pracy.

Gdy włączysz eksport strumieniowy Crashlytics do BigQuery, oprócz tabeli zbiorczej będziesz mieć też tabelę w czasie rzeczywistym. Oto różnice między tymi tabelami, o których warto pamiętać:

Tabela zbiorcza Tabela Czas rzeczywisty
  • Dane są eksportowane raz dziennie.
  • Zdarzenia są trwale przechowywane przed zapisem zbiorczym w BigQuery.
  • Dane można uzupełnić do 30 dni wstecz*.
  • Dane są eksportowane w czasie rzeczywistym.
  • Nie można uzupełnić brakujących danych.

Tabela zbiorcza jest idealna do długoterminowej analizy i określania trendów na przestrzeni czasu, ponieważ zdarzenia są trwało przechowywane przed zapisaniem i można je uzupełnić w tabeli przez maksymalnie 30 dni*. Gdy zapisujemy dane w tabeli czasu rzeczywistego, zapisujemy je też natychmiast w tabeli BigQuery. Dzięki temu są one idealne do paneli na żywo i alertów niestandardowych. Aby korzystać z zalet obu tabel, możesz połączyć je za pomocą zapytania łączącego.

Domyślny czas ważności partycji tabeli w czasie rzeczywistym wynosi 30 dni. Aby dowiedzieć się, jak to zmienić, zapoznaj się z sekcją Ustawianie daty wygaśnięcia partycji w dokumentacji BigQuery.

* Więcej informacji o obsługiwaniu danych zapasowych znajdziesz w artykule Przejście na nową infrastrukturę eksportu.

Włącz eksport strumieniowy Crashlytics do BigQuery

  1. W konsoli Firebase otwórz stronę Integracje.

  2. Na karcie BigQuery kliknij Zarządzaj.

  3. Zaznacz pole wyboru Uwzględnij strumieniowanie.

To działanie włącza strumieniowanie dla wszystkich połączonych aplikacji.

Co można zrobić z wyeksportowanymi danymi?

Dane eksportowane do pliku BigQuery zawierają surowe dane o awariach, w tym typ urządzenia, system operacyjny, wyjątki (aplikacje na Androida) lub błędy (aplikacje na urządzenia Apple), a także inne dane.Crashlytics

W dalszej części tej strony możesz sprawdzić, jakie dokładnie dane Crashlytics są eksportowane, oraz schemat tabeli.

Używanie szablonu Studia danych

Aby włączyć dane w czasie rzeczywistym w szablonie Studia danych, postępuj zgodnie z instrukcjami podanymi w artykule Wizualizacja wyeksportowanych danych Crashlytics w Studiu danych.

Tworzenie widoków

Zapytania możesz przekształcać w widoki za pomocą interfejsu BigQuery. Szczegółowe instrukcje znajdziesz w dokumentacji BigQuery dotyczącej tworzenia widoków.

Uruchamianie zapytań

Poniższe przykłady pokazują zapytania, które możesz uruchamiać na danych Crashlytics, aby generować raporty, które agregują dane o zdarzeniach awarii w bardziej zrozumiałe podsumowania. Ponieważ te typy raportów są niedostępne na panelu Crashlytics w konsoli Firebase, mogą one uzupełniać Twoją analizę i pomóc w zrozumieniu danych o wypadkach.

Przykład 1. Błędy a dzień

Po wyeliminowaniu jak największej liczby błędów uważasz, że Twój zespół jest gotowy do uruchomienia nowej aplikacji do udostępniania zdjęć. Zanim to zrobisz, chcesz sprawdzić liczbę awarii dziennie w ciągu ostatniego miesiąca, aby upewnić się, że dzięki spotkaniu poświęconemu wyeliminowaniu błędów aplikacja jest stabilniejsza.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i wartości IOS (zamiast nazwy pakietu i wartości ANDROID).

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

Przykład 2. Znajdowanie najczęściej występujących awarii

Aby prawidłowo ustalić priorytety planów produkcyjnych, musisz znaleźć 10 najczęstszych przyczyn awarii w aplikacji. W tym celu tworzysz zapytanie, które zawiera odpowiednie punkty danych.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i wartości IOS (zamiast nazwy pakietu i wartości ANDROID).

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
  `PROJECT_ID.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 najczęściej zawieszających się urządzeń

Jesień to czas na nowe telefony. Twoja firma wie, że oznacza to również nowy sezon problemów związanych z urządzeniami, zwłaszcza z Androidem. Aby uniknąć problemów z kompatybilnością, tworzysz zapytanie, które wskazuje 10 urządzeń, które w ciągu ostatniego tygodnia (168 godzin) najczęściej ulegały awarii.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i wartości IOS (zamiast nazwy pakietu i wartości ANDROID).

SELECT
  device.model,
COUNT(DISTINCT event_id) AS number_of_crashes
FROM
  `PROJECT_ID.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

Jesteś deweloperem gier i chcesz wiedzieć, na którym poziomie gry najczęściej występują awarie.

Aby śledzić tę statystykę, możesz ustawić niestandardowy klucz Crashlytics o nazwie current_level i aktualizować go za każdym razem, gdy użytkownik osiągnie nowy poziom.

Swift

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

Objective-C

CrashlyticsKit setIntValue:3 forKey:@"current_level";

Java

Crashlytics.setInt("current_level", 3);

Gdy masz ten klucz w eksporcie do BigQuery, możesz napisać zapytanie, aby zgłosić rozkład wartości current_level powiązanych z każdym zdarzeniem awarii.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i wartości IOS (zamiast nazwy pakietu i wartości ANDROID).

SELECT
COUNT(DISTINCT event_id) AS num_of_crashes,
  value
FROM
  `PROJECT_ID.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 identyfikatora użytkownika

Masz aplikację na Androida w ramach wcześniejszego dostępu. Większość użytkowników ją uwielbia, ale u 3 z nich wystąpiła nietypowa liczba awarii. Aby dojść do sedna problemu, możesz utworzyć zapytanie, które pobiera wszystkie zdarzenia awarii dla tych użytkowników, korzystając z ich identyfikatorów.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i wartości IOS (zamiast nazwy pakietu i wartości ANDROID).

SELECT *
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  user.id IN ("USER_ID_1", "USER_ID_2", "USER_ID_3")
ORDER BY
  user.id

Przykład 6. Znajdowanie wszystkich użytkowników, którzy mają problem z określonym błędem powodującym zamykanie aplikacji

Twój zespół przypadkowo udostępnił krytyczny błąd grupie beta-testerów. Twój zespół mógł użyć zapytania z przykładu „Znajdowanie najczęściej występujących awarii” powyżej, aby zidentyfikować konkretny identyfikator problemu z awarią. Twój zespół chce teraz wykonać zapytanie, aby pobrać listę użytkowników aplikacji, których dotyczył ten błąd.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i wartości IOS (zamiast nazwy pakietu i wartości ANDROID).

SELECT user.id as user_id
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  issue_id = "ISSUE_ID"
  AND application.display_version = "APP_VERSION"
  AND user.id != ""
ORDER BY
  user.id;

Przykład 7. Liczba użytkowników, których dotyczy problem z awarią, według kraju

Podczas wdrażania nowej wersji nasz zespół wykrył błąd krytyczny. Aby znaleźć konkretny identyfikator problemu z zawieszaniem, możesz użyć zapytania z powyższego przykładu „Znajdowanie najczęściej występujących awarii”. Nasz zespół chce teraz sprawdzić, czy ten błąd występuje u użytkowników w różnych krajach na całym świecie.

Aby utworzyć to zapytanie, Twój zespół musi wykonać te czynności:

  1. Włącz eksport danych Google Analytics do usługi BigQuery. Zobacz artykuł Eksportowanie danych projektu do BigQuery.

  2. Zaktualizuj aplikację, aby przekazywać identyfikator użytkownika do obu pakietów SDK: Google Analytics i Crashlytics.

    Swift 

    Crashlytics.sharedInstance().setUserIdentifier("123456789");
Analytics.setUserID("123456789");

    Objective-C 

    CrashlyticsKit setUserIdentifier:@"123456789";
FIRAnalytics setUserID:@"12345678 9";

    Java 

    Crashlytics.setUserIdentifier("123456789");
mFirebaseAnalytics.setUserId("123456789");

  3. Napisz zapytanie, które za pomocą pola identyfikatora użytkownika złączy zdarzenia ze zbioru danych Google Analytics z awariami ze zbioru danych Crashlytics.

    Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i wartości IOS (zamiast nazwy pakietu i wartości ANDROID).

    SELECT DISTINCT c.issue_id, a.geo.country, COUNT(DISTINCT c.user.id) as num_users_impacted
FROM `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` c
INNER JOIN  `PROJECT_ID.analytics_TABLE_NAME.events_*` a on c.user.id = a.user_id
WHERE
  c.issue_id = "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 problemów do tej pory

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i wartości IOS (zamiast nazwy pakietu i wartości ANDROID).

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM
  `PROJECT_ID.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. Najważniejsze problemy od daty {DATE}, w tym dzisiaj

Możesz też połączyć tabele zbiorcze i w czasie rzeczywistym za pomocą zapytania łączącego, aby dodać informacje w czasie rzeczywistym do wiarygodnych danych zbiorczych. Ponieważ event_id jest kluczem głównym, możesz używać DISTINCT event_id do usuwania duplikatów wspólnych zdarzeń z obu tabel.

Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora pakietu i wartości IOS (zamiast nazwy pakietu i wartości ANDROID).

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM (
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID_REALTIME`
  UNION ALL
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`)
WHERE
  event_timestamp >= "YYYY_MM_DD"
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

Schemat Crashlytics w pliku BigQuery

Gdy skonfigurujesz eksport danych Crashlytics do BigQuery, Firebase będzie eksportować ostatnie zdarzenia (awarie, błędy niekrytyczne i błędy ANR), w tym zdarzenia z okresu do 2 dni przed połączeniem, z opcją uzupełniania danych z okresu do 30 dni.

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

Zbiory danych

Crashlytics tworzy w BigQuery nowy zbiór danych dla danych Crashlytics. Zbiór danych obejmuje cały projekt, nawet jeśli zawiera on wiele aplikacji.

Tabele

Crashlytics tworzy tabelę w zbiorze danych dla każdej aplikacji w Twoim projekcie, chyba że zrezygnowałeś(-aś) z eksportowania danych z tej aplikacji. Firebase nadaje nazwy tabel na podstawie identyfikatora aplikacji, przy czym kropki zastępuje podkreśleniami, a na końcu dodaje nazwę platformy.

Na przykład dane aplikacji na Androida o nazwie pakietu com.google.test będą się znajdować w tabeli o nazwie 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 wszystkie niestandardowe klucze Crashlytics zdefiniowane przez Ciebie w aplikacji.

Wiersze

Każdy wiersz w tabeli odpowiada błędowi, na który napotkała aplikacja.

Kolumny

Kolumny w tabeli są identyczne w przypadku awarii, błędów niekrytycznych i błędów ANR. Jeśli masz włączony eksport strumieniowy Crashlytics do tabeli BigQuery, tabela w czasie rzeczywistym będzie miała te same kolumny co tabela zbiorcza. Pamiętaj, że w wierszach mogą występować kolumny, które reprezentują zdarzenia bez ścieżek wywołania.

Kolumny w ramach eksportu są wymienione w tej tabeli:

Nazwa pola Typ danych Opis
platform CIĄG ZNAKÓW Platforma aplikacji zarejestrowana w projekcie Firebase (prawidłowe wartości: IOS lub ANDROID).
bundle_identifier CIĄG ZNAKÓW Unikalny identyfikator aplikacji zarejestrowany w projekcie Firebase (np. com.google.gmail).
W przypadku aplikacji na platformę Apple jest to identyfikator pakietu aplikacji.
W przypadku aplikacji na Androida jest to nazwa pakietu aplikacji.
event_id CIĄG ZNAKÓW Unikalny identyfikator zdarzenia
is_fatal WARTOŚĆ LOGICZNA czy aplikacja uległa awarii.
error_type CIĄG ZNAKÓW Typ błędu zdarzenia (np. FATAL, NON_FATAL, ANR itd.)
issue_id CIĄG ZNAKÓW Problem związany ze zdarzeniem
variant_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 Kiedy wystąpiło zdarzenie
device REKORD Urządzenie, na którym wystąpiło zdarzenie.
device.manufacturer CIĄG ZNAKÓW Producent urządzenia
device.model CIĄG ZNAKÓW Model urządzenia
device.architecture CIĄG ZNAKÓW Przykłady: X86_32, X86_64, ARMV7, ARM64, ARMV7S lub ARMV7K.
memory REKORD stan pamięci urządzenia;
memory.used INT64 Wykorzystana pamięć w bajtach
memory.free INT64 Pozostałe bajty pamięci
storage REKORD Pamięć trwała urządzenia
storage.used INT64 Zajęte miejsce w bajtach
storage.free INT64 Pozostałe bajty miejsca na dane
operating_system REKORD Szczegóły systemu operacyjnego na urządzeniu
operating_system.display_version CIĄG ZNAKÓW Wersja systemu operacyjnego na urządzeniu
operating_system.name CIĄG ZNAKÓW Nazwa systemu operacyjnego na urządzeniu.
operating_system.modification_state CIĄG ZNAKÓW Czy urządzenie zostało zmodyfikowane (na przykład aplikacja po jailbreaku to MODIFIED, a zrootowana – UNMODIFIED).
operating_system.type CIĄG ZNAKÓW (dotyczy tylko aplikacji Apple) typ systemu operacyjnego na urządzeniu (na przykład IOS, MACOS itp.).
operating_system.device_type CIĄG ZNAKÓW Typ urządzenia (na przykład MOBILE, TABLET, TV itp.); znany też jako „kategoria urządzenia”
application REKORD Aplikacja, która wygenerowała zdarzenie.
application.build_version CIĄG ZNAKÓW Wersja kompilacji aplikacji.
application.display_version CIĄG ZNAKÓW
user REKORD (Opcjonalnie) Informacje zebrane o użytkowniku aplikacji
user.name CIĄG ZNAKÓW (Opcjonalnie) Imię i nazwisko 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
custom_keys POWTARZENIE NAGRANIA Pary klucz-wartość zdefiniowane przez dewelopera
custom_keys.key CIĄG ZNAKÓW Klucz zdefiniowany przez dewelopera
custom_keys.value CIĄG ZNAKÓW Wartość zdefiniowana przez dewelopera
installation_uuid CIĄG ZNAKÓW Identyfikator, który identyfikuje 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 Przykłady: PORTRAIT, LANDSCAPE, FACE_UP, FACE_DOWN itp.
device_orientation CIĄG ZNAKÓW Przykłady: PORTRAIT, LANDSCAPE, FACE_UP, FACE_DOWN itp.
process_state CIĄG ZNAKÓW BACKGROUND lub FOREGROUND
logs POWTARZENIE NAGRANIA Komunikaty dziennika z sygnaturą czasową wygenerowane przez rejestrator Crashlytics, jeśli jest włączony
logs.timestamp SYGNATURA CZASOWA Czas utworzenia dziennika.
logs.message CIĄG ZNAKÓW Zalogowana wiadomość
breadcrumbs POWTARZENIE NAGRANIA menu nawigacyjne Google Analytics z dodatkiem sygnatury czasowej, jeśli jest włączone
breadcrumbs.timestamp SYGNATURA CZASOWA Sygnatura czasowa powiązana z ścieżką nawigacyjną
breadcrumbs.name CIĄG ZNAKÓW Nazwa powiązana z śladami
breadcrumbs.params POWTARZENIE NAGRANIA Parametry powiązane z listą poziomą
breadcrumbs.params.key CIĄG ZNAKÓW Klucz parametru powiązany z listą poziomą
breadcrumbs.params.value CIĄG ZNAKÓW wartość parametru powiązana z menu nawigacyjnym.
blame_frame REKORD Ramka zidentyfikowana jako główna przyczyna awarii lub błędu
blame_frame.line INT64 Numer wiersza pliku ramki.
blame_frame.file CIĄG ZNAKÓW Nazwa pliku ramki.
blame_frame.symbol CIĄG ZNAKÓW Symbol nawodnienia lub symbol surowego produktu, jeśli nie można go nawilżyć
blame_frame.offset INT64 Przesunięcie bajtów w obrazie binarnym zawierającym kod
Nie ustawione w przypadku wyjątków w języku Java
blame_frame.address INT64 Adres w pliku binarnym, który zawiera kod
Nie ustawiaj w przypadku ramek Java
blame_frame.library CIĄG ZNAKÓW Wyświetlana nazwa biblioteki zawierającej ramkę
blame_frame.owner CIĄG ZNAKÓW Przykłady: DEVELOPER, VENDOR, RUNTIME, PLATFORM lub SYSTEM
blame_frame.blamed WARTOŚĆ LOGICZNA Czy Crashlytics stwierdziło, że ten kadr jest przyczyną awarii lub błędu
exceptions POWTARZENIE NAGRANIA (tylko Android) Wyjątki, które wystąpiły podczas tego zdarzenia. Wyjątki zagnieżdżone są wyświetlane w odwrotnej kolejności chronologicznej, co oznacza, że ostatni rekord jest pierwszym wyjątkiem.
exceptions.type CIĄG ZNAKÓW Typ wyjątku (np. java.lang.IllegalStateException)
exceptions.exception_message CIĄG ZNAKÓW komunikat związany z wyjątkiem,
exceptions.nested WARTOŚĆ LOGICZNA Prawda we wszystkich przypadkach oprócz ostatniego wyjątku (czyli pierwszego rekordu).
exceptions.title CIĄG ZNAKÓW Tytuł wątku
exceptions.subtitle CIĄG ZNAKÓW Podtytuł wątku
exceptions.blamed WARTOŚĆ LOGICZNA Prawda, jeśli Crashlytics określa, że wyjątek jest odpowiedzialny za błąd lub awarię.
exceptions.frames POWTARZENIE NAGRANIA Ramki powiązane z wyjątkiem
exceptions.frames.line INT64 Numer wiersza pliku ramki.
exceptions.frames.file CIĄG ZNAKÓW Nazwa pliku ramki.
exceptions.frames.symbol CIĄG ZNAKÓW Symbol nawodnienia lub symbol surowego produktu, jeśli nie można go nawilżyć
exceptions.frames.offset INT64 Przesunięcie bajtów w obrazie binarnym zawierającym kod
Nie ustawione w przypadku wyjątków w języku Java
exceptions.frames.address INT64 Adres w pliku binarnym, który zawiera kod
Nie ustawiaj w przypadku ramek Java
exceptions.frames.library CIĄG ZNAKÓW Wyświetlana nazwa biblioteki zawierającej ramkę
exceptions.frames.owner CIĄG ZNAKÓW Przykłady: DEVELOPER, VENDOR, RUNTIME, PLATFORM lub SYSTEM
exceptions.frames.blamed WARTOŚĆ LOGICZNA Czy Crashlytics stwierdziło, że ten kadr jest przyczyną awarii lub błędu
error POWTARZENIE NAGRANIA (dotyczy tylko aplikacji Apple) błędy niekrytyczne
error.queue_name CIĄG ZNAKÓW kolejka, w której był uruchamiany wątek;
error.code INT64 Kod błędu powiązany z niestandardowym odnotowanym przez aplikację błędem NSError.
error.title CIĄG ZNAKÓW Tytuł wątku
error.subtitle CIĄG ZNAKÓW Podtytuł wątku
error.blamed WARTOŚĆ LOGICZNA Czy Crashlytics stwierdziło, że ten kadr jest przyczyną błędu
error.frames POWTARZENIE NAGRANIA Ramki ścieżki wywołania
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 surowego produktu, jeśli nie można go nawilżyć
error.frames.offset INT64 przesunięcie bajtów w pliku binarnym zawierającym kod,
error.frames.address INT64 Adres w pliku binarnym zawierającym kod
error.frames.library CIĄG ZNAKÓW Wyświetlana nazwa biblioteki zawierającej ramkę
error.frames.owner CIĄG ZNAKÓW Przykłady: DEVELOPER, VENDOR, RUNTIME, PLATFORM lub SYSTEM
error.frames.blamed WARTOŚĆ LOGICZNA Czy Crashlytics stwierdziło, że ten kadr jest przyczyną błędu
threads POWTARZENIE NAGRANIA wątki obecne w momencie zdarzenia,
threads.crashed WARTOŚĆ LOGICZNA czy wątek uległ awarii.
threads.thread_name CIĄG ZNAKÓW nazwę wątku,
threads.queue_name CIĄG ZNAKÓW (dotyczy tylko aplikacji 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ępuje tylko w przypadku wątków natywnych, które uległy awarii.
threads.signal_code CIĄG ZNAKÓW Kod sygnału, który spowodował awarię aplikacji; występuje tylko w wątkach natywnych, które uległy awarii
threads.crash_address INT64 Adres sygnału, który spowodował awarię aplikacji; występuje tylko w wątkach natywnych, które uległy awarii
threads.code INT64 (dotyczy tylko aplikacji Apple) kod błędu zarejestrowany przez niestandardowy log aplikacji NSError.
threads.title CIĄG ZNAKÓW Tytuł wątku
threads.subtitle CIĄG ZNAKÓW Podtytuł wątku
threads.blamed WARTOŚĆ LOGICZNA Czy Crashlytics stwierdziło, że ten kadr jest przyczyną awarii lub błędu
threads.frames POWTARZENIE NAGRANIA 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 surowego produktu, jeśli nie można go nawodnić.
threads.frames.offset INT64 przesunięcie bajtów w pliku binarnym zawierającym kod,
threads.frames.address INT64 Adres w pliku binarnym zawierającym kod
threads.frames.library CIĄG ZNAKÓW Wyświetlana nazwa biblioteki zawierającej ramkę
threads.frames.owner CIĄG ZNAKÓW Przykłady: DEVELOPER, VENDOR, RUNTIME, PLATFORM lub SYSTEM
threads.frames.blamed WARTOŚĆ LOGICZNA Czy Crashlytics stwierdziło, że ten kadr jest przyczyną błędu
unity_metadata.unity_version CIĄG ZNAKÓW Wersja Unity uruchomiona na tym urządzeniu
unity_metadata.debug_build WARTOŚĆ LOGICZNA Jeśli jest to wersja debugowania
unity_metadata.processor_type CIĄG ZNAKÓW Typ procesora
unity_metadata.processor_count INT64 Liczba procesorów (rdzeni)
unity_metadata.processor_frequency_mhz INT64 Częstotliwość procesora(procesorów) w MHz
unity_metadata.system_memory_size_mb INT64 Rozmiar pamięci systemu w MB
unity_metadata.graphics_memory_size_mb INT64 Pamięć graficzna w MB
unity_metadata.graphics_device_id INT64 Identyfikator urządzenia graficznego
unity_metadata.graphics_device_vendor_id INT64 Identyfikator dostawcy procesora graficznego
unity_metadata.graphics_device_name CIĄG ZNAKÓW Nazwa urządzenia graficznego
unity_metadata.graphics_device_vendor CIĄG ZNAKÓW Dostawca urządzenia graficznego
unity_metadata.graphics_device_version CIĄG ZNAKÓW Wersja urządzenia graficznego
unity_metadata.graphics_device_type CIĄG ZNAKÓW Typ urządzenia graficznego
unity_metadata.graphics_shader_level INT64 Poziom shadera grafiki
unity_metadata.graphics_render_target_count INT64 Liczba celów renderowania graficznego
unity_metadata.graphics_copy_texture_support CIĄG ZNAKÓW Obsługa kopiowania tekstury graficznej zgodnie z definicją w interfejsie Unity API
unity_metadata.graphics_max_texture_size INT64 Maksymalny rozmiar przeznaczony do renderowania tekstury
unity_metadata.screen_size_px CIĄG ZNAKÓW Rozmiar ekranu w pikselach w formacie szerokość x wysokość
unity_metadata.screen_resolution_dpi CIĄG ZNAKÓW Gęstość ekranu (DPI) jako liczba zmiennoprzecinkowa.
unity_metadata.screen_refresh_rate_hz INT64 Częstotliwość odświeżania ekranu w Hz

Wizualizacja wyeksportowanych danych Crashlytics w Studiu danych

Studio danych Google przekształca Twoje zbiory danych Crashlytics w BigQuery w raporty, które są łatwiejsze do odczytania i udostępnienia oraz w pełni konfigurowalne.

Aby dowiedzieć się więcej o korzystaniu ze Studia danych, zapoznaj się z poradnikiem Witamy w Studiu danych.

Używanie szablonu raportu Crashlytics

W Data Studio znajdziesz przykładowy raport Crashlytics, który zawiera obszerny zbiór wymiarów i danych z wyeksportowanego schematu Crashlytics BigQuery. Jeśli masz włączone Crashlytics eksportowanie danych strumieniowych BigQuery, możesz wyświetlić te dane na stronie Trendy w czasie rzeczywistym w szablonie Studia danych.Możesz użyć tego szablonu, aby szybko tworzyć nowe raporty i wizualizacje na podstawie nieprzetworzonych danych o awariach z Twojej aplikacji:

  1. Otwórz szablon Crashlytics panelu Studia danych.

  2. W prawym górnym rogu kliknij Użyj szablonu.

  3. W menu Nowe źródło danych kliknij Utwórz nowe źródło danych.

  4. Na karcie BigQuery kliknij Wybierz.

  5. Wybierz tabelę zawierającą wyeksportowane dane Crashlytics, klikając Moje projekty > PROJECT_ID > firebase_crashlytics > TABLE_NAME.

    Tabela zbiorcza jest zawsze dostępna do wyboru. Jeśli masz włączony eksport strumieniowy Crashlytics do tabeli BigQuery, możesz zamiast tego wybrać tabelę z danymi w czasie rzeczywistym.

  6. W sekcji Konfiguracja ustaw Crashlytics Poziom szablonu na Domyślny.

  7. Aby utworzyć nowe źródło danych, kliknij Połącz.

  8. Aby wrócić do szablonu Crashlytics, kliknij Dodaj do raportu.

  9. Na koniec kliknij Utwórz raport, aby utworzyć kopię szablonu Crashlytics panelu Studia danych.

.

Przejście na nową infrastrukturę eksportu

W połowie października 2024 r. Crashlytics wdrożył nową infrastrukturę do eksportowania danych Crashlytics do usługi BigQuery. Na razie przejście na tę nową infrastrukturę jest opcjonalne.

Ta nowa infrastruktura obsługuje Crashlytics lokalizacje zbiorów danych poza Stanami Zjednoczonymi.

Kolejną różnicą w nowej infrastrukturze jest to, że nie obsługuje ona uzupełniania danych z okresu poprzedzającego włączenie eksportu. (w przypadku starej infrastruktury można było uzupełnić dane do 30 dni przed datą włączenia). Nowa infrastruktura obsługuje uzupełnianie danych z ostatnich 30 dni lub z ostatniego dnia, w którym włączono eksport do BigQuery (w zależności od tego, co jest najnowsze).

Warunek wstępny przejścia na wyższą wersję

Zanim przejdziesz na nową infrastrukturę, sprawdź, czy spełniasz ten wymóg wstępny: tabele bieżących zbiorczych BigQuery mają identyfikatory pasujące do identyfikatorów pakietów lub nazw pakietów ustawionych dla zarejestrowanych aplikacji Firebase.

Przykład:

  • Jeśli masz tabelę BigQuery o nazwie com_yourcompany_yourproject_IOS, w Twoim projekcie Firebase musi być zarejestrowana aplikacja Firebase na iOS+ z identyfikatorem pakietu com.yourcompany.yourproject.

  • Jeśli masz tabelę BigQuery o nazwie com_yourcompany_yourproject_ANDROID, w Twoim projekcie Firebase musi być zarejestrowana aplikacja Firebase na Androida o nazwie pakietu com.yourcompany.yourproject.

Aby znaleźć wszystkie aplikacje Firebase zarejestrowane w Twoim projekcie Firebase:

  1. W konsoli Firebase otwórz Ustawienia projektu.

  2. Przewiń w dół do karty Twoje aplikacje, a potem kliknij wybraną aplikację Firebase, aby wyświetlić informacje o niej, w tym jej identyfikator.

Nowa infrastruktura eksportu będzie eksportować dane każdej aplikacji na podstawie nazwy pakietu lub identyfikatora zestawu ustawionego dla zarejestrowanej aplikacji Firebase. Aby nie zakłócać BigQuery przepływu pracy, upewnij się, że bieżące tabele zbiorczych mają już prawidłowe nazwy, aby nowa infrastruktura mogła dodawać wszystkie nowe dane do istniejących tabel. Jeśli masz nazwy tabel partii, które nie zgadzają się z zarejestrowanymi aplikacjami Firebase, ale nadal chcesz przejść na nową usługę, skontaktuj się z zespołem pomocy Firebase.

Jak przejść na nową infrastrukturę

Jeśli eksport jest już włączony, możesz przejść na nową infrastrukturę, po prostu wyłączając, a następnie włączając eksport danych w konsoli Crashlytics.Firebase

Oto szczegółowe instrukcje:

  1. W konsoli Firebase otwórz stronę Integracje.

  2. Na karcie BigQuery kliknij Zarządzaj.

  3. Aby wyłączyć eksportowanie, wyłącz suwak Crashlytics. Gdy pojawi się odpowiedni komunikat, potwierdź, że chcesz zatrzymać eksport danych.

  4. Od razu włącz suwak Crashlytics, aby ponownie włączyć eksportowanie. Gdy pojawi się odpowiedni komunikat, potwierdź, że chcesz wyeksportować dane.

    eksport danych z Crashlytics do BigQuery jest teraz realizowany za pomocą nowej infrastruktury eksportu.