Esporta i dati di Firebase Crashlytics in BigQuery

Puoi esportare i dati di Firebase Crashlytics in BigQuery per ulteriori analisi. BigQuery ti consente di analizzare i dati utilizzando SQL di BigQuery, esportarli in un altro provider cloud e utilizzarli per la visualizzazione e le dashboard personalizzate con Google Data Studio.

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

    Se vuoi accedere ai dati di Crashlytics in BigQuery quasi in tempo reale, ti consigliamo di eseguire l'upgrade all'esportazione streaming.

Che cosa succede quando attivi l'esportazione?

  • Seleziona la posizione del set di dati. Dopo la creazione del set di dati, la località non può essere modificata, ma puoi copiarlo in un'altra posizione o spostarlo (ricrearlo) manualmente in un'altra posizione. Per saperne di più, consulta Modificare la posizione delle 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 nel progetto sono collegate a BigQuery e tutte le app che aggiungi in un secondo momento al progetto vengono collegate automaticamente a BigQuery. Puoi gestire le app che inviano dati.

  • Firebase configura le sincronizzazioni giornaliere dei tuoi dati con BigQuery.

    • Dopo aver collegato il progetto, in genere devi attendere la sincronizzazione del giorno successivo per esportare il primo set di dati in BigQuery.

    • La sincronizzazione giornaliera avviene una volta al giorno, indipendentemente da eventuali esportazioni programmate configurate in BigQuery. Tieni presente che la frequenza e la durata del job di sincronizzazione possono variare, pertanto non consigliamo di pianificare operazioni o job a valle in base a un momento specifico dell'esportazione.

  • Firebase esporta una copia dei tuoi dati esistenti in BigQuery. La propagazione iniziale dei dati per l'esportazione può 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 quando hai attivato l'esportazione in BigQuery (a seconda di quale sia la più recente).

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

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

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

Quali dati vengono esportati in BigQuery?

I dati Firebase Crashlytics vengono esportati in un set di dati BigQuery denominato firebase_crashlytics. Per impostazione predefinita, all'interno del set di dati Crashlytics verranno create singole tabelle per ogni app del progetto. Firebase nomina le tabelle in base all'identificatore dell'app, con i punti convertiti in trattini bassi e un nome della piattaforma aggiunto alla fine.

Ad esempio, i dati di un'app per Android con nome pacchetto com.google.test sarebbero in una tabella denominata com_google_test_ANDROID. Questa tabella batch viene aggiornata una volta al giorno. Se attivi l'esportazione streaming di Crashlytics in BigQuery, i dati di Crashlytics verranno trasmessi in streaming anche in tempo reale in una tabella denominata com_google_test_ANDROID_REALTIME.

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

Esportazione streaming di Crashlytics in BigQuery

Puoi trasmettere in streaming i dati Crashlytics in tempo reale con BigQuery streaming. Puoi utilizzarlo per qualsiasi scopo che richieda dati in tempo reale, ad esempio presentare informazioni in una dashboard in tempo reale, guardare un'implementazione in tempo reale o monitorare i problemi dell'applicazione che attivano avvisi e flussi di lavoro personalizzati.

Quando attivi l'esportazione in streaming di Crashlytics in BigQuery, oltre alla tabella batch avrai anche una tabella in tempo reale. Ecco le differenze tra le tabelle che devi conoscere:

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

La tabella batch è ideale per l'analisi a lungo termine e l'identificazione delle tendenze nel tempo perché archiviamo in modo duraturo gli eventi prima di scriverli e possiamo eseguirne il backfill nella tabella per un massimo di 30 giorni*. Quando scriviamo i dati nella tabella in tempo reale, li scriviamo immediatamente in BigQuery, quindi sono ideali per dashboard in tempo reale e avvisi personalizzati. Queste due tabelle possono essere combinate con una query di stitching per trarre il meglio da entrambe.

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

* Scopri i dettagli sull'assistenza per il backfill in Eseguire l'upgrade alla nuova infrastruttura di esportazione.

Attiva l'esportazione di Crashlytics in streaming 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 puoi fare con i dati esportati?

