Esporta i dati di Firebase Crashlytics in BigQuery

Puoi esportare i tuoi dati di Firebase Crashlytics in BigQuery per un'analisi più approfondita. BigQuery ti consente di analizzare i dati utilizzando BigQuery SQL, esportarli in un altro provider cloud e utilizzarli per la visualizzazione e le dashboard personalizzate con Looker Studio.

Che cosa puoi fare con i dati esportati?

Le esportazioni in BigQuery contengono dati sugli arresti anomali non elaborati, tra cui tipo di dispositivo, sistema operativo, eccezioni (app Android) o errori (app Apple) e log Crashlytics, nonché altri dati. Puoi esaminare esattamente quali dati Crashlyticsvengono esportati e il relativo schema della tabella più avanti in questa pagina.

Ecco alcuni esempi di ciò che puoi fare con i dati Crashlytics esportati:

  • Esegui query
    Puoi eseguire query sui dati di Crashlytics per generare report che aggregano i dati degli eventi di arresto anomalo in riepiloghi più facilmente comprensibili. Poiché questi tipi di report non sono disponibili nella dashboard Crashlytics della console Firebase, possono integrare l'analisi e la comprensione dei dati sugli arresti anomali. Più avanti in questa pagina, troverai una selezione di query di esempio.

  • Utilizza un Looker Studio modello
    Crashlytics fornisce un modello Looker Studio predefinito per visualizzare i dati esportati.

  • Crea viste
    Utilizzando l'interfaccia utente di BigQuery, puoi creare una "vista", ovvero una tabella virtuale definita da una query SQL. Per istruzioni dettagliate sui diversi tipi di viste e su come crearle, consulta la documentazione di BigQuery.

Esportazione streaming di Crashlytics in BigQuery

Puoi trasmettere in streaming i tuoi dati Crashlytics in tempo reale con lo streaming BigQuery. Puoi utilizzarlo per qualsiasi scopo che richieda dati in tempo reale, ad esempio per presentare informazioni in una dashboard in tempo reale, guardare un rollout in diretta o monitorare i problemi delle applicazioni che attivano avvisi e flussi di lavoro personalizzati.

Quando abiliti l'esportazione streaming Crashlytics in BigQuery, oltre alla tabella batch avrai anche una tabella in tempo reale. Ecco le differenze da tenere presenti tra le tabelle:

Tabella batch Tabella in tempo reale
  • I dati vengono esportati una volta al giorno.
  • Gli eventi vengono archiviati in modo permanente prima della scrittura batch in BigQuery.
  • I dati possono essere riempiti fino a 30 giorni prima*.
  • I dati vengono esportati in tempo reale.
  • Non è disponibile alcun backfill.

La tabella batch è ideale per l'analisi a lungo termine e l'identificazione delle tendenze nel tempo perché archiviamo in modo permanente gli eventi prima di scriverli e possono essere riempiti nella tabella per un massimo di 30 giorni*. Quando scriviamo i dati nella tabella in tempo reale, li scriviamo immediatamente in BigQuery, quindi è ideale per dashboard live e avvisi personalizzati. Queste due tabelle possono essere combinate con una query di unione per ottenere i vantaggi di entrambe.

Per impostazione predefinita, la tabella in tempo reale ha un periodo di scadenza delle partizioni di 30 giorni. Per scoprire come modificarlo, consulta Impostare la scadenza della partizione nella documentazione di BigQuery.

* Consulta i dettagli sul supporto del backfill in Esegui l'upgrade alla nuova infrastruttura di esportazione.


Abilita l'esportazione in BigQuery

  1. Nella console Firebase, vai alla pagina Integrazioni.

  2. Nella scheda BigQuery, fai clic su Collega.

  3. Segui le istruzioni sullo schermo per attivare l'esportazione su BigQuery.

    Se vuoi accedere ai tuoi dati Crashlytics in BigQuery quasi in tempo reale, valuta l'upgrade all'esportazione streaming.

Abilita l'esportazione dello streaming di Crashlytics in BigQuery

  1. Nella console Firebase, vai alla pagina Integrazioni.

  2. Nella scheda BigQuery, fai clic su Gestisci.

  3. Seleziona la casella di controllo Includi streaming.

