Diese Seite wurde von der Cloud Translation API übersetzt.

Firebase Crashlytics-Daten nach BigQuery exportieren

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 nach 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 nach 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 Exportfunktion aktiviere?

Sie wählen den Speicherort des Datensatzes aus. Nachdem das Dataset erstellt wurde, kann der Standort nicht mehr geändert werden. Sie können das Dataset jedoch an einen anderen Standort kopieren oder es manuell an einen anderen Standort verschieben (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.

Hinweis :Der Speicherort für den Datenexport kann nur dann ausgewählt und geändert werden, wenn Sie den Export nach Mitte Oktober 2024 aktiviert oder ein Upgrade auf die neue Exportinfrastruktur durchgeführt haben.
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 täglich, unabhängig von geplanten Exporten, die Sie möglicherweise in 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 erste Weitergabe 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 für die Batchtabelle Daten-Backfills manuell planen, und zwar maximal für die letzten 30 Tage oder für das letzte Datum, an dem Sie den Export nach BigQuery aktiviert haben (je nachdem, welches Datum das letzte 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, einen Backfill ausfü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. für die Präsentation von Informationen in einem Live-Dashboard, für die Live-Überwachung eines Roll-outs oder für die Überwachung von Anwendungsproblemen, die Benachrichtigungen und benutzerdefinierte Workflows auslösen.

Wenn Sie den Streamingexport von Crashlytics nach BigQuery aktivieren, haben Sie zusätzlich zur Batchtabelle auch eine Echtzeittabelle. Die Tabellen unterscheiden sich in folgenden Punkten:

Batchtabelle	Echtzeittabelle
Die Daten werden einmal täglich exportiert. Ereignisse werden dauerhaft gespeichert, bevor sie im Batch in BigQuery schreiben. Daten können bis zu 30 Tage zurückgemeldet werden*.	Die Daten werden in Echtzeit exportiert. Ein Backfilling ist nicht möglich.

Die Batchtabelle ist ideal für die Langzeitanalyse und die Identifizierung von Trends im Zeitverlauf, da Ereignisse vor dem Schreiben dauerhaft gespeichert werden und sie bis zu 30 Tage lang in die Tabelle eingefügt werden können*. Wenn wir Daten in Ihre Realtime-Tabelle schreiben, schreiben wir sie sofort in BigQuery. Daher eignen sie sich 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

Wie Sie Echtzeitdaten in Ihrer Data Studio-Vorlage aktivieren, erfahren Sie unter Exportierte Crashlytics-Daten mit Data Studio visualisieren.

Ansichten erstellen

Sie können Abfragen mithilfe der BigQuery-UI in Ansichten umwandeln. Eine ausführliche Anleitung finden Sie in der Dokumentation zu BigQuery 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 zu einer leichter verständlichen Zusammenfassung 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, denken Sie, dass Ihr Team nun bereit ist, Ihre neue App zum Teilen von Fotos auf den Markt zu bringen. Zuvor sollten Sie die Anzahl der Abstürze pro Tag im letzten Monat überprüfen, um sicherzustellen, dass das Bug-Bash die App im Laufe der Zeit stabiler gemacht hat.

Hier sehen Sie eine Beispielabfrage für eine Android-App. Verwenden Sie bei einer 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 dies auch bedeutet, dass neue gerätespezifische Probleme auftreten – insbesondere in Bezug auf 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 in Ihrem Spiel die meisten Abstürze auftreten.

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 sehen Sie eine Beispielabfrage für eine Android-App. Verwenden Sie bei einer 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 Gruppe von Betatestern veröffentlicht. 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 jetzt sehen, ob sich dieser Absturz auf Nutzer in verschiedenen Ländern weltweit übertragen 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 und 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

Beispiel 8: Die fünf häufigsten Probleme des Tages

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 alle gemeinsamen Ereignisse aus den beiden Tabellen deduplizieren.

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 neben den von Ihnen in Ihrer App definierten benutzerdefinierten Crashlytics-Schlüsseln einen standardmäßigen Satz von Crashlytics-Daten.

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	Dieses Feld wurde eingestellt. Verwenden Sie stattdessen `error_type`. 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 App-Nutzer erhoben wurden
`user.name`	STRING	Die Verwendung dieses Feldes wurde eingestellt. Optional: Name des Nutzers
`user.email`	STRING	Dieses Feld ist veraltet. Verwenden Sie es nicht. 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 SDK-Version „Crashlytics“, die das Ereignis generiert hat
`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`	WIEDERHOLEN DATENSATZ	Vom Crashlytics-Logger generierte Protokollnachrichten mit Zeitstempel, sofern aktiviert
`logs.timestamp`	TIMESTAMP	Zeitpunkt der Erstellung des Protokolls
`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	Parameterwert, der dem Navigationspfad zugeordnet ist
`blame_frame`	DATENSATZ	Der Frame, der als Grundursache 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ärbild, das den Code enthält Nicht festgelegt für Java-Ausnahmen
`blame_frame.address`	INT64	Die Adresse im Binärbild, das den Code enthält Nicht festgelegt für Java-Frames
`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	Gibt an, ob Crashlytics festgestellt hat, dass dieser Frame die Ursache des Absturzes oder Fehlers 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 Datensatz die erste ausgelöste Ausnahme ist.
`exceptions.type`	STRING	Der Ausnahmetyp (z. B. `java.lang.IllegalStateException)`
`exceptions.exception_message`	STRING	Eine mit der Ausnahme verbundene Nachricht
`exceptions.nested`	BOOLEAN	"True" für alle Ausnahmen außer der zuletzt ausgelösten Ausnahme (d. h. dem ersten Eintrag)
`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`	WIEDERHOLEN DATENSATZ	Die mit der Ausnahme verbundenen 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ärbild, das den Code enthält Nicht festgelegt für Java-Ausnahmen
`exceptions.frames.address`	INT64	Die Adresse im Binärbild, das den Code enthält Nicht festgelegt für Java-Frames
`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	Gibt an, ob Crashlytics festgestellt hat, dass dieser Frame die Ursache des Absturzes oder Fehlers ist
`error`	WIEDERHOLEN DATENSATZ	(nur Apple-Apps) nicht schwerwiegende Fehler
`error.queue_name`	STRING	Die Warteschlange, in der der Thread ausgeführt wurde
`error.code`	INT64	Fehlercode, der dem benutzerdefinierten protokollierten NSError der Anwendung zugeordnet 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`	WIEDERHOLEN DATENSATZ	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 in dem Binärbild, 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 in 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 des benutzerdefinierten protokollierten NSError der Anwendung
`threads.title`	STRING	Der Titel des Threads
`threads.subtitle`	STRING	Der Untertitel des Threads
`threads.blamed`	BOOLEAN	Gibt an, ob Crashlytics festgestellt hat, dass dieser Frame die Ursache des Absturzes oder Fehlers ist
`threads.frames`	WIEDERHOLEN DATENSATZ	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 in dem Binärbild, 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 Rendering von Texturen
`unity_metadata.screen_size_px`	STRING	Die Größe des Bildschirms in Pixeln im Format 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

Mit Google Data Studio können Sie Crashlytics-Datensätze in BigQuery in Berichte umwandeln, die sich leichter lesen, einfacher teilen und vollständig anpassen lassen.

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 steht immer zur Auswahl. 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 Vorlage Crashlytics zurückzukehren.
Klicken Sie abschließend auf Bericht erstellen, um eine Kopie der Vorlage „Crashlytics Data Studio-Dashboard“ zu erstellen.

Upgrade auf die neue Exportinfrastruktur durchführen

Mitte Oktober 2024 hat Crashlytics eine neue Infrastruktur für den Export von Crashlytics-Daten nach 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-ID com.yourcompany.yourproject registriert sein.
Wenn Sie eine BigQuery-Tabelle mit dem Namen com_yourcompany_yourproject_ANDROID haben, sollte eine Firebase-Android-App mit dem Paketnamen com.yourcompany.yourproject in Ihrem Firebase-Projekt 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 App-Informationen, einschließlich ihrer ID, 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.

Upgrade auf die neue Infrastruktur ausführen

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.