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, zu einem anderen Cloud-Anbieter exportieren und für die Visualisierung und benutzerdefinierte Dashboards mit Looker Studio verwenden.

Was kann ich mit den exportierten Daten tun?

Exporte nach BigQuery enthalten Rohdaten zu Abstürzen, darunter Gerätetyp, Betriebssystem, Ausnahmen (Android-Apps) oder Fehler (Apple-Apps) und Crashlytics-Logs sowie andere Daten. Weiter unten auf dieser Seite finden Sie Informationen dazu, welche Crashlytics-Daten exportiert werden und wie das Tabellenschema aussieht.

Hier sind einige Beispiele für die Verwendung der exportierten Crashlytics-Daten:

  • Abfragen ausführen
    Sie können Abfragen für Ihre Crashlytics-Daten ausführen, um Berichte zu erstellen, in denen Daten zu Absturzereignissen übersichtlicher zusammengefasst werden. Da diese Arten von Berichten nicht im Crashlytics-Dashboard der Firebase-Konsole verfügbar sind, können sie Ihre Analyse und Ihr Verständnis von Absturzdaten ergänzen. Weiter unten auf dieser Seite finden Sie eine Auswahl von Beispielabfragen.

  • Looker Studio-Vorlage verwenden
    Crashlytics bietet eine vorgefertigte Looker Studio-Vorlage für die Visualisierung Ihrer exportierten Daten.

  • Ansichten erstellen
    Über die BigQuery-Benutzeroberfläche können Sie eine „Ansicht“ erstellen, also eine virtuelle Tabelle, die durch eine SQL-Abfrage definiert ist. Eine ausführliche Anleitung zu den verschiedenen Ansichtstypen und zum Erstellen von Ansichten finden Sie in der BigQuery-Dokumentation.

Crashlytics-Streaming-Export nach BigQuery

Mit BigQuery-Streaming können Sie Ihre Crashlytics-Daten in Echtzeit streamen. Sie können es für jeden Zweck verwenden, der Live-Daten erfordert, z. B. zum Präsentieren von Informationen in einem Live-Dashboard, zum Beobachten eines Rollouts in Echtzeit oder zum Überwachen von Anwendungsproblemen, die Benachrichtigungen und benutzerdefinierte Workflows auslösen.

Wenn Sie den Crashlytics-Streaming-Export nach BigQuery aktivieren, haben Sie zusätzlich zur Batchtabelle auch eine Echtzeittabelle. Hier sind die Unterschiede zwischen den Tabellen, die Sie kennen sollten:

Batch-Tabelle Echtzeittabelle
  • Die Daten werden einmal täglich exportiert.
  • Ereignisse werden dauerhaft gespeichert, bevor sie im Batch in BigQuery geschrieben werden.
  • Daten können bis zu 30 Tage rückwirkend nachgetragen werden*.
  • Die Daten werden in Echtzeit exportiert.
  • Es ist kein Backfilling verfügbar.

Die Batch-Tabelle eignet sich ideal für langfristige Analysen und die Ermittlung von Trends im Zeitverlauf, da Ereignisse dauerhaft gespeichert werden, bevor sie geschrieben werden. Außerdem können sie bis zu 30 Tage* lang in die Tabelle eingefügt werden. Wenn wir Daten in Ihre Echtzeittabelle schreiben, werden sie sofort in BigQuery geschrieben. Daher ist sie 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 beträgt die Ablaufzeit von Partitionen in der Echtzeittabelle 30 Tage. Informationen zum Ändern dieser Einstellung finden Sie in der BigQuery-Dokumentation unter Partitionsablauf festlegen.

* Details zur Unterstützung von Backfills finden Sie unter Auf die neue Exportinfrastruktur umstellen.


Export nach BigQuery aktivieren

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

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

  3. 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 ein Upgrade auf den Streaming-Export in Betracht ziehen.

Crashlytics-Streaming-Export nach BigQuery aktivieren

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

  2. Klicken Sie auf der Karte BigQuery auf Verwalten.

  3. Klicken Sie das Kästchen Streaming einschließen an.

