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

  1. Rufen Sie in der Firebase Console die Seite Integrationen auf.

  2. Klicken Sie auf der Karte BigQuery auf Verknüpfen.

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

    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ückgefüllt 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

  1. Rufen Sie in der Firebase Console die Seite Integrationen auf.

  2. Klicken Sie auf der Karte BigQuery auf Verwalten.

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

  1. Aktivieren Sie den Export von Google Analytics-Daten nach BigQuery. Weitere Informationen finden Sie unter Projektdaten nach BigQuery exportieren.

  2. 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");

  3. 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 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, 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 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:

  1. Öffnen Sie die Crashlytics-Data Studio-Dashboard-Vorlage.

  2. Klicken Sie rechts oben auf Vorlage verwenden.

  3. Wählen Sie im Drop-down-Menü Neue Datenquelle die Option Neue Datenquelle erstellen aus.

  4. Klicken Sie auf der Karte BigQuery auf Auswählen.

  5. 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 Crashlytics-Streamingexport nach BigQuery aktiviert ist, können Sie stattdessen Ihre Echtzeittabelle auswählen.

  6. Legen Sie unter Konfiguration die Option Crashlytics-Vorlagenebene auf Standard fest.

  7. Klicken Sie auf Verbinden, um die neue Datenquelle zu erstellen.

  8. Klicken Sie auf Zum Bericht hinzufügen, um zur Crashlytics-Vorlage zurückzukehren.

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

  1. Rufen Sie in der Firebase Console die Projekteinstellungen auf.

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

  1. Rufen Sie in der Firebase Console die Seite Integrationen auf.

  2. Klicken Sie auf der Karte BigQuery auf Verwalten.

  3. Deaktivieren Sie den Schieberegler Crashlytics, um den Export zu deaktivieren. Bestätigen Sie auf Nachfrage, dass der Datenexport beendet werden soll.

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