Questa azione attiva lo streaming per tutte le app collegate.

Che cosa succede quando attivi l'esportazione?

  • Selezioni la posizione del set di dati. Dopo la creazione del set di dati, la località non può essere modificata, ma puoi copiare il set di dati in un'altra località o spostare (ricreare) manualmente il set di dati in un'altra località. Per saperne di più, consulta Modificare la posizione per le esportazioni esistenti.

    Questa posizione è applicabile solo ai dati esportati in BigQuery e non influisce sulla posizione dei dati archiviati per l'utilizzo nella dashboard Crashlytics della console Firebase o in Android Studio.

  • Per impostazione predefinita, tutte le app del progetto sono collegate a BigQuery e qualsiasi app che aggiungi in seguito viene collegata automaticamente a BigQuery. Puoi gestire le app che inviano dati.

  • Firebase configura sincronizzazioni giornaliere dei tuoi dati con BigQuery.

    • Dopo aver collegato il progetto, in genere devi attendere la sincronizzazione del giorno successivo prima che il primo set di dati venga esportato in BigQuery.

    • La sincronizzazione giornaliera avviene una volta al giorno, indipendentemente da qualsiasi esportazione pianificata che potresti aver configurato in BigQuery. Tieni presente che la tempistica e la durata del job di sincronizzazione possono cambiare, pertanto non consigliamo di pianificare operazioni o job downstream in base a una tempistica specifica dell'esportazione.

  • Firebase esporta una copia dei tuoi dati esistenti in BigQuery. La propagazione iniziale dei dati per l'esportazione potrebbe richiedere fino a 48 ore.

    • Per ogni app collegata, questa esportazione include una tabella batch contenente i dati della sincronizzazione giornaliera.

    • Puoi pianificare manualmente i backfill dei dati per la tabella batch fino agli ultimi 30 giorni o per la data più recente in cui hai attivato l'esportazione in BigQuery (a seconda di quale sia la più recente).

    Tieni presente che se hai attivato l'esportazione dei dati Crashlytics prima di metà ottobre 2024, puoi anche eseguire il backfill dei 30 giorni precedenti al giorno in cui hai attivato l'esportazione.

  • Se attivi Crashlyticsl'esportazione streaming in BigQuery, anche tutte le app collegate avranno una tabella in tempo reale contenente dati in costante aggiornamento.

Per disattivare l'esportazione in BigQuery, scollega il progetto nella console Firebase.


Esempi di query

Esempio 1: arresti anomali per giorno

Dopo aver lavorato per correggere il maggior numero possibile di bug, ritieni che il tuo team sia finalmente pronto per lanciare la nuova app di condivisione di foto. Prima di farlo, vuoi controllare il numero di arresti anomali al giorno nell'ultimo mese, per assicurarti che il bug bash abbia reso l'app più stabile nel tempo.

Ecco una query di esempio per un'app per Android. Per un'app per iOS, utilizza l'ID pacchetto e IOS (anziché il nome del pacchetto e 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;

Esempio 2: trova gli arresti anomali più pervasivi

Per dare la giusta priorità ai piani di produzione, vuoi trovare i 10 arresti anomali più pervasivi nella tua app. Produci una query che fornisca i punti di dati pertinenti.

Ecco una query di esempio per un'app per Android. Per un'app per iOS, utilizza l'ID pacchetto e IOS (anziché il nome del pacchetto e 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;

Esempio 3: i 10 dispositivi con il maggior numero di arresti anomali

L'autunno è la stagione dei nuovi smartphone. La tua azienda sa che questo significa anche che è arrivata la stagione dei nuovi problemi specifici dei dispositivi, soprattutto per Android. Per prevenire i problemi di compatibilità imminenti, hai creato una query che identifica i 10 dispositivi che hanno subito il maggior numero di arresti anomali nell'ultima settimana (168 ore).

Ecco una query di esempio per un'app per Android. Per un'app per iOS, utilizza l'ID pacchetto e IOS (anziché il nome del pacchetto e 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;