Durch diese Aktion wird das Streaming für alle verknüpften Apps aktiviert.

Was passiert, wenn Sie den Export aktivieren?

  • Sie wählen den Speicherort des Datasets aus. Nachdem das Dataset erstellt wurde, kann der Standort nicht mehr geändert werden. Sie können das Dataset aber an einen anderen Standort kopieren oder es manuell verschieben, d. h. an einem anderen Standort neu erstellen. Weitere Informationen finden Sie unter Speicherort für vorhandene Exporte ändern.

    Dieser Speicherort gilt nur für die in BigQuery exportierten Daten und hat keine Auswirkungen auf den Speicherort von 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 tägliche Synchronisierungen 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 Ihre ersten Daten nach BigQuery exportiert werden.

    • Die tägliche Synchronisierung erfolgt einmal täglich, unabhängig von geplanten Exporten, die Sie in BigQuery eingerichtet haben. Das Timing und die Dauer des Synchronisierungsjobs können sich ändern. Wir empfehlen daher nicht, Downstream-Vorgänge oder ‑Jobs auf Grundlage eines bestimmten Timings des Exports zu planen.

  • Firebase exportiert eine Kopie Ihrer vorhandenen Daten nach BigQuery. Die erste Übertragung von Daten für den Export kann bis zu 48 Stunden dauern.

    • Für jede verknüpfte App enthält dieser Export eine Batch-Tabelle mit den Daten aus der täglichen Synchronisierung.

    • Sie können manuelle Backfills von Daten für die Batchtabelle für die letzten 30 Tage oder für das letzte Datum planen, an dem Sie den Export nach BigQuery aktiviert haben (je nachdem, was aktueller ist).

    Wenn Sie den Export von Crashlytics-Daten vor Mitte Oktober 2024 aktiviert haben, können Sie auch Daten für 30 Tage vor dem Tag, an dem Sie den Export aktiviert haben, nachträglich einfügen.

  • Wenn Sie den Streaming-Export von Crashlytics nach BigQuery aktivieren, enthalten alle verknüpften Apps auch eine Echtzeittabelle mit ständig aktualisierten Daten.

Wenn Sie den Export nach BigQuery deaktivieren möchten, heben Sie die Verknüpfung Ihres Projekts in der Firebase-Konsole auf.


Beispielabfragen

Beispiel 1: Abstürze nach Tag

Nachdem Sie so viele Programmfehler wie möglich behoben haben, ist Ihr Team der Meinung, dass die Foto-Sharing-App jetzt herausgebracht werden kann. Zuvor soll jedoch noch die Anzahl der täglichen Abstürze im vergangenen Monat überprüft werden. Sie möchten sichergehen, dass die App aufgrund der Fehlerbehebungen im Lauf der Zeit stabiler geworden ist.

Hier ist ein Beispiel für eine Anfrage 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: Die häufigsten Abstürze finden

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 ein Beispiel für eine Anfrage 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 10 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 ein Beispiel für eine Anfrage 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 Ihr Spiel am häufigsten abstürzt.

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 Werte für current_level zu protokollieren.

Hier ist ein Beispiel für eine Anfrage 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 extrahieren

Sie haben eine Android-App im Early Access-Programm. Die meisten Nutzer sind begeistert, während bei dreien ungewöhnlich viele Abstürze aufgetreten sind. Zur Ermittlung der Ursache schreiben Sie eine Abfrage, mit der alle Absturzereignisse der betroffenen Nutzer anhand ihrer Nutzer-IDs abgerufen werden.

Hier ist ein Beispiel für eine Anfrage 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 finden

Ihr Team hat versehentlich einen kritischen Fehler für eine Gruppe von Betatestern freigegeben. Ihr Team konnte die Abfrage aus dem Beispiel „Häufigste Abstürze finden“ oben verwenden, um die spezifische Absturzproblem-ID zu ermitteln. Ihr Team möchte nun eine Abfrage ausführen, um die Liste der App-Nutzer zu extrahieren, die von diesem Absturz betroffen waren.

