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
Nella console Firebase, vai alla pagina Integrazioni.
Nella scheda BigQuery, fai clic su Collega.
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 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 la sincronizzazione giornaliera 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 dall'eventuale esportazione pianificata che potresti aver configurato 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 il nome del pacchetto com.google.test
si troverebbero 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 streaming in 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 |
---|---|
|
|
La tabella batch è ideale per l'analisi a lungo termine e l'identificazione delle tendenze nel tempo perché memorizziamo in modo duraturo gli eventi prima di scriverli e possono essere sottoposti a 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
Nella console Firebase, vai alla pagina Integrazioni.
Nella scheda BigQuery, fai clic su Gestisci.
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
Gli esempi riportati di seguito mostrano le query che puoi eseguire sui 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ù diffusi
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: i 10 dispositivi con più 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 degli 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 relativi ID utente.
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 * 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 del 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, suddiviso 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 ora sapere se questo arresto anomalo si è diffuso a utenti di diversi paesi in tutto il mondo.
Per scrivere questa query, il team dovrà eseguire i seguenti passaggi:
Attiva l'esportazione dei dati di Google Analytics in BigQuery. Consulta Esportare i dati del progetto in BigQuery.
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");
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 eANDROID
).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 primaria, puoi utilizzarla per deduplicare gli eventi comuni delle due tabelle.DISTINCT event_id
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 in poi, fino a quando non disattivi l'esportazione, Firebase esporta gli eventi Crashlytics 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 assegna ai tabella il nome 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 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 arresti anomali, errori non irreversibili e 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 es. 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 a tutti gli eventi è associata una variante del problema. |
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 | Indica 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 vengono presentate in ordine cronologico inverso, il che significa che l'ultimo record è la prima eccezione lanciata. |
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 | Indica 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 | Indica 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 | Indica 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 | Indica 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 non elaborato 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 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 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.
Utilizzare 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 Crashlytics BigQuery 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:
Fai clic su Utilizza modello nell'angolo in alto a destra.
Nel menu a discesa Nuova origine dati, seleziona Crea nuova origine dati.
Fai clic su Seleziona nella scheda BigQuery.
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.
In Configurazione, imposta Crashlytics Livello modello su Predefinito.
Fai clic su Connetti per creare la nuova origine dati.
Fai clic su Aggiungi al report per tornare al modello Crashlytics.
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 le località dei set di dati Crashlytics al di fuori degli Stati Uniti.
Se hai attivato l'esportazione prima di metà ottobre 2024, ora puoi facoltativamente modificare la posizione di esportazione dei dati in qualsiasi posizione 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, potevi eseguire il backfill fino a 30 giorni prima della data di attivazione. La nuova infrastruttura supporta i backfill fino agli ultimi 30 giorni o alla 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 bundlecom.yourcompany.yourproject
.Se hai una tabella BigQuery denominata
com_yourcompany_yourproject_ANDROID
, dovresti avere un'app Android creata in Firebase registrata nel tuo progetto Firebase con il nome del pacchettocom.yourcompany.yourproject
.
Ecco come trovare tutte le app Firebase registrate nel tuo progetto Firebase:
Nella console Firebase, vai alle Impostazioni del progetto di .
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 bundle impostato per l'app Firebase registrata. Per non interrompere il flusso di lavoro BigQuery, è importante assicurarsi che le tabelle batch correnti abbiano già i nomi corretti in modo che la nuova infrastruttura possa accodare tutti i nuovi dati alle tabelle esistenti. Se i nomi delle tabelle batch non corrispondono alle tue app Firebase registrate, ma vuoi comunque eseguire l'upgrade, rivolgiti all'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:
Nella console Firebase, vai alla pagina Integrazioni.
Nella scheda BigQuery, fai clic su Gestisci.
Disattiva il cursore Crashlytics per disattivare l'esportazione. Quando richiesto, conferma che vuoi interrompere l'esportazione dei dati.
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.