Esempio 4: filtra per chiave personalizzata

Sei uno sviluppatore di giochi che vuole sapere quale livello del tuo gioco subisce il maggior numero di arresti anomali.

Per monitorare questa statistica, imposti una chiave Crashlytics personalizzata chiamata current_level e la aggiorni ogni volta che l'utente raggiunge un nuovo livello.

Swift

Crashlytics.sharedInstance().setIntValue(3, forKey: "current_level");

Objective-C

CrashlyticsKit setIntValue:3 forKey:@"current_level";

Java

Crashlytics.setInt("current_level", 3);

Con questa chiave nell'esportazione in BigQuery, puoi scrivere una query per generare un report sulla distribuzione dei valori current_level associati a ogni evento di arresto anomalo.

Ecco una query di esempio per un'app per Android. Per un'app per iOS, utilizza l'ID pacchetto e IOS (anziché il nome del pacchetto e 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

Esempio 5: estrazione dell'ID utente

Hai un'app per Android in accesso in anteprima. La maggior parte dei tuoi utenti lo adora, ma tre hanno riscontrato un numero insolito di arresti anomali. Per risolvere il problema, scrivi una query che estrae tutti gli eventi di arresto anomalo per questi utenti, utilizzando i loro ID utente.

Ecco una query di esempio per un'app per Android. Per un'app per iOS, utilizza l'ID pacchetto e IOS (anziché il nome del pacchetto e 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

Esempio 6: trova tutti gli utenti che riscontrano un determinato problema di arresto anomalo

Il tuo team ha rilasciato per errore un bug critico a un gruppo di beta tester. Il tuo team è riuscito a utilizzare la query dell'esempio "Trova gli arresti anomali più pervasivi" riportato sopra per identificare l'ID problema di arresto anomalo specifico. Ora il tuo team vuole eseguire una query per estrarre l'elenco degli utenti dell'app interessati da questo arresto anomalo.

Ecco una query di esempio per un'app per Android. Per un'app per iOS, utilizza l'ID pacchetto e IOS (anziché il nome del pacchetto e 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;

Esempio 7: numero di utenti interessati da un problema di arresto anomalo, suddivisi per paese

Il tuo team ha rilevato un bug critico durante l'implementazione di una nuova release. Hai potuto utilizzare la query dell'"Esempio Trova arresti anomali più pervasivi" sopra per identificare l'ID problema di arresto anomalo specifico. Il tuo team vorrebbe ora verificare se questo arresto anomalo si è diffuso tra gli utenti di diversi paesi in tutto il mondo.

Per scrivere questa query, il tuo team dovrà:

  1. Attiva l'esportazione dei dati di Google Analytics in BigQuery. Consulta Esportare i dati del progetto in BigQuery.

  2. Aggiorna la tua app per trasmettere un ID utente sia all'SDK Google Analytics sia all'SDK Crashlytics.

    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. Scrivi una query che utilizzi il campo ID utente per unire gli eventi nel set di dati Google Analytics con gli arresti anomali nel set di dati Crashlytics.

    Ecco un esempio di query per un'app per Android. Per un'app per iOS, utilizza l'ID pacchetto e IOS (anziché il nome del pacchetto e 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

Esempio 8: i 5 problemi principali finora oggi

Ecco una query di esempio per un'app per Android. Per un'app per iOS, utilizza l'ID pacchetto e IOS (anziché il nome del pacchetto e 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;

Esempio 9: i 5 problemi principali a partire da DATE, incluso oggi

Puoi anche combinare le tabelle batch e in tempo reale con una query di unione per aggiungere informazioni in tempo reale ai dati batch affidabili. Poiché event_id è una chiave primaria, puoi utilizzare DISTINCT event_id per deduplicare gli eventi comuni delle due tabelle.

Ecco una query di esempio per un'app per Android. Per un'app per iOS, utilizza l'ID pacchetto e IOS (anziché il nome del pacchetto e 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;


Visualizzare i dati di Crashlytics esportati con Looker Studio