Hier ist ein Beispiel für eine Anfrage 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 Absturzproblem betroffen sind, aufgeschlüsselt nach Land

Ihr Team hat während der Einführung eines neuen Releases einen kritischen Fehler erkannt. Sie konnten die Abfrage aus dem Beispiel „Häufigste Abstürze finden“ oben verwenden, um die spezifische Absturzproblem-ID zu ermitteln. Ihr Team möchte nun herausfinden, ob dieser Absturz auch bei Nutzern in anderen Ländern aufgetreten ist.

Um diese Abfrage zu schreiben, muss Ihr Team Folgendes tun:

  1. Export von Google Analytics-Daten nach BigQuery aktivieren. Weitere Informationen finden Sie unter Projektdaten in 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. Schreiben Sie eine Abfrage, mit der Ereignisse im Dataset Google Analytics anhand des Felds „user_id“ mit Abstürzen im Dataset Crashlytics verknüpft werden.

    Hier ist ein Beispiel für eine Anfrage 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 bisher heute

Hier ist ein Beispiel für eine Anfrage 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 DISTINCT event_id verwenden, um gemeinsame Ereignisse aus den beiden Tabellen zu deduplizieren.

Hier ist ein Beispiel für eine Anfrage 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 >= PARSE_TIMESTAMP("%Y_%m_%d", "YYYY_MM_DD")
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;


Exportierte Crashlytics-Daten mit Looker Studio visualisieren

Looker Studio wandelt Ihre Crashlytics-Datensätze in BigQuery in Berichte um, die übersichtlicher sind, sich einfacher teilen lassen und vollständig angepasst werden können.

Weitere Informationen zur Verwendung von Looker Studio finden Sie im Willkommensleitfaden.

Crashlytics-Berichtsvorlage verwenden

Looker Studio bietet einen Beispielbericht für Crashlytics. Dieser enthält umfassende Dimensionen und Messwerte des exportierten Crashlytics-Schemas BigQuery. Wenn Sie den Crashlytics-Streaming-Export nach BigQuery aktiviert haben, können Sie sich die Daten auf der Seite Echtzeittrends der Looker Studio-Vorlage ansehen.Sie können das Beispiel als Vorlage verwenden, um basierend auf den Rohdaten der Abstürze Ihrer App schnell neue Berichte und Visualisierungen zu erstellen:

  1. Öffnen Sie die Crashlytics Looker Studio-Dashboardvorlage.

  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 ist immer verfügbar. Wenn der Crashlytics-Streaming-Export nach BigQuery aktiviert ist, können Sie stattdessen Ihre Echtzeittabelle auswählen.

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

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

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

  9. Klicken Sie abschließend auf Bericht erstellen, um eine Kopie der Dashboardvorlage Crashlytics Looker Studio zu erstellen.


Crashlytics-Schema in BigQuery

Firebase Crashlytics-Daten werden in ein BigQuery-Dataset mit dem Namen firebase_crashlytics exportiert. Das Dataset deckt das gesamte Projekt ab, selbst wenn dieses mehrere Apps umfasst.

Tabellen

Standardmäßig erstellt Firebase für jede App in Ihrem Projekt, die mit BigQuery verknüpft ist, separate Tabellen im Dataset Crashlytics. Die Tabellen werden nach der ID der App benannt. Dabei werden Punkte in Unterstriche umgewandelt und die Plattform der App (_IOS oder _ANDROID) wird angehängt. Daten für eine Android-App mit dem Paketnamen com.google.test befinden sich beispielsweise in einer Tabelle mit dem Namen com_google_test_ANDROID.

Wenn Sie den Crashlytics-Streaming-Export nach BigQuery aktivieren, werden Crashlytics-Daten auch in Echtzeit in eine Tabelle gestreamt, an die _REALTIME angehängt wird (z. B. com_google_test_ANDROID_REALTIME).