Le esportazioni in BigQuery contengono dati non elaborati sugli arresti anomali, tra cui tipo di dispositivo, sistema operativo, eccezioni (app per Android) o errori (app per Apple), nonché log di Crashlytics e altri dati.

Esamina esattamente quali dati Crashlytics vengono esportati e il relativo schema della tabella più avanti in questa pagina.

Utilizzare un modello di Data Studio

Per attivare i dati in tempo reale nel modello di Data Studio, segui le istruzioni riportate in Visualizzare i dati Crashlytics esportati con Data Studio.

Creare visualizzazioni

Puoi trasformare le query in visualizzazioni utilizzando l'interfaccia utente di BigQuery. Per istruzioni dettagliate, consulta Creare visualizzazioni nella documentazione di BigQuery.

esegui delle query

I seguenti esempi mostrano delle query che puoi eseguire sui tuoi dati Crashlytics per generare report che aggregano i dati sugli 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 la tua analisi e la tua comprensione dei dati sugli arresti anomali.

Esempio 1: arresti anomali per giorno

Dopo aver lavorato per correggere il maggior numero possibile di bug, pensi che il tuo team sia finalmente pronto a 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 la tua app sia diventata più stabile nel tempo.

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
  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: trovare gli arresti anomali più pervasivi

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

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 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: primi 10 dispositivi che subiscono arresti anomali

L'autunno è la stagione dei nuovi smartphone. La tua azienda sa che questo significa anche che è iniziata la nuova stagione dei problemi specifici dei dispositivi, in particolare per Android. Per anticipare i problemi di compatibilità imminenti, crei una query che identifichi i 10 dispositivi che hanno registrato il maggior numero di arresti anomali nell'ultima settimana (168 ore).

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
  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: filtro per chiave personalizzata

Sei uno sviluppatore di giochi e vuoi sapere quale livello del tuo gioco presenta più arresti anomali.

Per monitorare questa statistica, imposta una chiave Crashlytics personalizzata chiamata current_level e aggiornala 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 registrare la distribuzione dei valori current_level associati a ogni evento di arresto anomalo.

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
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 analizzare il problema, scrivi una query che estragga tutti gli eventi di arresto anomalo per quegli utenti utilizzando i loro ID utente.

Di seguito è riportata 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: trovare tutti gli utenti che hanno riscontrato un determinato problema di arresto anomalo

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

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 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 "Trovare gli arresti anomali più diffusi" riportato sopra per identificare l'ID del problema di arresto anomalo specifico. Il tuo team vorrebbe sapere se l'arresto anomalo si è diffuso in diversi paesi del mondo.

Per scrivere questa query, il team dovrà eseguire i seguenti passaggi:

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

  2. Aggiorna l'app in modo da 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 fino ad oggi

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
  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: 5 problemi principali dal giorno DATA, incluso oggi

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

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

Informazioni sullo schema Crashlytics in BigQuery

Quando configuri l'esportazione dei dati di Crashlytics in BigQuery, Firebase esporta gli eventi recenti (arresti anomali, errori non irreversibili e ANR), inclusi gli eventi fino a due giorni prima del collegamento, con la possibilità di eseguire il backfill fino a 30 giorni.

Da quel momento fino alla disattivazione dell'esportazione, Firebase esporta Crashlytics eventi su base giornaliera. Potrebbero essere necessari alcuni minuti prima che i dati siano disponibili in BigQuery dopo ogni esportazione.

Set di dati

Crashlytics crea un nuovo set di dati in BigQuery per i dati Crashlytics. Il set di dati copre l'intero progetto, anche se contiene più app.

Tabelle

Crashlytics crea una tabella nel set di dati per ogni app del progetto, a meno che tu non abbia disattivato l'esportazione dei dati per l'app. Firebase denomina le tabelle in base all'identificatore dell'app, con i punti convertiti in trattini bassi e alla fine il nome della piattaforma.

Ad esempio, i dati di un'app per Android con il nome del pacchetto com.google.test si troverebbero in una tabella denominata com_google_test_ANDROID, mentre i dati in tempo reale (se abilitati) si troverebbero in una tabella denominata com_google_test_ANDROID_REALTIME