Looker Studio trasforma i tuoi set di dati Crashlytics in BigQuery in report più facili da leggere, condividere e personalizzare.

Per scoprire di più sull'utilizzo di Looker Studio, consulta la guida di benvenuto.

Utilizzare un modello di report Crashlytics

Looker Studio ha un report di esempio per Crashlytics che include un insieme completo di dimensioni e metriche dello schema Crashlytics BigQuery esportato. Se hai attivato l'esportazione in streaming su BigQuery, puoi visualizzare i dati nella pagina Tendenze in tempo reale del modello Looker Studio.Puoi utilizzare l'esempio come modello per creare rapidamente nuovi report e visualizzazioni in base ai dati non elaborati sugli arresti anomali della tua app:Crashlytics

  1. Apri il modello dashboard Crashlytics Looker Studio.

  2. Fai clic su Utilizza modello nell'angolo in alto a destra.

  3. Nel menu a discesa Nuova origine dati, seleziona Crea nuova origine dati.

  4. Fai clic su Seleziona nella scheda BigQuery.

  5. Seleziona una tabella contenente i dati Crashlytics esportati scegliendo I miei progetti > PROJECT_ID > firebase_crashlytics > TABLE_NAME.

    La tabella batch è sempre disponibile per la selezione. Se l'esportazione streaming in BigQuery è attivata, puoi selezionare la tabella in tempo reale.Crashlytics

  6. In Configurazione, imposta Livello modello Crashlytics su Predefinito.

  7. Fai clic su Connetti per creare la nuova origine dati.

  8. Fai clic su Aggiungi al report per tornare al modello Crashlytics.

  9. Infine, fai clic su Crea report per creare la tua copia del modello di dashboard Crashlytics Looker Studio.


Comprendere lo schema Crashlytics in BigQuery

I dati Firebase Crashlytics vengono esportati in un set di dati BigQuery denominato firebase_crashlytics. Il set di dati copre l'intero progetto, anche se contiene più app.

Tabelle

Per impostazione predefinita, Firebase crea tabelle individuali all'interno del set di dati Crashlytics per ogni app del tuo progetto collegata a BigQuery. Le tabelle vengono denominate in base all'identificatore dell'app (con i punti convertiti in trattini bassi) e viene aggiunto il nome della piattaforma dell'app (_IOS o _ANDROID). Ad esempio, i dati di un'app per Android con il nome del pacchetto com.google.test si troveranno in una tabella denominata com_google_test_ANDROID.

Se attivi l'esportazione dello streaming Crashlytics in BigQuery, i dati Crashlytics verranno trasmessi in streaming in tempo reale anche a una tabella a cui è stato aggiunto _REALTIME (ad esempio, com_google_test_ANDROID_REALTIME).

Ogni riga di una tabella rappresenta un evento che si è verificato nell'app, inclusi arresti anomali, errori non irreversibili e ANR.

Le tabelle contengono un insieme standard di dati Crashlytics oltre a eventuali chiavi Crashlytics personalizzate definite dall'utente nella sua app.

Righe

Ogni riga di una tabella rappresenta un errore riscontrato dall'app.

Colonne

Le colonne di una tabella sono identiche per arresti anomali, errori non irreversibili e ANR. Se l'esportazione in streaming in BigQuery è abilitata, la tabella in tempo reale avrà le stesse colonne della tabella batch.Crashlytics Tieni presente che potresti avere colonne in righe che rappresentano eventi senza stack trace.

Di seguito sono riportate le colonne della tabella per i dati Crashlytics esportati:

Nome campo Tipo di dati Descrizione
platform STRING La piattaforma dell'app registrata nel progetto Firebase (valori validi: IOS o ANDROID)
bundle_identifier STRING L'identificatore univoco dell'app registrata nel progetto Firebase (ad esempio, com.google.gmail)
Per le app della piattaforma Apple, questo è l'ID bundle dell'app.
Per le app per Android, questo è il nome del pacchetto dell'app.
event_id STRING L'ID univoco dell'evento
is_fatal BOOLEAN Indica se l'app ha subito un arresto anomalo
error_type STRING Il tipo di errore dell'evento (ad esempio, FATAL, NON_FATAL, ANR e così via).
issue_id STRING Il problema associato all'evento
variant_id STRING La variante del problema associata a questo evento
Tieni presente che non tutti gli eventi hanno una variante del problema associata.
event_timestamp TIMESTAMP Quando si è verificato l'evento
device RECORD Il dispositivo su cui si è verificato l'evento
device.manufacturer STRING Il produttore del dispositivo
device.model STRING Il modello del dispositivo
device.architecture STRING Ad esempio, X86_32, X86_64, ARMV7, ARM64, ARMV7S o ARMV7K
memory RECORD Stato della memoria del dispositivo
memory.used INT64 Byte di memoria utilizzati
memory.free INT64 Byte di memoria rimanenti
storage RECORD Lo spazio di archiviazione permanente del dispositivo
storage.used INT64 Byte di spazio di archiviazione utilizzati
storage.free INT64 Byte di spazio di archiviazione rimanente
operating_system RECORD I dettagli del sistema operativo sul dispositivo
operating_system.display_version STRING La versione del sistema operativo sul dispositivo
operating_system.name STRING Il nome del sistema operativo sul dispositivo.
operating_system.modification_state STRING Indica se il dispositivo è stato modificato (ad esempio, un'app jailbroken è MODIFIED e un'app rooted è UNMODIFIED)
operating_system.type STRING (Solo app Apple) Il tipo di sistema operativo in esecuzione sul dispositivo (ad esempio, IOS, MACOS e così via).
operating_system.device_type STRING Il tipo di dispositivo (ad esempio MOBILE, TABLET, TV e così via), noto anche come "categoria del dispositivo".
application RECORD L'app che ha generato l'evento
application.build_version STRING Versione build dell'app
application.display_version STRING
user RECORD (Facoltativo) Informazioni raccolte sull'utente dell'app
user.name STRING (Facoltativo) Il nome dell'utente.
user.email STRING (Facoltativo) L'indirizzo email dell'utente
user.id STRING (Facoltativo) Un ID specifico dell'app associato all'utente
custom_keys REPEATED RECORD Coppie chiave-valore definite dallo sviluppatore
custom_keys.key STRING Una chiave definita dallo sviluppatore
custom_keys.value STRING Un valore definito dallo sviluppatore
installation_uuid STRING Un ID che identifica un'installazione unica di app e dispositivo
crashlytics_sdk_versions STRING La versione dell'SDK Crashlytics che ha generato l'evento
app_orientation STRING Ad esempio, PORTRAIT, LANDSCAPE, FACE_UP, FACE_DOWN e così via.
device_orientation STRING Ad esempio, PORTRAIT, LANDSCAPE, FACE_UP, FACE_DOWN e così via.
process_state STRING BACKGROUND o FOREGROUND
logs REPEATED RECORD Messaggi di log con timestamp generati dal logger Crashlytics, se abilitato
logs.timestamp TIMESTAMP Quando è stato creato il log
logs.message STRING Il messaggio registrato
breadcrumbs REPEATED RECORD Breadcrumb Google Analytics con timestamp, se abilitati
breadcrumbs.timestamp TIMESTAMP Il timestamp associato alla sequenza di breadcrumb
breadcrumbs.name STRING Il nome associato alla breadcrumb
breadcrumbs.params REPEATED RECORD Parametri associati alla breadcrumb
breadcrumbs.params.key STRING Una chiave parametro associata alla breadcrumb
breadcrumbs.params.value STRING Un valore del parametro associato alla breadcrumb
blame_frame RECORD Il frame identificato come causa principale dell'arresto anomalo o dell'errore
blame_frame.line INT64 Il numero di riga del file del frame
blame_frame.file STRING Il nome del file del frame
blame_frame.symbol STRING Il simbolo idratato o il simbolo non idratabile, se non è possibile idratarlo
blame_frame.offset INT64 L'offset di byte nell'immagine binaria che contiene il codice
Non impostato per le eccezioni Java
blame_frame.address INT64 L'indirizzo nell'immagine binaria che contiene il codice
Non impostato per i frame Java
blame_frame.library STRING Il nome visualizzato della libreria che include il frame
blame_frame.owner STRING Ad esempio, DEVELOPER, VENDOR, RUNTIME, PLATFORM o SYSTEM
blame_frame.blamed BOOLEAN Se Crashlytics ha stabilito che questo frame è la causa dell'arresto anomalo o dell'errore
exceptions REPEATED RECORD (Solo Android) Eccezioni che si sono verificate durante questo evento. Le eccezioni nidificate vengono presentate in ordine cronologico inverso, il che significa che l'ultimo record è la prima eccezione generata
exceptions.type STRING Il tipo di eccezione (ad esempio, java.lang.IllegalStateException)
exceptions.exception_message STRING Un messaggio associato all'eccezione
exceptions.nested BOOLEAN Vero per tutte le eccezioni tranne l'ultima (ovvero il primo record)
exceptions.title STRING Il titolo del thread
exceptions.subtitle STRING Il sottotitolo del thread
exceptions.blamed BOOLEAN True se Crashlytics determina che l'eccezione è responsabile dell'errore o dell'arresto anomalo
exceptions.frames REPEATED RECORD I frame associati all'eccezione
exceptions.frames.line INT64 Il numero di riga del file del frame
exceptions.frames.file STRING Il nome del file del frame
exceptions.frames.symbol STRING Il simbolo idratato o il simbolo non idratabile, se non è possibile idratarlo
exceptions.frames.offset INT64 L'offset di byte nell'immagine binaria che contiene il codice
Non impostato per le eccezioni Java
exceptions.frames.address INT64 L'indirizzo nell'immagine binaria che contiene il codice
Non impostato per i frame Java
exceptions.frames.library STRING Il nome visualizzato della libreria che include il frame
exceptions.frames.owner STRING Ad esempio, DEVELOPER, VENDOR, RUNTIME, PLATFORM o SYSTEM
exceptions.frames.blamed BOOLEAN Se Crashlytics ha stabilito che questo frame è la causa dell'arresto anomalo o dell'errore
error REPEATED RECORD (Solo app Apple) errori non irreversibili
error.queue_name STRING La coda su cui è stato eseguito il thread
error.code INT64 Codice di errore associato a NSError registrato personalizzato dell'app
error.title STRING Il titolo del thread
error.subtitle STRING Il sottotitolo del thread
error.blamed BOOLEAN Se Crashlytics ha determinato che questo frame è la causa dell'errore
error.frames REPEATED RECORD I frame dello stacktrace
error.frames.line INT64 Il numero di riga del file del frame
error.frames.file STRING Il nome del file del frame
error.frames.symbol STRING Il simbolo idratato o il simbolo non idratabile, se non è possibile idratarlo
error.frames.offset INT64 L'offset di byte nell'immagine binaria che contiene il codice
error.frames.address INT64 L'indirizzo nell'immagine binaria che contiene il codice
error.frames.library STRING Il nome visualizzato della libreria che include il frame
error.frames.owner STRING Ad esempio, DEVELOPER, VENDOR, RUNTIME, PLATFORM o SYSTEM
error.frames.blamed BOOLEAN Se Crashlytics ha determinato che questo frame è la causa dell'errore
threads REPEATED RECORD Thread presenti al momento dell'evento
threads.crashed BOOLEAN Se il thread è andato in crash
threads.thread_name STRING Il nome del thread
threads.queue_name STRING (Solo app Apple) La coda in cui è stato eseguito il thread
threads.signal_name STRING Il nome del segnale che ha causato l'arresto anomalo dell'app, presente solo nei thread nativi con arresto anomalo
threads.signal_code STRING Il codice del segnale che ha causato l'arresto anomalo dell'app; presente solo nei thread nativi arrestati in modo anomalo
threads.crash_address INT64 L'indirizzo del segnale che ha causato l'arresto anomalo dell'applicazione; presente solo nei thread nativi in arresto anomalo
threads.code INT64 (Solo app Apple) Codice di errore dell'NSError personalizzato registrato dell'applicazione
threads.title STRING Il titolo del thread
threads.subtitle STRING Il sottotitolo del thread
threads.blamed BOOLEAN Se Crashlytics ha stabilito che questo frame è la causa dell'arresto anomalo o dell'errore
threads.frames REPEATED RECORD I frame del thread
threads.frames.line INT64 Il numero di riga del file del frame
threads.frames.file STRING Il nome del file del frame
threads.frames.symbol STRING Il simbolo idratato o il simbolo grezzo se non è idratabile
threads.frames.offset INT64 L'offset di byte nell'immagine binaria che contiene il codice
threads.frames.address INT64 L'indirizzo nell'immagine binaria che contiene il codice
threads.frames.library STRING Il nome visualizzato della libreria che include il frame
threads.frames.owner STRING Ad esempio, DEVELOPER, VENDOR, RUNTIME, PLATFORM o SYSTEM
threads.frames.blamed BOOLEAN Se Crashlytics ha determinato che questo frame è la causa dell'errore
unity_metadata.unity_version STRING La versione di Unity in esecuzione su questo dispositivo
unity_metadata.debug_build BOOLEAN Se si tratta di una build di debug
unity_metadata.processor_type STRING Il tipo di processore
unity_metadata.processor_count INT64 Il numero di processori (core)
unity_metadata.processor_frequency_mhz INT64 La frequenza del processore o dei processori in MHz
unity_metadata.system_memory_size_mb INT64 Dimensioni della memoria del sistema in MB
unity_metadata.graphics_memory_size_mb INT64 La memoria video in MB
unity_metadata.graphics_device_id INT64 L'identificatore del dispositivo grafico
unity_metadata.graphics_device_vendor_id INT64 L'identificatore del fornitore del processore grafico
unity_metadata.graphics_device_name STRING Il nome del dispositivo grafico
unity_metadata.graphics_device_vendor STRING Il fornitore del dispositivo grafico
unity_metadata.graphics_device_version STRING La versione del dispositivo grafico
unity_metadata.graphics_device_type STRING Il tipo di dispositivo grafico
unity_metadata.graphics_shader_level INT64 Il livello di shader della grafica
unity_metadata.graphics_render_target_count INT64 Il numero di target di rendering grafici
unity_metadata.graphics_copy_texture_support STRING Supporto per la copia della texture grafica come definita nell'API Unity
unity_metadata.graphics_max_texture_size INT64 La dimensione massima dedicata al rendering della texture
unity_metadata.screen_size_px STRING Le dimensioni dello schermo in pixel, nel formato larghezza x altezza
unity_metadata.screen_resolution_dpi STRING Il DPI dello schermo come numero in virgola mobile
unity_metadata.screen_refresh_rate_hz INT64 La frequenza di aggiornamento dello schermo in Hz