Jede Zeile in einer Tabelle stellt ein Ereignis dar, das in der App aufgetreten ist, einschließlich Abstürzen, nicht schwerwiegenden Fehlern und ANR-Fehlern.

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 Crashlytics-Streaming-Export nach BigQuery aktiviert ist, hat die Echtzeittabelle dieselben Spalten wie die Batchtabelle. Beachten Sie, dass es in Zeilen Spalten geben kann, die Ereignisse ohne Stacktraces darstellen.

Hier sind die Spalten in der Tabelle für die exportierten Crashlytics-Daten aufgeführt:

Feldname Datentyp Beschreibung
app_orientation STRING Beispiele: PORTRAIT, LANDSCAPE, FACE_UP, FACE_DOWN usw.
application DATENSATZ Die App, durch die das Ereignis hervorgerufen wurde
application.build_version STRING Die Build-Version der App
application.display_version STRING
blame_frame DATENSATZ Der Frame, der als Ursache des Absturzes oder Fehlers identifiziert wurde
blame_frame.address INT64 Die Adresse im Binärbild, die den Code
enthält. Für Java-Frames nicht festgelegt.
blame_frame.blamed BOOLEAN Gibt an, ob Crashlytics festgestellt hat, dass dieser Frame die Ursache des Absturzes oder Fehlers ist.
blame_frame.file STRING Der Name der Frame-Datei
blame_frame.library STRING Der Anzeigename der Bibliothek, die den Frame enthält
blame_frame.line INT64 Die Zeilennummer der Datei des Frames
blame_frame.offset INT64 Der Byte-Offset im binären Image, das den Code enthält
Für Java-Ausnahmen nicht festgelegt
blame_frame.owner STRING Beispiel: DEVELOPER, VENDOR, RUNTIME, PLATFORM oder SYSTEM
blame_frame.symbol STRING Das Symbol mit Platzhaltern oder das Rohsymbol, wenn es nicht mit Platzhaltern versehen werden kann
breadcrumbs WIEDERHOLTE AUFZEICHNUNG Zeitstempel für Google Analytics-Navigationspfade, sofern aktiviert
breadcrumbs.name STRING Der Name, der mit dem Breadcrumb verknüpft ist
breadcrumbs.params WIEDERHOLTE AUFZEICHNUNG Parameter, die mit dem Breadcrumb verknüpft sind
breadcrumbs.params.key STRING Ein Parameterschlüssel, der dem Breadcrumb zugeordnet ist
breadcrumbs.params.value STRING Ein Parameterwert, der dem Breadcrumb zugeordnet ist
breadcrumbs.timestamp TIMESTAMP Der Zeitstempel, der dem Breadcrumb zugeordnet ist
bundle_identifier STRING Die eindeutige Kennung der App, wie sie im Firebase-Projekt registriert ist (z. B. com.google.gmail)
Bei Apps für Apple-Plattformen ist dies die Bundle-ID der App.
Bei Android-Apps ist dies der Paketname der App.
crashlytics_sdk_versions STRING Die Crashlytics-SDK-Version, die das Ereignis generiert hat
custom_keys WIEDERHOLTE AUFZEICHNUNG Von Entwicklern definierte Schlüssel/Wert-Paare
custom_keys.key STRING Ein vom Entwickler definierter Schlüssel
custom_keys.value STRING Ein vom Entwickler definierter Wert
device DATENSATZ Das Gerät, auf dem das Ereignis aufgetreten ist
device_orientation STRING Beispiele: PORTRAIT, LANDSCAPE, FACE_UP, FACE_DOWN usw.
device.architecture STRING Beispiel: X86_32, X86_64, ARMV7, ARM64, ARMV7S oder ARMV7K
device.manufacturer STRING Der Gerätehersteller
device.model STRING Das Gerätemodell
error WIEDERHOLTE AUFZEICHNUNG (Nur Apple-Apps) Nicht schwerwiegende Fehler
error_type STRING Der Fehlertyp des Ereignisses, z. B. FATAL, NON_FATAL oder ANR.
error.blamed BOOLEAN Gibt an, ob Crashlytics festgestellt hat, dass dieser Frame die Ursache des Fehlers ist.
error.code INT64 Fehlercode, der dem benutzerdefinierten protokollierten NSError der App zugeordnet ist
error.frames WIEDERHOLTE AUFZEICHNUNG Die Frames des Stacktrace
error.frames.address INT64 Die Adresse im Binärbild, die den Code enthält
error.frames.blamed BOOLEAN Gibt an, ob Crashlytics festgestellt hat, dass dieser Frame die Ursache des Fehlers ist.
error.frames.file STRING Der Name der Frame-Datei
error.frames.library STRING Der Anzeigename der Bibliothek, die den Frame enthält
error.frames.line INT64 Die Zeilennummer der Datei des Frames
error.frames.offset INT64 Der Byte-Offset in das binäre Image, das den Code enthält
error.frames.owner STRING Beispiel: DEVELOPER, VENDOR, RUNTIME, PLATFORM oder SYSTEM
error.frames.symbol STRING Das Symbol mit Platzhaltern oder das Rohsymbol, wenn es nicht mit Platzhaltern versehen werden kann
error.queue_name STRING Die Warteschlange, in der der Thread ausgeführt wurde
error.subtitle STRING Der Untertitel des Threads
error.title STRING Der Titel des Threads
event_id STRING Die eindeutige ID für das Ereignis
event_timestamp TIMESTAMP Zeitpunkt des Ereignisses
exceptions WIEDERHOLTE AUFZEICHNUNG (Nur Android) Ausnahmen, die während dieses Ereignisses aufgetreten sind. Verschachtelte Ausnahmen werden in umgekehrter chronologischer Reihenfolge dargestellt. Das bedeutet, dass der letzte Datensatz die erste ausgelöste Ausnahme ist.
exceptions.blamed BOOLEAN Wahr, wenn Crashlytics feststellt, dass die Ausnahme für den Fehler oder Absturz verantwortlich ist.
exceptions.exception_message STRING Eine Nachricht, die mit der Ausnahme verknüpft ist
exceptions.frames WIEDERHOLTE AUFZEICHNUNG Die mit der Ausnahme verknüpften Frames
exceptions.frames.address INT64 Die Adresse im Binärbild, die den Code
enthält. Für Java-Frames nicht festgelegt.
exceptions.frames.blamed BOOLEAN Gibt an, ob Crashlytics festgestellt hat, dass dieser Frame die Ursache des Absturzes oder Fehlers ist.
exceptions.frames.file STRING Der Name der Frame-Datei
exceptions.frames.library STRING Der Anzeigename der Bibliothek, die den Frame enthält
exceptions.frames.line INT64 Die Zeilennummer der Datei des Frames
exceptions.frames.offset INT64 Der Byte-Offset im binären Image, das den Code enthält
Für Java-Ausnahmen nicht festgelegt
exceptions.frames.owner STRING Beispiel: DEVELOPER, VENDOR, RUNTIME, PLATFORM oder SYSTEM
exceptions.frames.symbol STRING Das Symbol mit Platzhaltern oder das Rohsymbol, wenn es nicht mit Platzhaltern versehen werden kann
exceptions.nested BOOLEAN Wahr für alle außer der zuletzt ausgelösten Ausnahme (d. h. dem ersten Datensatz)
exceptions.subtitle STRING Der Untertitel des Threads
exceptions.title STRING Der Titel des Threads
exceptions.type STRING Der Ausnahmetyp (z. B. java.lang.IllegalStateException))
installation_uuid STRING Eine ID, die eine eindeutige App- und Geräteinstallation identifiziert
is_fatal BOOLEAN Gibt an, ob die App abgestürzt ist.
issue_id STRING Das mit dem Ereignis verknüpfte Problem
logs WIEDERHOLTE AUFZEICHNUNG Zeitgestempelte Log-Nachrichten, die vom Crashlytics-Logger generiert werden, sofern aktiviert
logs.message STRING Die protokollierte Nachricht
logs.timestamp TIMESTAMP Wann das Log erstellt wurde
memory DATENSATZ Speicherstatus des Geräts
memory.free INT64 Verbleibende Arbeitsspeicherbytes
memory.used INT64 Verwendete Arbeitsspeicher-Bytes
operating_system DATENSATZ Details zum Betriebssystem auf dem Gerät
operating_system.device_type STRING Der Gerätetyp (z. B. MOBILE, TABLET oder TV), auch als „Gerätekategorie“ bezeichnet
operating_system.display_version STRING Die Version des Betriebssystems auf dem Gerät
operating_system.modification_state STRING Gibt an, ob das Gerät manipuliert wurde (z. B. eine App mit Jailbreak ist MODIFIED und eine gerootete App ist UNMODIFIED).
operating_system.name STRING Der Name des Betriebssystems auf dem Gerät
operating_system.type STRING (Nur Apple-Apps) Der Typ des Betriebssystems, das auf dem Gerät ausgeführt wird (z. B. IOS, MACOS usw.)
platform STRING Die Plattform der App, wie sie im Firebase-Projekt registriert ist (gültige Werte: IOS oder ANDROID)
process_state STRING BACKGROUND oder FOREGROUND
storage DATENSATZ Der nichtflüchtige Speicher des Geräts
storage.free INT64 Verbleibende Bytes des Speicherplatzes
storage.used INT64 Genutzter Speicherplatz in Bytes
threads WIEDERHOLTE AUFZEICHNUNG Threads, die zum Zeitpunkt des Ereignisses vorhanden waren
threads.blamed BOOLEAN Gibt an, ob Crashlytics festgestellt hat, dass dieser Frame die Ursache des Absturzes oder Fehlers ist.
threads.code INT64 (Nur Apple-Apps) Fehlercode des benutzerdefinierten protokollierten NSError der Anwendung
threads.crash_address INT64 Die Adresse des Signals, das den Absturz der Anwendung verursacht hat. Ist nur bei abgestürzten nativen Threads vorhanden.
threads.crashed BOOLEAN Ob der Thread abgestürzt ist
threads.frames WIEDERHOLTE AUFZEICHNUNG Die Frames des Threads
threads.frames.address INT64 Die Adresse im Binärbild, die den Code enthält
threads.frames.blamed BOOLEAN Gibt an, ob Crashlytics festgestellt hat, dass dieser Frame die Ursache des Fehlers ist.
threads.frames.file STRING Der Name der Frame-Datei
threads.frames.library STRING Der Anzeigename der Bibliothek, die den Frame enthält
threads.frames.line INT64 Die Zeilennummer der Datei des Frames
threads.frames.offset INT64 Der Byte-Offset in das binäre Image, das den Code enthält
threads.frames.owner STRING Beispiel: DEVELOPER, VENDOR, RUNTIME, PLATFORM oder SYSTEM
threads.frames.symbol STRING Das Symbol mit Platzhaltern oder das Rohsymbol, wenn es nicht mit Platzhaltern versehen werden kann
threads.queue_name STRING (Nur Apple-Apps) Die Warteschlange, in der der Thread ausgeführt wurde
threads.signal_code STRING Der Code des Signals, das den Absturz der App verursacht hat. Ist nur bei abgestürzten nativen Threads vorhanden.
threads.signal_name STRING Der Name des Signals, das zum Absturz der App geführt hat. Ist nur bei abgestürzten nativen Threads vorhanden.
threads.subtitle STRING Der Untertitel des Threads
threads.thread_name STRING Der Name des Threads
threads.title STRING Der Titel des Threads
unity_metadata.debug_build BOOLEAN Wenn es sich um einen Debug-Build handelt
unity_metadata.graphics_copy_texture_support STRING Unterstützung für das Kopieren von Grafiktexturen gemäß der Unity API
unity_metadata.graphics_device_id INT64 Die Kennung des Grafikgeräts
unity_metadata.graphics_device_name STRING Der Name des Grafikgeräts
unity_metadata.graphics_device_type STRING Der Typ des Grafikgeräts
unity_metadata.graphics_device_vendor_id INT64 Die Kennung des Anbieters des Grafikprozessors
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_max_texture_size INT64 Maximale Größe für das Rendern von Texturen
unity_metadata.graphics_memory_size_mb INT64 Grafikspeicher in MB
unity_metadata.graphics_render_target_count INT64 Die Anzahl der grafischen Rendering-Ziele
unity_metadata.graphics_shader_level INT64 Die Shader-Ebene der Grafik
unity_metadata.processor_count INT64 Anzahl der Prozessoren (Kerne)
unity_metadata.processor_frequency_mhz INT64 Die Frequenz des Prozessors bzw. der Prozessoren in MHz
unity_metadata.processor_type STRING Prozessortyp
unity_metadata.screen_refresh_rate_hz INT64 Die Aktualisierungsrate des Displays in Hz
unity_metadata.screen_resolution_dpi STRING Die DPI des Bildschirms als Gleitkommazahl
unity_metadata.screen_size_px STRING Die Größe des Bildschirms in Pixeln im Format „Breite × Höhe“
unity_metadata.system_memory_size_mb INT64 Größe des Systemspeichers in MB
unity_metadata.unity_version STRING Die Unity-Version, die auf diesem Gerät ausgeführt wird
user DATENSATZ (Optional) Informationen, die über den Nutzer der App erhoben werden
user.email STRING (Optional) Die E-Mail-Adresse des Nutzers
user.id STRING (Optional) Eine appspezifische ID, die mit dem Nutzer verknüpft ist
user.name STRING (Optional): Der Name des Nutzers
variant_id STRING Die mit diesem Ereignis verknüpfte Problemvariante
Hinweis: Nicht alle Ereignisse haben eine zugehörige Problemvariante.