Le tabelle contengono un insieme standard di dati Crashlytics, oltre a eventuali chiavi Crashlytics personalizzate che hai definito nella tua app.

Righe

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

Colonne

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

Le colonne dell'esportazione sono elencate in questa tabella:

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 registrato nel progetto Firebase (ad esempio com.google.gmail)
Per le app per la piattaforma Apple, si tratta dell'ID pacchetto dell'app.
Per le app per Android, si tratta del nome del pacchetto dell'app.
event_id STRING L'ID univoco dell'evento
is_fatal BOOLEAN Indica se l'app si è arrestata in modo 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 Lo stato della memoria del dispositivo
memory.used INT64 Byte di memoria utilizzata
memory.free INT64 Byte di memoria rimanenti
storage RECORD Lo spazio di archiviazione permanente del dispositivo
storage.used INT64 Byte di spazio di archiviazione utilizzato
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 La versione della 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 REGISTRAZIONE RIPETUTA 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 univoca dell'app e del 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 REGISTRAZIONE RIPETUTA 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 REGISTRAZIONE RIPETUTA Google Analytics breadcrumb con timestamp, se abilitati
breadcrumbs.timestamp TIMESTAMP Il timestamp associato al breadcrumb
breadcrumbs.name STRING Il nome associato al breadcrumb
breadcrumbs.params REGISTRAZIONE RIPETUTA Parametri associati al breadcrumb
breadcrumbs.params.key STRING Una chiave del parametro associata al breadcrumb
breadcrumbs.params.value STRING Un valore del parametro associato al 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 elaborato se non è idratabile
blame_frame.offset INT64 L'offset in 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 REGISTRAZIONE RIPETUTA (Solo Android) Eccezioni che si sono verificate durante questo evento. Le eccezioni nidificate sono presentate in ordine cronologico inverso, il che significa che l'ultimo record è la prima eccezione
exceptions.type STRING Il tipo di eccezione (ad es. java.lang.IllegalStateException)
exceptions.exception_message STRING Un messaggio associato all'eccezione
exceptions.nested BOOLEAN True per tutte le eccezioni tranne l'ultima lanciata (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 REGISTRAZIONE RIPETUTA 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 elaborato se non è idratabile
exceptions.frames.offset INT64 L'offset in 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 REGISTRAZIONE RIPETUTA (solo app Apple) errori non irreversibili
error.queue_name STRING La coda su cui era in esecuzione il thread
error.code INT64 Codice di errore associato all'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 stabilito che questo frame è la causa dell'errore
error.frames REGISTRAZIONE RIPETUTA 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 elaborato se non è idratabile
error.frames.offset INT64 L'offset in 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 stabilito che questo frame è la causa dell'errore
threads REGISTRAZIONE RIPETUTA Thread presenti al momento dell'evento
threads.crashed BOOLEAN Indica se il thread ha avuto un arresto anomalo
threads.thread_name STRING Il nome del thread
threads.queue_name STRING (Solo app Apple) La coda su cui era in esecuzione il thread
threads.signal_name STRING Il nome dell'indicatore che ha causato l'arresto anomalo dell'app, presente solo nei thread nativo in cui si è verificato l'arresto anomalo
threads.signal_code STRING Il codice dell'indicatore che ha causato l'arresto anomalo dell'app; presente solo nei thread nativi in cui si è verificato l'arresto anomalo
threads.crash_address INT64 L'indirizzo dell'indicatore che ha causato l'arresto anomalo dell'applicazione; presente solo nei thread nativi in cui si è verificato l'arresto anomalo
threads.code INT64 (Solo app Apple) Codice di errore dell'NSError registrato personalizzato 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 REGISTRAZIONE RIPETUTA 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 in 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 Indica se Crashlytics ha stabilito 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 dei processori in MHz
unity_metadata.system_memory_size_mb INT64 La dimensione della memoria di sistema in Mb
unity_metadata.graphics_memory_size_mb INT64 La memoria grafica in MB
unity_metadata.graphics_device_id INT64 L'identificatore del dispositivo grafico
unity_metadata.graphics_device_vendor_id INT64 L'identificatore del fornitore della scheda grafica
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 delle grafiche
unity_metadata.graphics_render_target_count INT64 Il numero di target di rendering grafico
unity_metadata.graphics_copy_texture_support STRING Supporto per la copia della texture grafica come definito 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

