Dane Firebase Crashlytics możesz wyeksportować do pliku BigQuery, aby przeanalizować je dokładniej. BigQuery umożliwia analizowanie danych za pomocą BigQuery SQL, wyeksportuj go do innego dostawcy chmury i użyj wizualizacji i paneli niestandardowych w Studiu danych Google.
Włącz eksport do usługi BigQuery
- W konsoli Firebase wybierz Integracje.
- Na karcie BigQuery kliknij Połącz.
- Postępuj zgodnie z instrukcjami wyświetlanymi na ekranie, aby włączyć eksportowanie danych do usługi BigQuery.
Gdy włączysz eksportowanie do BigQuery:
Domyślnie wszystkie aplikacje w projekcie są połączone z BigQuery oraz dowolnymi aplikacje, które dodasz później do projektu, zostaną automatycznie połączone BigQuery Możesz określić, które aplikacje mają wysyłać dane.
Firebase konfiguruje codzienne synchronizacje danych z projektu Firebase w BigQuery
Firebase wyeksportuje kopię Twoich dotychczasowych danych do usługi BigQuery. W przypadku każdej połączonej aplikacji obejmuje to tabelę zbiorczą. który zawiera dane z codziennej synchronizacji.
Jeśli włącz eksport strumieniowy z aplikacji Crashlytics do BigQuery, wszystkie połączone aplikacje będą też miały tabelę czasu rzeczywistego, która zawiera stale aktualizowane i skalowalnych danych.
Aby dezaktywować eksport do usługi BigQuery, odłącz projekt w konsoli Firebase.
Jakie dane są eksportowane do usługi BigQuery?
Dane usługi Firebase Crashlytics są eksportowane do zbioru danych BigQuery o nazwie
firebase_crashlytics
Domyślnie poszczególne tabele będą tworzone wewnątrz
zbiór danych Crashlytics dla każdej aplikacji w Twoim projekcie. Firebase nadaje nazwę
na podstawie identyfikatora aplikacji, z kropkami konwertowanymi na podkreślenia,
z nazwą platformy dodaną na końcu.
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
BigQuery, a następnie dane z Crashlytics również będą przesyłane strumieniowo 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, w tym oraz błędów niekrytycznych i błędów ANR.
Eksport strumieniowy Crashlytics do BigQuery
Dane Crashlytics możesz przesyłać strumieniowo w czasie rzeczywistym za pomocą BigQuery. Można ich używać do dowolnych celów, które wymagają danych na żywo, takich jak prezentowanie w panelu transmisji na żywo, obserwować wdrożenia na żywo lub monitorować je problemy z aplikacją, które aktywują alerty i niestandardowe przepływy pracy.
Gdy włączysz eksport strumieniowy Crashlytics do BigQuery, oprócz tabeli wsadowej masz też tabelę czasu rzeczywistego. Oto różnice między tymi tabelami, o których warto pamiętać:
Tabela zbiorcza | Tabela Czas rzeczywisty |
---|---|
|
|
Tabela wsadowa jest idealna do długoterminowej analizy i identyfikowania trendów w czasie. bo przechowujemy zdarzenia przed ich napisaniem i można je uzupełniać z perspektywy maksymalnie 30 dni. Przy zapisie danych w tabeli czasu rzeczywistego od razu zapisać go w aplikacji BigQuery. Dzięki temu idealnie nadaje się do transmisji na żywo. z paneli informacyjnych i alertów niestandardowych. Te 2 tabele mogą być połączone z zapytaniem łączenia, aby uzyskać korzyści obu rodzajów.
Domyślnie tabela czasu rzeczywistego ma okres ważności partycji wynoszący 30 dni. Do dowiedzieć się, jak to zmienić, zobacz Ustawianie daty wygaśnięcia partycji w dokumentacji BigQuery.
Włącz eksport strumieniowy Crashlytics do usługi BigQuery
- W konsoli Firebase wybierz Integracje.
- Na karcie BigQuery kliknij Zarządzaj.
- Zaznacz pole wyboru Uwzględnij strumieniowanie.
To działanie umożliwia strumieniowanie w przypadku wszystkich połączonych aplikacji.
Co można zrobić z wyeksportowanymi danymi?
Eksporty do BigQuery zawierają nieprzetworzone dane o awariach, w tym o typie urządzenia, systemu operacyjnego, wyjątków (aplikacje na Androida) lub błędów (aplikacje Apple), Crashlytics oraz inne dane.
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 użytkownika BigQuery. Szczegółowe instrukcje znajdziesz w materiałach na temat Utwórz widoki w BigQuery.
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ż nie są dostępne tego typu raporty w panelu Crashlytics w konsoli Firebase mogą uzupełniać analizy i interpretacji danych dotyczących awarii.
Przykład 1: awarie według dnia
Po naprawieniu jak największej liczby błędów uważasz, że Twój zespół wreszcie możesz uruchomić nową aplikację do udostępniania zdjęć. Zanim to zrobisz, sprawdź liczby awarii dziennie w zeszłym miesiącu, aby mieć pewność, że poprawki błędów jest bardziej stabilna w miarę upływu czasu.
Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora jej pakietu
i IOS
(zamiast nazwy pakietu i 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. Znalezienie najczęstszych awarii
Aby ustalić priorytety planów produkcji, znajdź 10 najlepszych powszechnych awarii w aplikacji. Tworzysz zapytanie, w którym punktów danych.
Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora jej pakietu
i IOS
(zamiast nazwy pakietu i 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 urządzeń, na których najczęściej występują awarie
Jesień to nowy sezon telefonów! 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 ze zgodnością, które mogą się pojawić w przyszłości, tworzysz zapytanie, które wskazuje 10 urządzeń, które w ostatnim tygodniu (168 godzin) najczęściej ulegały awarii.
Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora jej pakietu
i IOS
(zamiast nazwy pakietu i 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 ułatwić śledzenie tych statystyk, ustaw
niestandardowy klucz Crashlytics
o nazwie current_level
i aktualizuj ją 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);
Mając ten klucz w eksporcie do usługi BigQuery, możesz napisać zapytanie do
zgłoś rozkład wartości current_level
powiązanych z każdą awarią
.
Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora jej pakietu
i IOS
(zamiast nazwy pakietu i 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 identyfikatorów użytkownika
Masz aplikację na Androida w programie wcześniejszego dostępu. Większość użytkowników je uwielbia, ale dla trzech ma miejsce nadzwyczajna liczba awarii. Aby przejść do dołu piszesz zapytanie, które pobiera wszystkie zdarzenia awarii tych użytkowników za pomocą identyfikatorów użytkownikó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ł grupie beta-testerów błąd krytyczny. Twój zespół mógł użyć zapytania z „Wykrywaj najpowszechniejsze awarie” przykład powyżej, aby zidentyfikować konkretny identyfikator problemu powodującego awarię. Twój zespół chce przeprowadzić w celu wyodrębnienia listy użytkowników aplikacji, których dotyczy ta awaria.
Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora jej pakietu
i IOS
(zamiast nazwy pakietu i 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 awaria, z podziałem na kraje
Twój zespół wykrył błąd krytyczny podczas wdrażania nowej wersji. Ty mogli użyć zapytania z „Wykrywaj najpowszechniejsze awarie” przykład powyżej, aby zidentyfikować konkretny identyfikator problemu powodującego awarię. Zespół chciałby teraz zobaczyć, czy ta awaria dotarła do użytkowników w różnych krajach na całym świecie.
Aby utworzyć to zapytanie, Twój zespół musi wykonać te czynności:
Włącz eksportowanie danych z usługi Google Analytics do usługi BigQuery. Zobacz Eksportowanie danych projektu do BigQuery.
Zaktualizuj aplikację, aby przekazywać identyfikator użytkownika do pakietu SDK Google Analytics oraz pakiet SDK 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");
Utwórz zapytanie, które korzysta z pola User-ID, aby łączyć zdarzenia w Zbiór danych Google Analytics z awariami w zbiorze danych Crashlytics.
Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj jej identyfikator pakietu i
IOS
(zamiast nazwy pakietu iANDROID
).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 do tej pory tematów na dziś
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 wsadowe i w czasie rzeczywistym za pomocą zapytania o łączenie, aby dodać
w czasie rzeczywistym do niezawodnych danych wsadowych. Ponieważ event_id
jest głównym elementem
za pomocą DISTINCT event_id
możesz usunąć z nich dowolne typowe zdarzenia
tabeli.
Oto przykładowe zapytanie dotyczące aplikacji na Androida. W przypadku aplikacji na iOS użyj identyfikatora jej pakietu
i IOS
(zamiast nazwy pakietu i 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 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 Firebase będzie eksportować dane, dopóki nie wyłączysz eksportu Crashlytics zdarzeń dziennie. Zbieranie danych może zająć kilka minut dostępne w BigQuery po każdym eksporcie.
Zbiory danych
Crashlytics tworzy nowy zbiór danych w BigQuery dla użytkowniczki Crashlytics i skalowalnych danych. Zbiór danych obejmuje cały projekt, nawet jeśli zawiera on wiele aplikacji.
Tabele
Crashlytics tworzy w zbiorze danych tabelę dla każdej aplikacji w projekcie, chyba że zrezygnujesz z eksportowania danych z tej aplikacji. Firebase nadaje nazwę na podstawie identyfikatora aplikacji, z kropkami konwertowanymi na podkreślenia, z nazwą platformy dodaną na końcu.
Na przykład dane dla aplikacji na Androida o nazwie pakietu com.google.test
znajdą się w tabeli o nazwie com_google_test_ANDROID
, a dane w czasie rzeczywistym
(jeśli jest włączona) znajduje się w tabeli o nazwie com_google_test_ANDROID_REALTIME
Tabele zawierają standardowy zestaw danych Crashlytics, a także wszelkie inne niestandardowe klucze Crashlytics określone przez Ciebie w aplikacji.
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 Crashlytics do usługi BigQuery, a następnie tabela czasu rzeczywistego będzie zawierać te same kolumny co tabela zbiorcza. Pamiętaj, że możesz mają kolumny w wierszach reprezentujące zdarzenia, które nie mają zrzutów stosu.
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 zarejestrowanej w projekcie Firebase.
(na przykład com.google.gmail W przypadku aplikacji platformy Apple jest to identyfikator pakietu aplikacji. W przypadku aplikacji na Androida jest to nazwa pakietu aplikacji. |
event_id |
CIĄG ZNAKÓW | Unikalny identyfikator wydarzenia. |
is_fatal |
WARTOŚĆ LOGICZNA | czy aplikacja uległa awarii. |
error_type |
CIĄG ZNAKÓW | Typ błędu zdarzenia (np. FATAL ,
NON_FATAL , ANR itp.) |
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 | czas wystąpienia zdarzenia; |
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 | Wykorzystane bajty pamięci |
memory.free |
INT64 | Pozostałe bajty pamięci |
storage |
REKORD | Pamięć trwała urządzenia |
storage.used |
INT64 | Zajęte bajty miejsca na dane |
storage.free |
INT64 | Wolne 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 urządzenia. |
operating_system.name |
CIĄG ZNAKÓW | Nazwa systemu operacyjnego na urządzeniu |
operating_system.modification_state |
CIĄG ZNAKÓW | Określa, czy urządzenie zostało zmodyfikowane
(np. aplikacja po jailbreaku to MODIFIED , a aplikacja z dostępem do roota
UNMODIFIED ). |
operating_system.type |
CIĄG ZNAKÓW | (Tylko aplikacje Apple) Typ systemu operacyjnego działającego na urządzeniu (np.
IOS , MACOS itp.) |
operating_system.device_type |
CIĄG ZNAKÓW | Typ urządzenia (np. MOBILE , TABLET ,
TV itp.); zwany także „kategorią 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) Zebrane informacje 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. |
custom_keys |
POWTÓRZONY REKORD | Pary klucz-wartość zdefiniowane przez programistę |
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 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 | Na przykład: PORTRAIT , LANDSCAPE .
FACE_UP , FACE_DOWN itp. |
device_orientation |
CIĄG ZNAKÓW | Na przykład: PORTRAIT , LANDSCAPE .
FACE_UP , FACE_DOWN itp. |
process_state |
CIĄG ZNAKÓW | BACKGROUND lub FOREGROUND |
logs |
POWTARZENIE NAGRANIA | wiadomości logu oznaczone sygnaturą czasową wygenerowane przez rejestrator Crashlytics, jeśli włączono |
logs.timestamp |
SYGNATURA CZASOWA | data utworzenia dziennika, |
logs.message |
CIĄG ZNAKÓW | Zalogowana wiadomość |
breadcrumbs |
POWTÓRZONY REKORD | menu nawigacyjnego z Google Analytics sygnaturami czasowymi, 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 menu nawigacyjnym |
breadcrumbs.params |
POWTÓRZONY REKORD | Parametry powiązane z menu nawigacyjnym |
breadcrumbs.params.key |
CIĄG ZNAKÓW | Klucz parametru powiązany z menu nawigacyjnym |
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 surowej wody, jeśli nie jest nawodniony; |
blame_frame.offset |
INT64 | Wartość przesunięcia bajtów na obraz binarny zawierający kod Nieskonfigurowane dla wyjątków Javy |
blame_frame.address |
INT64 | Adres w obrazie binarnym, który zawiera kod Usuń ustawienie dla ramek Java |
blame_frame.library |
CIĄG ZNAKÓW | Wyświetlana nazwa biblioteki zawierającej ramkę |
blame_frame.owner |
CIĄG ZNAKÓW | Na przykład: 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 |
POWTÓRZONY REKORD | (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
(na przykład java.lang.IllegalStateException) |
exceptions.exception_message |
CIĄG ZNAKÓW | Komunikat powiązany z wyjątkiem |
exceptions.nested |
WARTOŚĆ LOGICZNA | Prawda dla wszystkich oprócz ostatniego odrzuconego 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 ustali, że wyjątek jest odpowiedzialny za błąd lub awaria |
exceptions.frames |
POWTÓRZONY REKORD | Klatki 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 surowej wody, jeśli nie jest nawodniony; |
exceptions.frames.offset |
INT64 | Wartość przesunięcia bajtów na obraz binarny zawierający kod Nieskonfigurowane dla wyjątków Javy |
exceptions.frames.address |
INT64 | Adres w obrazie binarnym, który zawiera kod Usuń ustawienie dla ramek Java |
exceptions.frames.library |
CIĄG ZNAKÓW | Wyświetlana nazwa biblioteki zawierającej ramkę |
exceptions.frames.owner |
CIĄG ZNAKÓW | Na przykład: 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 |
POWTÓRZONY REKORD | (dotyczy tylko aplikacji Apple) błędy niekrytyczne |
error.queue_name |
CIĄG ZNAKÓW | Kolejka, w której działał wątek |
error.code |
INT64 | Kod błędu powiązany z niestandardowym zapisanym błędem NSError aplikacji |
error.title |
CIĄG ZNAKÓW | Tytuł wątku |
error.subtitle |
CIĄG ZNAKÓW | Podtytuł wątku |
error.blamed |
WARTOŚĆ LOGICZNA | Określa, czy Crashlytics ustalił, że ta ramka jest przyczyną błąd |
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 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 | Na przykład: DEVELOPER , VENDOR .
RUNTIME , PLATFORM lub SYSTEM |
error.frames.blamed |
WARTOŚĆ LOGICZNA | Określa, czy Crashlytics ustalił, że ta ramka jest przyczyną błąd |
threads |
POWTARZENIE NAGRANIA | Wątki obecne w momencie wydarzenia |
threads.crashed |
WARTOŚĆ LOGICZNA | Czy wątek uległ awarii |
threads.thread_name |
CIĄG ZNAKÓW | Nazwa 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; tylko obecne w przypadku awarii wątków natywnych |
threads.code |
INT64 | (Tylko aplikacje Apple) Kod błędu niestandardowego dziennika aplikacji Błąd NS |
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 |
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 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 | Na przykład: DEVELOPER , VENDOR .
RUNTIME , PLATFORM lub SYSTEM |
threads.frames.blamed |
WARTOŚĆ LOGICZNA | Określa, czy Crashlytics ustalił, że ta ramka jest przyczyną błąd |
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ść 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ęć karty graficznej 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 karty graficznej. |
unity_metadata.graphics_device_type |
CIĄG ZNAKÓW | Typ urządzenia graficznego |
unity_metadata.graphics_shader_level |
INT64 | Poziom cieniowania 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 grafiki zgodnie z definicją w Interfejs API Unity |
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 podany jako szerokość x wysokość. |
unity_metadata.screen_resolution_dpi |
CIĄG ZNAKÓW | Wartość DPI ekranu w postaci liczby zmiennoprzecinkowej. |
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 Crashlytics zbiorów danych w usłudze BigQuery w raporty, które łatwiej jest do czytania, udostępniania i dostosowywania do własnych potrzeb.
Więcej informacji o korzystaniu ze Studia danych znajdziesz w krótkim przewodniku po Studiu danych: Witamy w Studiu danych
Użyj szablonu raportu Crashlytics
Studio danych zawiera przykładowy raport dotyczący kategorii Crashlytics, który zawiera kompleksowy zestaw wymiarów i danych z wyeksportowanych Crashlytics Schemat BigQuery. Jeśli masz włączone eksportowanie danych Crashlytics w formie strumienia do BigQuery, możesz wyświetlać 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:
Otwórz szablon Crashlytics panelu Studia danych.
Kliknij Użyj szablonu w prawym górnym rogu.
W menu Nowe źródło danych wybierz Utwórz nowe źródło danych.
Na karcie BigQuery kliknij Wybierz.
Wybierz tabelę zawierającą wyeksportowane dane Crashlytics Moje projekty > PROJECT_ID > firebase_crashlytics > TABLE_NAME.
Tabela wsadowa jest zawsze dostępna do wyboru. Jeśli włączony jest eksport strumieniowy Crashlytics do usługi BigQuery, a następnie możesz zamiast tego wybrać tabelę w czasie rzeczywistym.
W obszarze Konfiguracja ustaw opcję Poziom szablonu Crashlytics na Domyślny.
Kliknij Połącz, aby utworzyć nowe źródło danych.
Kliknij Dodaj do raportu, aby powrócić do szablonu Crashlytics.
Na koniec kliknij Utwórz raport, aby utworzyć kopię raportu Crashlytics. Szablon panelu Studia danych.