Auf die neue Exportinfrastruktur umstellen

Mitte Oktober 2024 hat Crashlytics eine neue Infrastruktur für den Batch-Export von Crashlytics-Daten in BigQuery eingeführt.

Alle Firebase-Projekte werden bereits am 15. September 2025 automatisch auf die neue Infrastruktur für den Batchexport aktualisiert. Sie können vor diesem Datum ein Upgrade durchführen. Achten Sie jedoch darauf, dass Ihre BigQuery-Batchtabellen die Voraussetzungen für ein Upgrade erfüllen.

Sie können ein Upgrade auf die neue Infrastruktur durchführen. Achten Sie jedoch darauf, dass Ihre BigQuery-Batchtabellen die Voraussetzungen für das Upgrade erfüllen.

Prüfen, ob Sie die neue Infrastruktur nutzen

Wenn Sie den Batch-Export Mitte Oktober 2024 oder später aktiviert haben, wird in Ihrem Firebase-Projekt automatisch die neue Exportinfrastruktur verwendet.

So können Sie prüfen, welche Infrastruktur für Ihr Projekt verwendet wird: Rufen Sie die Google Cloud-Konsole auf. Wenn Ihre Konfiguration für die Datenübertragung mit Firebase Crashlytics with Multi-Region Support gekennzeichnet ist, wird für Ihr Projekt die neue Exportinfrastruktur verwendet.

