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 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 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 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.

Hinweis: Sie können den Speicherort für den Datenexport nur auswählen und ändern, wenn Sie den Export nach Mitte Oktober 2024 aktiviert haben oder auf die neue Exportinfrastruktur umstellen.
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 Daten werden einmal täglich exportiert. Ereignisse werden dauerhaft gespeichert, bevor sie im Batchmodus in BigQuery geschrieben werden. Daten können bis zu 30 Tage zurückgemeldet werden*.	Die Daten werden in Echtzeit exportiert. Ein Backfilling ist nicht möglich.

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, darunter Gerätetyp, Betriebssystem, Ausnahmen (Android-Apps) oder Fehler (Apple-Apps) sowie Crashlytics-Protokolle und andere Daten.

Weitere Informationen dazu, welche Crashlytics-Daten exportiert werden und wie das Tabellen-Schema 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-IDs 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 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 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 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, durch die das Ereignis generiert wurde
`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	Die Verwendung dieses Feldes wurde eingestellt. Optional: Name des Nutzers
`user.email`	STRING	Die Verwendung dieses Feldes wurde eingestellt. 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	Vom Crashlytics-Logger generierte Protokollnachrichten mit Zeitstempel, 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 die Daten nicht hydratisiert werden können
`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 Texturen
`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

Mit Google Data Studio können Sie Crashlytics-Datensätze in BigQuery in Berichte umwandeln, die übersichtlich sind, sich leicht teilen lassen und vollständig anpassbar sind.

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-ID com.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 Paketnamen com.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 Daten jeder App werden von der neuen Exportinfrastruktur basierend auf dem Paketnamen oder der Paket-ID exportiert, 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.