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 di servizi 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 su BigQuery.
Se vuoi accedere ai tuoi dati Crashlytics in BigQuery quasi in tempo reale, valuta l'upgrade all'esportazione streaming.
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 viene eseguita 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.
Quali dati vengono esportati in BigQuery?
I dati Firebase Crashlytics vengono esportati in un set di dati BigQuery denominato
firebase_crashlytics
. Per impostazione predefinita, le singole tabelle vengono create all'interno
del set di dati Crashlytics per ogni app del progetto. Firebase denomina 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 pacchetto com.google.test
si troverebbero in una tabella denominata com_google_test_ANDROID
. Questa tabella dei batch viene aggiornata
una volta al giorno. Se attivi l'esportazione streaming di Crashlytics in
BigQuery, anche i dati Crashlytics verranno trasmessi in streaming in tempo reale
a 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 irreversibili e ANR.
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 |
---|---|
|
|
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 dello streaming di Crashlytics 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 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.
Più avanti in questa pagina, esamina esattamente quali dati di Crashlytics vengono esportati e il relativo schema della tabella.
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 viste
Puoi trasformare le query in viste utilizzando l'interfaccia utente BigQuery. Per istruzioni dettagliate, vedi Creare viste nella documentazione di BigQuery.
esegui delle query
I seguenti esempi mostrano query che puoi eseguire sui tuoi dati 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.
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à:
Attiva l'esportazione dei dati di Google Analytics in BigQuery. Consulta Esportare i dati del progetto in BigQuery.
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");
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 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;
Comprendere lo schema Crashlytics in BigQuery
Quando configuri l'esportazione dei dati 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 riempire 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 di 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 un nome alle 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 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 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.
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 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 |
Visualizzare i dati Crashlytics esportati con Data Studio
Google Data Studio trasforma i tuoi Crashlytics set di dati 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, 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 i dati nella pagina Tendenze in tempo reale del modello di Data Studio.Puoi utilizzare il campione come modello per creare rapidamente nuovi report e visualizzazioni in base ai dati non elaborati sugli 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 in BigQuery è attivata, puoi selezionare la tabella in tempo reale.Crashlytics
In Configurazione, imposta Livello modello Crashlytics 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 modello di dashboard di Data Studio Crashlytics.
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
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 bundlecom.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 pacchettocom.yourcompany.yourproject
registrata nel tuo progetto Firebase.
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:
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.