Wichtige Unterschiede zwischen der alten und der neuen Exportinfrastruktur

  • Die neue Infrastruktur unterstützt Crashlytics-Dataset-Standorte außerhalb der USA.

    • Der Export wurde vor Mitte Oktober 2024 aktiviert und auf die neue Exportinfrastruktur aktualisiert: Sie können jetzt optional den Speicherort für den Datenexport ändern.

    • Export ab Mitte Oktober 2024 aktiviert: Bei der Einrichtung wurden Sie aufgefordert, einen Speicherort für den Datenexport auszuwählen.

  • Die neue Infrastruktur unterstützt keine Backfills von Daten aus der Zeit vor der Aktivierung des Exports.

    • In der alten Infrastruktur war ein Backfill bis zu 30 Tage vor dem Datum möglich, an dem Sie den Export aktiviert haben.

    • Die neue Infrastruktur unterstützt Backfills bis zu den letzten 30 Tagen oder bis zum letzten Datum, an dem Sie den Export nach BigQuery aktiviert haben (je nachdem, was zuletzt war).

  • Die neuen Infrastrukturnamen BigQuery Batch-Tabellen mit den Kennungen, die für Ihre Firebase-Apps in Ihrem Firebase-Projekt festgelegt sind.

    • In der alten Infrastruktur wurden Daten in Batchtabellen mit Namen geschrieben, die auf den Paket-IDs oder Paketnamen im Binärcode Ihrer App basierten.

    • In der neuen Infrastruktur werden Daten in Batchtabellen geschrieben, deren Namen auf den Paket-IDs oder Paketnamen basieren, die für Ihre registrierten Firebase-Apps in Ihrem Firebase-Projekt festgelegt sind.