Visualizzare i dati Crashlytics esportati con Data Studio

Google Data 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 Data Studio, consulta la guida rapida di Data Studio, Ti diamo il benvenuto in Data Studio.

Utilizza un modello di report Crashlytics

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

  1. Apri il modello di dashboard di Data Studio Crashlytics.

  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 di Crashlytics in BigQuery è attivata, puoi selezionare la tabella in tempo reale.

  6. In Configurazione, imposta Crashlytics Livello modello 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 Crashlytics modello di dashboard di Data Studio.

Eseguire l'upgrade alla nuova infrastruttura di esportazione

A metà ottobre 2024, Crashlytics ha lanciato una nuova infrastruttura per l'esportazione dei dati di Crashlytics in BigQuery. Per il momento, l'upgrade a questa nuova infrastruttura è facoltativo.

Questa nuova infrastruttura supporta Crashlytics località del set di dati al di fuori degli Stati Uniti.

  • Se hai abilitato l'esportazione prima di metà ottobre 2024, ora puoi modificare la località per l'esportazione dei dati in qualsiasi località del set di dati supportata da BigQuery.

  • Se hai attivato l'esportazione a partire da metà ottobre 2024, puoi selezionare qualsiasi posizione del set di dati supportata da BigQuery durante la configurazione.

Un'altra differenza della nuova infrastruttura è che non supporta il backfill dei dati prima dell'attivazione dell'esportazione. Con la vecchia infrastruttura, potresti eseguire il backfill fino a 30 giorni prima della data di abilitazione. La nuova infrastruttura supporta i backfill 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).

Prerequisito per l'upgrade

Prima di eseguire l'upgrade alla nuova infrastruttura, verifica di soddisfare il seguente prerequisito: le tabelle batch BigQuery correnti hanno identificatori corrispondenti agli ID bundle o ai nomi dei pacchetti impostati per le tue app Firebase registrate.

Ad esempio:

  • Se hai una tabella BigQuery denominata com_yourcompany_yourproject_IOS, devi avere un'app Firebase per iOS+ registrata nel tuo progetto Firebase con l'ID del bundle com.yourcompany.yourproject.

  • Se hai una tabella BigQuery denominata com_yourcompany_yourproject_ANDROID, devi avere un'app Android creata in Firebase registrata nel tuo progetto Firebase con il nome del pacchetto com.yourcompany.yourproject.

Ecco come trovare tutte le app Firebase registrate nel tuo progetto Firebase:

  1. Nella console Firebase, vai alle Impostazioni del progetto di .

  2. Scorri verso il basso fino alla scheda Le tue app, quindi fai clic sull'app Firebase che ti interessa per visualizzarne le informazioni, incluso l'identificatore.

La nuova infrastruttura di esportazione esporterà i dati di ogni app in base al nome del pacchetto o all'ID pacchetto impostato per l'app Firebase registrata. Per non interrompere il flusso di lavoro di BigQuery, è importante verificare che le tabelle batch attuali abbiano già i nomi corretti, in modo che la nuova infrastruttura possa aggiungere tutti i nuovi dati alle tabelle esistenti. Se disponi di nomi di tabelle batch che non corrispondono alle app Firebase registrate, ma vuoi comunque eseguire l'upgrade, contatta l'assistenza Firebase.

Come eseguire l'upgrade alla nuova infrastruttura

Se hai già attivato l'esportazione, puoi eseguire l'upgrade alla nuova infrastruttura semplicemente disattivando e riattivando l'esportazione dei dati Crashlytics nella console Firebase.

Ecco la procedura dettagliata:

  1. Nella console Firebase, vai alla pagina Integrazioni.

  2. Nella scheda BigQuery, fai clic su Gestisci.

  3. Disattiva il dispositivo di scorrimento Crashlytics per disabilitare 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.