Eseguire l'upgrade alla nuova infrastruttura di esportazione

A metà ottobre 2024, Crashlytics ha lanciato una nuova infrastruttura per l'esportazione batch dei dati Crashlytics in BigQuery.

L'upgrade automatico di tutti i progetti Firebase alla nuova infrastruttura di esportazione batch verrà eseguito a partire dal 15 settembre 2025. Puoi eseguire l'upgrade prima di questa data, ma assicurati che le tabelle batch BigQuery soddisfino i prerequisiti per l'upgrade.

Puoi eseguire l'upgrade alla nuova infrastruttura, ma assicurati che le tabelle batch BigQuery soddisfino i prerequisiti per l'upgrade.

Determinare se utilizzi la nuova infrastruttura

Se hai attivato l'esportazione batch a metà ottobre 2024 o in un secondo momento, il tuo progetto Firebase utilizza automaticamente la nuova infrastruttura di esportazione.

Puoi controllare quale infrastruttura utilizza il tuo progetto: vai alla console Google Cloud e, se la tua "configurazione del trasferimento dei dati" è etichettata Firebase Crashlytics with Multi-Region Support, il tuo progetto utilizza la nuova infrastruttura di esportazione.

Differenze importanti tra la vecchia e la nuova infrastruttura di esportazione

  • La nuova infrastruttura supporta le posizioni dei set di dati Crashlytics al di fuori degli Stati Uniti.

    • Esportazione abilitata prima di metà ottobre 2024 e aggiornata alla nuova infrastruttura di esportazione: ora puoi modificare facoltativamente la posizione per l'esportazione dei dati.

    • Esportazione attivata a metà ottobre 2024 o in un secondo momento: durante la configurazione ti è stato chiesto di selezionare una posizione per l'esportazione dei dati.

  • La nuova infrastruttura non supporta i backfill dei dati precedenti all'attivazione dell'esportazione.

    • La vecchia infrastruttura supportava il backfill fino a 30 giorni prima della data in cui hai attivato l'esportazione.

    • La nuova infrastruttura supporta i backfill fino agli ultimi 30 giorni o fino alla data più recente in cui hai attivato l'esportazione in BigQuery (a seconda di quale sia la data più recente).

  • I nuovi nomi dell'infrastruttura BigQuery tabelle batch utilizzando gli identificatori impostati per le tue app Firebase nel tuo progetto Firebase.

    • La vecchia infrastruttura scriveva i dati nelle tabelle batch con nomi basati sugli ID bundle o sui nomi dei pacchetti nella configurazione Firebase nel codebase della tua app.

    • La nuova infrastruttura scrive i dati nelle tabelle batch con nomi basati sugli ID bundle o sui nomi dei pacchetti impostati per le tue app Firebase registrate nel tuo progetto Firebase.

