Sie können Ihre Firebase Crashlytics-Daten zur weiteren Analyse in BigQuery exportieren. Mit BigQuery können Sie die Daten mit BigQuery SQL analysieren, in einen anderen Cloud-Anbieter exportieren und für Visualisierungen und benutzerdefinierte Dashboards mit Google Data Studio verwenden.
Export in BigQuery aktivieren
Rufen Sie in der Firebase Console die Seite Integrationen auf.
Klicken Sie auf der Karte BigQuery auf Verknüpfen.
Folgen Sie der Anleitung auf dem Bildschirm, um den Export in BigQuery zu aktivieren.
Wenn Sie nahezu in Echtzeit auf Ihre Crashlytics-Daten in BigQuery zugreifen möchten, sollten Sie auf den Streaming-Export umstellen.
Was passiert, wenn ich die Funktion „Exportieren“ aktiviere?
Sie wählen den Speicherort des Datensatzes aus. Nachdem das Dataset erstellt wurde, kann der Speicherort nicht mehr geändert werden. Sie können das Dataset aber an einen anderen Speicherort kopieren oder es manuell verschieben, d. h. an einem anderen Speicherort neu erstellen. Weitere Informationen finden Sie unter Speicherort für vorhandene Exporte ändern.
Dieser Speicherort gilt nur für die Daten, die in BigQuery exportiert werden. Er hat keine Auswirkungen auf den Speicherort der Daten, die für die Verwendung im Crashlytics-Dashboard der Firebase-Konsole oder in Android Studio gespeichert werden.
Standardmäßig werden alle Apps in Ihrem Projekt mit BigQuery verknüpft. Alle Apps, die Sie dem Projekt später hinzufügen, werden ebenfalls automatisch mit BigQuery verknüpft. Sie können festlegen, welche Apps Daten senden.
Firebase richtet eine tägliche Synchronisierung Ihrer Daten mit BigQuery ein.
Nachdem Sie Ihr Projekt verknüpft haben, müssen Sie in der Regel bis zur Synchronisierung am nächsten Tag warten, bis die ersten Daten nach BigQuery exportiert werden.
Die tägliche Synchronisierung erfolgt einmal pro Tag, unabhängig von geplanten Exporten, die Sie unter BigQuery eingerichtet haben. Beachten Sie, dass sich Zeitpunkt und Dauer des Synchronisierungsjobs ändern können. Wir empfehlen daher nicht, Downstream-Vorgänge oder ‑Jobs basierend auf einem bestimmten Zeitpunkt des Exports zu planen.
Firebase exportiert eine Kopie Ihrer vorhandenen Daten zu BigQuery. Die Erstübertragung der Daten für den Export kann bis zu 48 Stunden dauern.
Dieser Export enthält für jede verknüpfte App eine Batchtabelle mit den Daten aus der täglichen Synchronisierung.
Sie können Daten-Backfills für die Batchtabelle bis zu den letzten 30 Tagen manuell planen oder für das Datum, an dem Sie den Export nach BigQuery aktiviert haben (je nachdem, was jünger ist).
Wenn Sie den Export von Crashlytics-Daten vor Mitte Oktober 2024 aktiviert haben, können Sie auch 30 Tage vor dem Tag, an dem Sie den Export aktiviert haben, ein Backfill durchführen.
Wenn Sie den Streamingexport von Crashlytics nach BigQuery aktivieren, haben alle verknüpften Apps auch eine Echtzeittabelle mit ständig aktualisierten Daten.
Wenn Sie den Export in BigQuery deaktivieren möchten, entkoppeln Sie Ihr Projekt in der Firebase-Konsole.
Welche Daten werden nach BigQuery exportiert?
Firebase Crashlytics-Daten werden in ein BigQuery-Dataset namens firebase_crashlytics
exportiert. Standardmäßig werden im Crashlytics-Dataset für jede App in Ihrem Projekt einzelne Tabellen erstellt. Die Tabellen werden in Firebase nach der ID der Anwendung benannt. Die in der ID enthaltenen Punkte werden in Unterstriche umgewandelt und am Ende wird der Plattformname angehängt.
Daten für eine Android-App mit dem Paketnamen com.google.test
würden beispielsweise in einer Tabelle mit dem Namen com_google_test_ANDROID
gespeichert. Diese Batch-Tabelle wird einmal täglich aktualisiert. Wenn Sie den Streaming-Export von Crashlytics nach BigQuery aktivieren, werden Crashlytics-Daten auch in Echtzeit in eine Tabelle mit dem Namen com_google_test_ANDROID_REALTIME
gestreamt.
Jede Zeile in einer Tabelle steht für ein Ereignis, das in der App aufgetreten ist, einschließlich Abstürzen, nicht schwerwiegenden Fehlern und ANRs.
Crashlytics-Streaming-Export nach BigQuery
Mit BigQuery-Streaming können Sie Ihre Crashlytics-Daten in Echtzeit streamen. Sie können sie für alle Zwecke verwenden, für die Live-Daten erforderlich sind, z. B. zur Präsentation von Informationen in einem Live-Dashboard, zum Live-Überwachen eines Roll-outs oder zum Überwachen von Anwendungsproblemen, die Benachrichtigungen und benutzerdefinierte Workflows auslösen.
Wenn Sie den Streaming-Export von Crashlytics nach BigQuery aktivieren, haben Sie zusätzlich zur Batchtabelle auch eine Echtzeittabelle. Die Tabellen unterscheiden sich in folgenden Punkten:
Batchtabelle | Echtzeittabelle |
---|---|
|
|
Die Batchtabelle eignet sich ideal für langfristige Analysen und die Erkennung von Trends im Zeitverlauf, da Ereignisse dauerhaft gespeichert werden, bevor sie geschrieben werden, und bis zu 30 Tage lang in die Tabelle zurückgefüllt werden können*. Wenn wir Daten in Ihre Echtzeittabelle schreiben, werden sie sofort in BigQuery geschrieben. Daher eignet sich BigQuery ideal für Live-Dashboards und benutzerdefinierte Benachrichtigungen. Diese beiden Tabellen können mit einer Stitching-Abfrage kombiniert werden, um die Vorteile beider zu nutzen.
Standardmäßig hat die Echtzeittabelle eine Partitionsablaufzeit von 30 Tagen. Weitere Informationen zum Ändern finden Sie in der BigQuery-Dokumentation unter Partitionsablauf festlegen.
* Details zur Unterstützung von Backfills finden Sie unter Auf die neue Exportinfrastruktur umstellen.
Crashlytics-Streamingexport nach BigQuery aktivieren
Rufen Sie in der Firebase Console die Seite Integrationen auf.
Klicken Sie auf der Karte BigQuery auf Verwalten.
Klicken Sie das Kästchen Streaming einschließen an.
Dadurch wird das Streaming für alle verknüpften Apps aktiviert.
Was kann ich mit den exportierten Daten tun?
Exporte nach BigQuery enthalten Rohabsturzdaten wie Gerätetyp, Betriebssystem, Ausnahmen (Android-Apps) oder Fehler (Apple-Apps) und Crashlytics-Protokolle sowie andere Daten.
Weitere Informationen dazu, welche Crashlytics-Daten exportiert werden und wie das Tabellenschema aussieht, finden Sie weiter unten auf dieser Seite.
Data Studio-Vorlage verwenden
Wenn Sie Echtzeitdaten in Ihrer Data Studio-Vorlage aktivieren möchten, folgen Sie der Anleitung unter Exportierte Crashlytics-Daten mit Data Studio visualisieren.
Ansichten erstellen
Sie können Abfragen über die BigQuery-Benutzeroberfläche in Ansichten umwandeln. Eine ausführliche Anleitung finden Sie in der BigQuery-Dokumentation unter Ansichten erstellen.
Abfragen ausführen
Die folgenden Beispiele zeigen Abfragen, die Sie mit Ihren Crashlytics-Daten ausführen können, um Berichte zu generieren, in denen Daten zu Absturzereignissen übersichtlicher zusammengefasst werden. Da diese Berichtstypen nicht im Crashlytics-Dashboard der Firebase-Konsole verfügbar sind, können sie Ihre Analyse und Ihr Verständnis von Absturzdaten ergänzen.
Beispiel 1: Abstürze nach Tag
Nachdem Sie so viele Fehler wie möglich behoben haben, sind Sie der Meinung, dass Ihr Team endlich bereit ist, Ihre neue Foto-Sharing-App auf den Markt zu bringen. Bevor Sie dies tun, möchten Sie die Anzahl der täglichen Abstürze im letzten Monat prüfen, um sich zu vergewissern, dass die App aufgrund der Fehlerbehebungen im Lauf der Zeit stabiler geworden ist.
Hier ist eine Beispielabfrage für eine Android-App. Verwenden Sie für eine iOS-App die Paket-ID und IOS
(anstelle des Paketnamens und 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;
Beispiel 2: Häufigste Abstürze ermitteln
Um die Produktionspläne richtig zu priorisieren, möchten Sie die zehn häufigsten Abstürze in Ihrer App ermitteln. Sie erstellen eine Abfrage, die die relevanten Datenpunkte liefert.
Hier ist eine Beispielabfrage für eine Android-App. Verwenden Sie für eine iOS-App die Paket-ID und IOS
(anstelle des Paketnamens und 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;
Beispiel 3: Die zehn Geräte mit den meisten Abstürzen
Im Herbst kommen die neuen Smartphones auf den Markt! Ihr Unternehmen weiß, dass dadurch auch neue gerätespezifische Probleme auftreten, insbesondere bei Android. Sie erstellen eine Abfrage zur Ermittlung der zehn Geräte, die in der vergangenen Woche (168 Stunden) am häufigsten abgestürzt sind, um sich einen Überblick über die voraussichtlichen Kompatibilitätsprobleme zu verschaffen.
Hier ist eine Beispielabfrage für eine Android-App. Verwenden Sie für eine iOS-App die Paket-ID und IOS
(anstelle des Paketnamens und 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;
Beispiel 4: Nach benutzerdefiniertem Schlüssel filtern
Sie sind Spieleentwickler und möchten wissen, auf welchem Level Ihres Spiels es am häufigsten zu Abstürzen kommt.
Sie legen zur Ermittlung der Statistik den benutzerdefinierten Crashlytics-Schlüssel current_level
fest und aktualisieren ihn jedes Mal, wenn der Nutzer ein neues Level erreicht.
Swift
Crashlytics.sharedInstance().setIntValue(3, forKey: "current_level");
Objective-C
CrashlyticsKit setIntValue:3 forKey:@"current_level";
Java
Crashlytics.setInt("current_level", 3);
Mit diesem Schlüssel in Ihrem Export nach BigQuery können Sie dann eine Abfrage schreiben, um die Verteilung der mit jedem Absturzereignis verbundenen current_level
-Werte zu protokollieren.
Hier ist eine Beispielabfrage für eine Android-App. Verwenden Sie für eine iOS-App die Paket-ID und IOS
(anstelle des Paketnamens und 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
Beispiel 5: User-ID-Extraktion
Sie haben eine Android-App im Early Access. Die meisten Nutzer sind begeistert, bei dreien sind jedoch ungewöhnlich viele Abstürze aufgetreten. Zur Ermittlung der Ursache schreiben Sie eine Abfrage, mit der alle Absturzereignisse der betroffenen Nutzer anhand ihrer Nutzer-ID abgerufen werden.
Hier ist eine Beispielabfrage für eine Android-App. Verwenden Sie für eine iOS-App die Paket-ID und IOS
(anstelle des Paketnamens und 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
Beispiel 6: Alle Nutzer mit einem bestimmten Absturzproblem ermitteln
Ihr Team hat versehentlich einen kritischen Fehler in einer Version veröffentlicht, die an eine Gruppe von Betatestern gesendet wurde. Ihr Team konnte die Abfrage aus dem Beispiel Die häufigsten Abstürze finden oben verwenden, um die ID des spezifischen Absturzproblems zu ermitteln. Ihr Team möchte jetzt eine Abfrage ausführen, um eine Liste der App-Nutzer zu extrahieren, die von diesem Absturz betroffen waren.
Hier ist eine Beispielabfrage für eine Android-App. Verwenden Sie für eine iOS-App die Paket-ID und IOS
(anstelle des Paketnamens und 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;
Beispiel 7: Anzahl der Nutzer, die von einem Absturz betroffen sind, aufgeschlüsselt nach Land
Ihr Team hat beim Roll-out eines neuen Release einen kritischen Fehler entdeckt. Sie konnten die Abfrage aus dem Beispiel „Häufigste Abstürze finden“ oben verwenden, um die ID des spezifischen Absturzproblems zu ermitteln. Ihr Team möchte nun wissen, ob sich dieser Absturz auf Nutzer in verschiedenen Ländern ausgeweitet hat.
Um diese Abfrage zu schreiben, muss Ihr Team Folgendes tun:
Aktivieren Sie den Export von Google Analytics-Daten nach BigQuery. Weitere Informationen finden Sie unter Projektdaten nach BigQuery exportieren.
Aktualisieren Sie Ihre App, damit eine User-ID sowohl an das Google Analytics SDK als auch an das Crashlytics SDK übergeben wird.
Swift
Crashlytics.sharedInstance().setUserIdentifier("123456789"); Analytics.setUserID("123456789");
Objective-C
CrashlyticsKit setUserIdentifier:@"123456789"; FIRAnalytics setUserID:@"12345678 9";
Java
Crashlytics.setUserIdentifier("123456789"); mFirebaseAnalytics.setUserId("123456789");
Erstellen Sie eine Abfrage, in der Ereignisse im Dataset Google Analytics anhand des Felds „User-ID“ mit Abstürzen im Dataset Crashlytics zusammengeführt werden.
Hier ist eine Beispielabfrage für eine Android-App. Verwenden Sie für eine iOS-App die Paket-ID und
IOS
(anstelle des Paketnamens undANDROID
).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
Beispiel 8: Die fünf häufigsten Probleme heute
Hier ist eine Beispielabfrage für eine Android-App. Verwenden Sie für eine iOS-App die Paket-ID und IOS
(anstelle des Paketnamens und 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;
Beispiel 9: Die fünf häufigsten Probleme seit dem DATE, einschließlich heute
Sie können die Batch- und Echtzeittabellen auch mit einer Stitching-Abfrage kombinieren, um den zuverlässigen Batchdaten Echtzeitinformationen hinzuzufügen. Da event_id
ein Primärschlüssel ist, können Sie damit gemeinsame Ereignisse aus den beiden Tabellen deduplizieren.DISTINCT event_id
Hier ist eine Beispielabfrage für eine Android-App. Verwenden Sie für eine iOS-App die Paket-ID und IOS
(anstelle des Paketnamens und 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;
Crashlytics-Schema in BigQuery
Wenn Sie den Crashlytics-Datenexport nach BigQuery einrichten, exportiert Firebase aktuelle Ereignisse (Abstürze, nicht schwerwiegende Fehler und ANRs), einschließlich Ereignisse, die bis zu zwei Tage vor der Verknüpfung aufgetreten sind. Dabei besteht die Möglichkeit, bis zu 30 Tage Backfills durchzuführen.
Der Export der Crashlytics-Ereignisse erfolgt ab diesem Zeitpunkt täglich, bis Sie den Export deaktivieren. Es kann einige Minuten dauern, bis die Daten nach jedem Export in BigQuery verfügbar sind.
Datasets
Crashlytics erstellt ein neues Dataset in BigQuery für Crashlytics-Daten. Das Dataset deckt das gesamte Projekt ab, selbst wenn dieses mehrere Anwendungen umfasst.
Tabellen
Crashlytics erstellt für jede Anwendung des Projekts eine Tabelle im Dataset, es sei denn, Sie haben den Datenexport für eine Anwendung deaktiviert. Die Tabellen werden in Firebase nach der ID der Anwendung benannt. Die in der ID enthaltenen Punkte werden in Unterstriche umgewandelt und am Ende wird der Plattformname angehängt.
Daten für eine Android-App mit dem Paketnamen com.google.test
würden beispielsweise in einer Tabelle mit dem Namen com_google_test_ANDROID
gespeichert. Realtime-Daten (falls aktiviert) würden in einer Tabelle mit dem Namen com_google_test_ANDROID_REALTIME
gespeichert.
Tabellen enthalten einen Standardsatz von Crashlytics-Daten sowie alle benutzerdefinierten Crashlytics-Schlüssel, die Sie in Ihrer App definiert haben.
Zeilen
Jede Zeile der Tabelle stellt einen Fehler der Anwendung dar.
Spalten
Die Spalten der Tabelle sind für Abstürze, nicht schwerwiegende Fehler und ANRs identisch. Wenn der Streamingexport von Crashlytics nach BigQuery aktiviert ist, hat die Echtzeittabelle dieselben Spalten wie die Batchtabelle. Es kann sein, dass Zeilen Spalten enthalten, die Ereignisse darstellen, die keine Stack-Traces haben.
Die Spalten im Export sind in dieser Tabelle aufgeführt:
Feldname | Datentyp | Beschreibung |
---|---|---|
platform |
STRING | Die im Firebase-Projekt registrierte Plattform der App (gültige Werte: IOS oder ANDROID )
|
bundle_identifier |
STRING | Die eindeutige Kennung für die App, wie sie im Firebase-Projekt registriert ist (z. B. com.google.gmail Bei Apps für die Apple-Plattform ist dies die Bundle-ID der App. Bei Android-Apps ist dies der Paketname der App. |
event_id |
STRING | Die eindeutige ID für das Ereignis |
is_fatal |
BOOLEAN | Ob die App abgestürzt ist |
error_type |
STRING | Der Fehlertyp des Ereignisses (z. B. FATAL , NON_FATAL , ANR usw.) |
issue_id |
STRING | Das mit dem Ereignis verknüpfte Problem |
variant_id |
STRING | Die mit diesem Ereignis verknüpfte Problemvariante Hinweis: Nicht alle Ereignisse haben eine verknüpfte Problemvariante. |
event_timestamp |
TIMESTAMP | Zeitpunkt des Ereignisses |
device |
DATENSATZ | Das Gerät, auf dem das Ereignis aufgetreten ist |
device.manufacturer |
STRING | Gerätehersteller |
device.model |
STRING | Gerätemodell |
device.architecture |
STRING | Beispiel: X86_32 , X86_64 , ARMV7 ,
ARM64 , ARMV7S oder ARMV7K |
memory |
DATENSATZ | Speicherstatus des Geräts |
memory.used |
INT64 | Verwendeter Arbeitsspeicher in Byte |
memory.free |
INT64 | Verbleibender Arbeitsspeicher (in Byte) |
storage |
DATENSATZ | Nichtflüchtiger Speicher des Geräts |
storage.used |
INT64 | Belegter Speicherplatz in Bytes |
storage.free |
INT64 | Verbleibender Speicherplatz in Byte |
operating_system |
DATENSATZ | Details zum Betriebssystem auf dem Gerät |
operating_system.display_version |
STRING | Die Version des Betriebssystems auf dem Gerät |
operating_system.name |
STRING | Der Name des Betriebssystems auf dem Gerät |
operating_system.modification_state |
STRING | Ob das Gerät modifiziert wurde (z. B. MODIFIED für eine App mit Jailbreak und UNMODIFIED für eine gerootete App) |
operating_system.type |
STRING | (Nur Apple-Apps) Der Typ des Betriebssystems, das auf dem Gerät ausgeführt wird (z. B. IOS oder MACOS ) |
operating_system.device_type |
STRING | Der Gerätetyp (z. B. MOBILE , TABLET , TV usw.); auch als „Gerätekategorie“ bezeichnet |
application |
DATENSATZ | Die App, die das Ereignis generiert hat |
application.build_version |
STRING | Die Build-Version der App |
application.display_version |
STRING | |
user |
DATENSATZ | Optional: Informationen, die über den Nutzer der App erfasst wurden |
user.name |
STRING | Optional: Name des Nutzers |
user.email |
STRING | Optional: E-Mail-Adresse des Nutzers |
user.id |
STRING | Optional: Eine appspezifische ID, die mit dem Nutzer verknüpft ist |
custom_keys |
REPEATED RECORD | Vom Entwickler definierte Schlüssel/Wert-Paare |
custom_keys.key |
STRING | Ein vom Entwickler definierter Schlüssel |
custom_keys.value |
STRING | Ein vom Entwickler definierter Wert |
installation_uuid |
STRING | Eine ID, die eine eindeutige App- und Geräteinstallation identifiziert |
crashlytics_sdk_versions |
STRING | Die Crashlytics SDK-Version, mit der das Ereignis generiert wurde |
app_orientation |
STRING | Beispiel: PORTRAIT , LANDSCAPE , FACE_UP , FACE_DOWN usw. |
device_orientation |
STRING | Beispiel: PORTRAIT , LANDSCAPE , FACE_UP , FACE_DOWN usw. |
process_state |
STRING | BACKGROUND oder FOREGROUND |
logs |
REPEATED RECORD | Zeitgestempelte Lognachrichten, die vom Crashlytics-Logger generiert werden, falls aktiviert |
logs.timestamp |
TIMESTAMP | Wann das Protokoll erstellt wurde |
logs.message |
STRING | Die protokollierte Nachricht |
breadcrumbs |
REPEATED RECORD | Zeitgestempelte Google Analytics-Navigationspfade, sofern aktiviert |
breadcrumbs.timestamp |
TIMESTAMP | Der Zeitstempel, der mit dem Breadcrumb verknüpft ist |
breadcrumbs.name |
STRING | Der Name, der mit dem Navigationspfad verknüpft ist |
breadcrumbs.params |
REPEATED RECORD | Mit dem Navigationspfad verknüpfte Parameter |
breadcrumbs.params.key |
STRING | Ein Parameterschlüssel, der mit dem Navigationspfad verknüpft ist |
breadcrumbs.params.value |
STRING | Ein Parameterwert, der mit dem Navigationspfad verknüpft ist |
blame_frame |
DATENSATZ | Der Frame, der als Ursache des Absturzes oder Fehlers identifiziert wurde |
blame_frame.line |
INT64 | Die Zeilennummer der Datei des Frames |
blame_frame.file |
STRING | Der Name der Framedatei |
blame_frame.symbol |
STRING | Das Symbol für hydratisierte oder das Symbol für Rohdaten, wenn die Daten nicht hydratisiert werden können |
blame_frame.offset |
INT64 | Der Byte-Offset im Binär-Image, das den Code enthält Für Java-Ausnahmen nicht festgelegt |
blame_frame.address |
INT64 | Die Adresse im Binär-Image, die den Code enthält Für Java-Frames nicht festgelegt |
blame_frame.library |
STRING | Der Anzeigename der Bibliothek, die den Frame enthält |
blame_frame.owner |
STRING | Beispiel: DEVELOPER , VENDOR , RUNTIME , PLATFORM oder SYSTEM |
blame_frame.blamed |
BOOLEAN | Ob Crashlytics festgestellt hat, dass dieser Frame die Ursache für den Absturz oder Fehler ist |
exceptions |
REPEATED RECORD | (Nur Android) Ausnahmen, die während dieses Ereignisses aufgetreten sind. Verschachtelte Ausnahmen werden in umgekehrter chronologischer Reihenfolge angezeigt. Das bedeutet, dass der letzte Eintrag die erste geworfene Ausnahme ist. |
exceptions.type |
STRING | Der Ausnahmetyp (z. B. java.lang.IllegalStateException) |
exceptions.exception_message |
STRING | Eine Nachricht, die mit der Ausnahme verknüpft ist |
exceptions.nested |
BOOLEAN | True für alle Einträge außer der zuletzt geworfenen Ausnahme (d. h. dem ersten Datensatz) |
exceptions.title |
STRING | Der Titel des Threads |
exceptions.subtitle |
STRING | Der Untertitel des Threads |
exceptions.blamed |
BOOLEAN | „Wahr“, wenn Crashlytics feststellt, dass die Ausnahme für den Fehler oder Absturz verantwortlich ist |
exceptions.frames |
REPEATED RECORD | Die mit der Ausnahme verknüpften Frames |
exceptions.frames.line |
INT64 | Die Zeilennummer der Datei des Frames |
exceptions.frames.file |
STRING | Der Name der Framedatei |
exceptions.frames.symbol |
STRING | Das Symbol für hydratisierte oder das Symbol für Rohdaten, wenn die Daten nicht hydratisiert werden können |
exceptions.frames.offset |
INT64 | Der Byte-Offset im Binär-Image, das den Code enthält Für Java-Ausnahmen nicht festgelegt |
exceptions.frames.address |
INT64 | Die Adresse im Binär-Image, die den Code enthält Für Java-Frames nicht festgelegt |
exceptions.frames.library |
STRING | Der Anzeigename der Bibliothek, die den Frame enthält |
exceptions.frames.owner |
STRING | Beispiel: DEVELOPER , VENDOR , RUNTIME , PLATFORM oder SYSTEM |
exceptions.frames.blamed |
BOOLEAN | Ob Crashlytics festgestellt hat, dass dieser Frame die Ursache für den Absturz oder Fehler ist |
error |
REPEATED RECORD | (nur Apple-Apps) nicht schwerwiegende Fehler |
error.queue_name |
STRING | Die Warteschlange, in der der Thread ausgeführt wurde |
error.code |
INT64 | Fehlercode, der mit der benutzerdefinierten NSError der App verknüpft ist |
error.title |
STRING | Der Titel des Threads |
error.subtitle |
STRING | Der Untertitel des Threads |
error.blamed |
BOOLEAN | Ob Crashlytics festgestellt hat, dass dieser Frame die Ursache des Fehlers ist |
error.frames |
REPEATED RECORD | Die Frames des Stack-Traces |
error.frames.line |
INT64 | Die Zeilennummer der Datei des Frames |
error.frames.file |
STRING | Der Name der Framedatei |
error.frames.symbol |
STRING | Das Symbol für hydratisierte oder das Symbol für Rohdaten, wenn die Daten nicht hydratisiert werden können |
error.frames.offset |
INT64 | Der Byte-Offset im Binär-Image, das den Code enthält |
error.frames.address |
INT64 | Die Adresse im Binär-Image, die den Code enthält |
error.frames.library |
STRING | Der Anzeigename der Bibliothek, die den Frame enthält |
error.frames.owner |
STRING | Beispiel: DEVELOPER , VENDOR , RUNTIME , PLATFORM oder SYSTEM |
error.frames.blamed |
BOOLEAN | Ob Crashlytics festgestellt hat, dass dieser Frame die Ursache des Fehlers ist |
threads |
REPEATED RECORD | Threads, die zum Zeitpunkt des Ereignisses vorhanden waren |
threads.crashed |
BOOLEAN | Ob der Thread abgestürzt ist |
threads.thread_name |
STRING | Der Name des Threads |
threads.queue_name |
STRING | (Nur Apple-Apps) Die Warteschlange, in der der Thread ausgeführt wurde |
threads.signal_name |
STRING | Der Name des Signals, das zum Absturz der App geführt hat. Nur in abgestürzten nativen Threads vorhanden. |
threads.signal_code |
STRING | Der Code des Signals, das zum Absturz der App geführt hat; nur bei abgestürzten nativen Threads vorhanden |
threads.crash_address |
INT64 | Die Adresse des Signals, das zum Absturz der Anwendung geführt hat. Nur bei abgestürzten nativen Threads vorhanden. |
threads.code |
INT64 | (Nur Apple-Apps) Fehlercode der benutzerdefinierten NSError, die von der Anwendung protokolliert wurde |
threads.title |
STRING | Der Titel des Threads |
threads.subtitle |
STRING | Der Untertitel des Threads |
threads.blamed |
BOOLEAN | Ob Crashlytics festgestellt hat, dass dieser Frame die Ursache für den Absturz oder Fehler ist |
threads.frames |
REPEATED RECORD | Die einzelnen Frames des Threads |
threads.frames.line |
INT64 | Die Zeilennummer der Datei des Frames |
threads.frames.file |
STRING | Der Name der Framedatei |
threads.frames.symbol |
STRING | Das Symbol für hydratisierte oder das Symbol für Rohdaten, wenn das Material nicht hydratisiert werden kann |
threads.frames.offset |
INT64 | Der Byte-Offset im Binär-Image, das den Code enthält |
threads.frames.address |
INT64 | Die Adresse im Binär-Image, die den Code enthält |
threads.frames.library |
STRING | Der Anzeigename der Bibliothek, die den Frame enthält |
threads.frames.owner |
STRING | Beispiel: DEVELOPER , VENDOR , RUNTIME , PLATFORM oder SYSTEM |
threads.frames.blamed |
BOOLEAN | Ob Crashlytics festgestellt hat, dass dieser Frame die Ursache des Fehlers ist |
unity_metadata.unity_version |
STRING | Die Unity-Version, die auf diesem Gerät ausgeführt wird |
unity_metadata.debug_build |
BOOLEAN | Wenn es sich um einen Debug-Build handelt |
unity_metadata.processor_type |
STRING | Prozessortyp |
unity_metadata.processor_count |
INT64 | Die Anzahl der Prozessoren (Kerne) |
unity_metadata.processor_frequency_mhz |
INT64 | Die Taktfrequenz der Prozessoren in MHz |
unity_metadata.system_memory_size_mb |
INT64 | Die Größe des Arbeitsspeichers des Systems in MB |
unity_metadata.graphics_memory_size_mb |
INT64 | Der Grafikspeicher in MB |
unity_metadata.graphics_device_id |
INT64 | Die Kennung des Grafikgeräts |
unity_metadata.graphics_device_vendor_id |
INT64 | Die Kennung des Anbieters des Grafikprozessors |
unity_metadata.graphics_device_name |
STRING | Der Name des Grafikgeräts |
unity_metadata.graphics_device_vendor |
STRING | Der Anbieter des Grafikgeräts |
unity_metadata.graphics_device_version |
STRING | Die Version des Grafikgeräts |
unity_metadata.graphics_device_type |
STRING | Der Typ des Grafikgeräts |
unity_metadata.graphics_shader_level |
INT64 | Die Shaderebene der Grafiken |
unity_metadata.graphics_render_target_count |
INT64 | Die Anzahl der grafischen Rendering-Ziele |
unity_metadata.graphics_copy_texture_support |
STRING | Unterstützung für das Kopieren von Grafiktextur gemäß der Unity API |
unity_metadata.graphics_max_texture_size |
INT64 | Die maximale Größe für das Rendern von Textur |
unity_metadata.screen_size_px |
STRING | Die Größe des Bildschirms in Pixeln, formatiert als Breite x Höhe |
unity_metadata.screen_resolution_dpi |
STRING | Die Bildschirmdichte als Gleitkommazahl |
unity_metadata.screen_refresh_rate_hz |
INT64 | Die Aktualisierungsrate des Displays in Hz |
Exportierte Crashlytics-Daten mit Data Studio visualisieren
Google Data Studio wandelt Ihre Crashlytics-Datensätze in BigQuery in Berichte um. Die vollständig anpassbaren Berichte sind übersichtlich und lassen sich einfach teilen.
Weitere Informationen zur Verwendung von Data Studio finden Sie in der Kurzanleitung zu Data Studio.
Crashlytics-Berichtsvorlage verwenden
Data Studio bietet einen Beispielbericht für Crashlytics. Dieser enthält umfassende Dimensionen und Messwerte des exportierten Crashlytics-BigQuery-Schemas. Wenn Sie den Streamingexport von Crashlytics nach BigQuery aktiviert haben, können Sie diese Daten auf der Seite Echtzeittrends der Data Studio-Vorlage aufrufen.Sie können das Beispiel als Vorlage verwenden, um schnell neue Berichte und Visualisierungen auf Grundlage der Rohdaten der Abstürze Ihrer App zu erstellen:
Öffnen Sie die Crashlytics-Data Studio-Dashboard-Vorlage.
Klicken Sie rechts oben auf Vorlage verwenden.
Wählen Sie im Drop-down-Menü Neue Datenquelle die Option Neue Datenquelle erstellen aus.
Klicken Sie auf der Karte BigQuery auf Auswählen.
Wählen Sie unter Meine Projekte > PROJECT_ID > firebase_crashlytics > TABLE_NAME eine Tabelle mit exportierten Crashlytics-Daten aus.
Ihre Batch-Tabelle kann jederzeit ausgewählt werden. Wenn der Streaming-Export von Crashlytics nach BigQuery aktiviert ist, können Sie stattdessen Ihre Echtzeittabelle auswählen.
Legen Sie unter Konfiguration die Option Crashlytics-Vorlagenebene auf Standard fest.
Klicken Sie auf Verbinden, um die neue Datenquelle zu erstellen.
Klicken Sie auf Zum Bericht hinzufügen, um zur Crashlytics-Vorlage zurückzukehren.
Klicken Sie abschließend auf Bericht erstellen, um eine Kopie der Vorlage „Crashlytics Data Studio-Dashboard“ zu erstellen.
Auf die neue Exportinfrastruktur umstellen
Mitte Oktober 2024 hat Crashlytics eine neue Infrastruktur für den Export von Crashlytics-Daten in BigQuery eingeführt. Ein Upgrade auf diese neue Infrastruktur ist derzeit optional.
Diese neue Infrastruktur unterstützt Crashlytics Speicherorte für Datensätze außerhalb der USA.
Wenn Sie den Export vor Mitte Oktober 2024 aktiviert haben, können Sie jetzt optional den Speicherort für den Datenexport in einen beliebigen von BigQuery unterstützten Speicherort für Datasets ändern.
Wenn Sie den Export Mitte Oktober 2024 oder später aktiviert haben, können Sie bei der Einrichtung einen beliebigen von BigQuery unterstützten Speicherort für den Datensatz auswählen.
Ein weiterer Unterschied bei der neuen Infrastruktur besteht darin, dass sie keine Backfills von Daten aus der Zeit vor der Aktivierung des Exports unterstützt. Mit der alten Infrastruktur war es möglich, bis zu 30 Tage vor dem Aktivierungsdatum Backfills durchzuführen. Die neue Infrastruktur unterstützt Backfills bis zu den letzten 30 Tagen oder bis zum Datum, an dem Sie den Export nach BigQuery aktiviert haben (je nachdem, was zuletzt eingetreten ist).
Voraussetzung für das Upgrade
Bevor Sie auf die neue Infrastruktur umstellen, prüfen Sie, ob Sie die folgende Voraussetzung erfüllen: Die Tabellen des aktuellen Batches BigQuery haben dieselben Kennungen wie die für Ihre registrierten Firebase-Apps festgelegten Paket-IDs oder Paketnamen.
Beispiel:
Wenn Sie eine BigQuery-Tabelle mit dem Namen
com_yourcompany_yourproject_IOS
haben, sollte in Ihrem Firebase-Projekt eine Firebase-iOS-App mit der Bundle-IDcom.yourcompany.yourproject
registriert sein.Wenn Sie eine BigQuery-Tabelle mit dem Namen
com_yourcompany_yourproject_ANDROID
haben, sollte in Ihrem Firebase-Projekt eine Firebase-Android-App mit dem Paketnamencom.yourcompany.yourproject
registriert sein.
So rufen Sie alle in Ihrem Firebase-Projekt registrierten Firebase-Apps auf:
Rufen Sie in der Firebase Console die Projekteinstellungen auf.
Scrollen Sie nach unten zur Karte Meine Apps und klicken Sie auf die gewünschte Firebase App, um die Informationen zur App einschließlich ihrer Kennung aufzurufen.
Die neue Exportinfrastruktur exportiert die Daten jeder App basierend auf dem Paketnamen oder der Paket-ID, die für die registrierte Firebase-App festgelegt wurde. Damit Ihr BigQuery-Workflow nicht unterbrochen wird, müssen Ihre aktuellen Batchtabellen bereits die richtigen Namen haben, damit die neue Infrastruktur alle neuen Daten an die vorhandenen Tabellen anhängen kann. Wenn die Namen Ihrer Batchtabellen nicht mit Ihren registrierten Firebase-Apps übereinstimmen, Sie aber trotzdem umstellen möchten, wenden Sie sich an den Firebase-Support.
So führen Sie ein Upgrade auf die neue Infrastruktur durch
Wenn Sie den Export bereits aktiviert haben, können Sie auf die neue Infrastruktur umstellen, indem Sie den Crashlytics-Datenexport in der Firebase-Konsole einfach deaktivieren und wieder aktivieren.
So gehts:
Rufen Sie in der Firebase Console die Seite Integrationen auf.
Klicken Sie auf der Karte BigQuery auf Verwalten.
Deaktivieren Sie den Schieberegler Crashlytics, um den Export zu deaktivieren. Bestätigen Sie auf Nachfrage, dass der Datenexport beendet werden soll.
Aktivieren Sie den Schieberegler Crashlytics sofort wieder, um den Export zu aktivieren. Bestätigen Sie auf Nachfrage, dass Sie Daten exportieren möchten.
Für den Datenexport von Crashlytics nach BigQuery wird jetzt die neue Exportinfrastruktur verwendet.