Schritt 1: Voraussetzungen für das Upgrade

  1. Prüfen Sie, ob in Ihren vorhandenen BigQuery-Batchtabellen dieselben Kennungen wie die Paket-IDs oder Paketnamen verwendet werden, die für Ihre registrierten Firebase-Apps in Ihrem Firebase-Projekt festgelegt sind. Wenn sie nicht übereinstimmen, kann es zu Unterbrechungen bei den exportierten Batchdaten kommen. Die meisten Projekte sind in einem geeigneten und kompatiblen Zustand. Es ist jedoch wichtig, dies vor dem Upgrade zu prüfen.

    • Alle in Ihrem Firebase-Projekt registrierten Firebase-Apps finden Sie in der Firebase Console: Rufen Sie die Projekteinstellungen auf und scrollen Sie dann zur Karte Ihre Apps, um alle Ihre Firebase-Apps und die zugehörigen Informationen zu sehen.

    • Alle Ihre BigQuery-Batchtabellen finden Sie in der BigQuery-Seite der Google Cloud-Konsole.

    Hier sind einige Beispiele für ideale Zustände, in denen beim Upgrade keine Probleme auftreten:

    • Sie haben eine Batchtabelle mit dem Namen com_yourcompany_yourproject_IOS und eine Firebase iOS+-App mit der Bundle-ID com.yourcompany.yourproject, die in Ihrem Firebase-Projekt registriert ist.

    • Sie haben eine Batchtabelle mit dem Namen com_yourcompany_yourproject_ANDROID und eine Firebase-Android-App mit dem Paketnamen com.yourcompany.yourproject, die in Ihrem Firebase-Projekt registriert ist.

  2. Wenn Sie Batchtabellennamen haben, die nicht mit den für Ihre registrierten Firebase-Apps festgelegten Kennungen übereinstimmen, folgen Sie der Anleitung auf dieser Seite vor dem manuellen Upgrade oder vor dem 15. September 2025, um Unterbrechungen des Batchexports zu vermeiden.

Schritt 2: Manuelles Upgrade auf die neue Infrastruktur

Wenn Sie den Batch-Export vor Mitte Oktober 2024 aktiviert haben, können Sie manuell auf die neue Infrastruktur umstellen, indem Sie den Crashlytics-Datenexport in der Firebase-Konsole deaktivieren und dann wieder aktivieren.

So gehts:

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

  2. Klicken Sie auf der Karte BigQuery auf Verwalten.

  3. Deaktivieren Sie den Schieberegler Crashlytics, um den Export zu deaktivieren. Bestätige, dass du den Datenexport beenden möchtest.

  4. Aktivieren Sie den Schieberegler Crashlytics sofort wieder, um den Export wieder zu aktivieren. Bestätige, dass du Daten exportieren möchtest.

    Ihr Crashlytics-Datenexport nach BigQuery erfolgt jetzt über die neue Exportinfrastruktur.

Der Name Ihrer vorhandenen Batchtabelle stimmt nicht mit der Kennung Ihrer Firebase-App überein.