Passaggio 1: prerequisito per l'upgrade

  1. Verifica che le tabelle batch BigQuery esistenti utilizzino identificatori corrispondenti agli ID bundle o ai nomi dei pacchetti impostati per le tue app Firebase registrate nel tuo progetto Firebase. Se non corrispondono, potresti riscontrare interruzioni nei dati batch esportati. La maggior parte dei progetti si troverà in uno stato corretto e compatibile, ma è importante controllare prima dell'upgrade.

    • Puoi trovare tutte le app Firebase registrate nel tuo progetto Firebase nella console Firebase: vai alle Impostazioni progetto, poi scorri fino alla scheda Le tue app per visualizzare tutte le tue app Firebase e le relative informazioni.

    • Puoi trovare tutte le tabelle batch BigQuery nella pagina BigQuery della console Google Cloud.

    Ad esempio, ecco gli stati ideali in cui non avrai problemi con l'upgrade:

    • Hai una tabella batch denominata com_yourcompany_yourproject_IOS e un'app Firebase iOS+ con l'ID bundle com.yourcompany.yourproject registrata nel tuo progetto Firebase.

    • Hai una tabella batch denominata com_yourcompany_yourproject_ANDROID e un'app Firebase per Android con il nome del pacchetto com.yourcompany.yourproject registrata nel tuo progetto Firebase.

  2. Se i nomi delle tabelle batch non corrispondono agli identificatori impostati per le tue app Firebase registrate, segui le istruzioni riportate più avanti in questa pagina prima di eseguire l'upgrade manuale o prima del 15 settembre 2025 per evitare interruzioni dell'esportazione batch.

Passaggio 2: esegui l'upgrade manuale alla nuova infrastruttura

Se hai attivato l'esportazione batch prima di metà ottobre 2024, puoi eseguire manualmente l'upgrade alla nuova infrastruttura semplicemente attivando e disattivando l'esportazione dei dati Crashlytics nella console Firebase.

Ecco i passaggi dettagliati:

  1. Nella console Firebase, vai alla pagina Integrazioni.

  2. Nella scheda BigQuery, fai clic su Gestisci.

  3. Disattiva il cursore Crashlytics per disattivare l'esportazione. Quando richiesto, conferma che vuoi interrompere l'esportazione dei dati.

  4. Riattiva immediatamente il cursore Crashlytics per riattivare l'esportazione. Quando richiesto, conferma di voler esportare i dati.

    L'esportazione dei dati di Crashlytics in BigQuery ora utilizza la nuova infrastruttura di esportazione.

Il nome della tabella batch esistente non corrisponde all'identificatore dell'app Firebase