Exportar dados do Firebase Crashlytics para o BigQuery

Seus dados do Firebase Crashlytics podem ser exportados para o BigQuery para uma análise mais detalhada. Com o BigQuery, é possível analisar os dados usando o BigQuery SQL, exportá-los para outro provedor de nuvem e usá-los em visualizações e painéis personalizados com o Data Studio do Google.

Ativar exportação para BigQuery

  1. No console do Firebase, acesse a guia Integrações.

  2. No card do BigQuery, clique em Vincular.

  3. Siga as instruções na tela para ativar a exportação para o BigQuery.

    Se você quiser acesso quase em tempo real aos dados do Crashlytics no BigQuery, faça upgrade para a exportação de streaming.

O que acontece quando você ativa a exportação?

  • Você seleciona o local do conjunto de dados. Após a criação do banco de dados, o local não pode ser alterado, mas é possível mover (recriar) ou copiar o conjunto de dados para um local diferente. Para saber mais, consulte Mudar o local das exportações atuais.

    Esse local é aplicável apenas aos dados exportados para BigQuery e não afeta o local dos dados armazenados para uso no painel Crashlytics do console Firebase ou no Android Studio.

  • Todos os apps no projeto são vinculados ao BigQuery por padrão, e qualquer app adicionado ao projeto depois também é vinculado automaticamente ao BigQuery. É possível gerenciar quais apps enviam dados.

  • O Firebase configura as sincronizações diárias dos seus dados para o BigQuery.

    • Depois de vincular seu projeto, geralmente será necessário esperar até a sincronização do dia seguinte para que o primeiro conjunto de dados seja exportado para o BigQuery.

    • A sincronização diária acontece uma vez por dia, independentemente da exportação programada que você tenha configurado no BigQuery. Observação: o tempo e a duração do job de sincronização podem mudar. Portanto, não recomendamos programar operações ou jobs downstream com base em um tempo específico da exportação.

  • O Firebase exporta uma cópia dos seus dados para o BigQuery. A propagação inicial dos dados para exportação pode levar até 48 horas.

    • Para cada aplicativo vinculado, essa exportação inclui uma tabela em lote contendo os dados da sincronização diária.

    • É possível configurar manualmente o preenchimento de dados da tabela de lote até os últimos 30 dias ou a data mais recente em que você ativou a exportação para BigQuery (o que for mais recente).

    Se você tiver ativado a exportação de dados de Crashlytics antes de meados de outubro de 2024, também poderá preencher os dados 30 dias antes do dia em que ativou a exportação.

  • Se você ativar a exportação de streaming do Crashlytics para o BigQuery, todos os apps vinculados também terão uma tabela em tempo real com dados sempre atualizados.

Para desativar a exportação do BigQuery, desvincule seu projeto no console do Firebase.

Quais dados são exportados para o BigQuery?

Os dados do Firebase Crashlytics são exportados para um conjunto de dados do BigQuery chamado firebase_crashlytics. Por padrão, tabelas individuais são criadas dentro do conjunto de dados do Crashlytics para cada app no seu projeto. O Firebase nomeia as tabelas com base no identificador do app, com pontos convertidos em sublinhados e um nome de plataforma anexado ao final.

Por exemplo, os dados de um app Android com o nome do pacote com.google.test ficariam em uma tabela chamada com_google_test_ANDROID. Essa tabela em lote é atualizada uma vez por dia. Se você ativar a exportação de streaming do Crashlytics para o BigQuery, os dados do Crashlytics também serão transmitidos em tempo real para uma tabela chamada com_google_test_ANDROID_REALTIME.

Cada linha em uma tabela representa um evento que ocorreu no app, incluindo falhas, erros não fatais e ANRs.

Exportação de streaming do Crashlytics para o BigQuery

É possível transmitir seus dados do Crashlytics em tempo real com o streaming do BigQuery. Use esse recurso sempre que quiser acessar dados em tempo real, por exemplo, apresentar informações em um painel ativo, assistir a um lançamento ao vivo ou monitorar problemas de aplicativos que acionam alertas e fluxos de trabalho personalizados.

Ao ativar a exportação de streaming do Crashlytics para o BigQuery, além da tabela em lote, você também terá uma tabela em tempo real. Veja abaixo as diferenças entre as tabelas:

Tabela em lote Tabela em tempo real
  • Os dados são exportados uma vez por dia.
  • Os eventos são armazenados de maneira durável antes da gravação em lote no BigQuery.
  • Os dados podem ser preenchidos até 30 dias antes*.
  • Os dados são exportados em tempo real.
  • A adição retroativa de dados não está disponível.

A tabela em lote é ideal para análise de longo prazo e identificação de tendências ao longo do tempo, porque armazenamos eventos de maneira durável antes de gravá-los. Além disso, eles podem ser preenchidos na tabela por até 30 dias*. Quando gravamos dados na sua tabela em tempo real, eles são gravados imediatamente no BigQuery e, por isso, é ideal para painéis ativos e alertas personalizados. Essas duas tabelas podem ser combinadas com uma consulta de agrupamento para aproveitar os benefícios de ambas.

Por padrão, a tabela em tempo real tem um prazo de validade de partição de 30 dias. Para saber como mudar isso, consulte Definir a validade da partição na documentação do BigQuery.

* Confira detalhes sobre o suporte de preenchimento em Fazer upgrade para a nova infraestrutura de exportação.

Ativar a exportação de streaming do Crashlytics para o BigQuery

  1. No console do Firebase, acesse a guia Integrações.

  2. No card do BigQuery, clique em Gerenciar.

  3. Marque a caixa de seleção Incluir streaming.

Essa ação ativa o streaming para todos os seus apps vinculados.

O que você pode fazer com os dados exportados?

As exportações para o BigQuery contêm dados brutos de falhas, incluindo tipo de dispositivo, sistema operacional, exceções (apps Android) ou erros (apps Apple) e registros do Crashlytics, além de outros dados.

Confira exatamente os dados do Crashlytics que são exportados e o esquema da tabela mais adiante nesta página.

Usar um modelo do Data Studio

Para ativar os dados em tempo real no seu modelo do Data Studio, siga as instruções em Como visualizar dados exportados do Crashlytics com o Data Studio.

Criar visualizações

É possível transformar consultas em visualizações usando a interface do BigQuery. Para instruções detalhadas de como fazer isso, consulte Criar visualizações na documentação do BigQuery.

Execute consultas

Os exemplos a seguir demonstram consultas que podem ser executadas nos seus dados do Crashlytics para gerar relatórios que agregam dados de eventos com falha em resumos mais fáceis de entender. Como esses tipos de relatórios não estão disponíveis no painel do Crashlytics no console do Firebase, eles podem complementar sua análise e entendimento dos dados de falha.

Exemplo 1: número de falhas por dia

Depois de trabalhar para corrigir o máximo de bugs possível, você acha que sua equipe finalmente está pronta para lançar o novo app de compartilhamento de fotos. Antes de fazer isso, você quer conferir o número de falhas por dia no último mês para ter certeza de que a busca por bugs tornou o app mais estável com o tempo.

Este é um exemplo de consulta para um app Android. Para apps iOS, use o ID do pacote e IOS (em vez do nome do pacote 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;

Exemplo 2: encontrar as falhas de maior impacto

Para priorizar corretamente os planos de produção, você quer encontrar as 10 falhas de maior impacto no seu app. Você cria uma consulta que fornece os pontos de dados pertinentes.

Este é um exemplo de consulta para um app Android. Para apps iOS, use o ID do pacote e IOS (em vez do nome do pacote 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;

Exemplo 3: os 10 dispositivos com mais falhas

O outono é a temporada de lançamento de novos smartphones. Sua empresa sabe que isso também significa uma nova onda de problemas específicos de cada dispositivo, principalmente para Android. Para superar as preocupações de compatibilidade, você elaborou uma consulta que identifica os 10 dispositivos com mais falhas na última semana (168 horas).

Este é um exemplo de consulta para um app Android. Para apps iOS, use o ID do pacote e IOS (em vez do nome do pacote 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;

Exemplo 4: filtrar por chave personalizada

Você é um desenvolvedor de jogos que quer saber em qual nível o jogo está apresentando o maior número de falhas.

Para ajudar a monitorar essa estatística, defina uma chave personalizada do Crashlytics chamada current_level e a atualize sempre que o usuário atingir um novo nível.

Swift

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

Objective-C

CrashlyticsKit setIntValue:3 forKey:@"current_level";

Java

Crashlytics.setInt("current_level", 3);

Com essa chave na sua exportação para o BigQuery, é possível gravar uma consulta para relatar a distribuição dos valores de current_level associados a cada evento com falha.

Este é um exemplo de consulta para um app Android. Para apps iOS, use o ID do pacote e IOS (em vez do nome do pacote 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

Exemplo 5: extração de ID do usuário

Você tem um app Android que está em acesso antecipado. A maioria dos seus usuários adorou, mas três tiveram um número incomum de falhas. Para encontrar a raiz do problema, você criou uma consulta para extrair todos os eventos com falha que ocorreram com esses usuários, usando os IDs de usuário correspondentes.

Este é um exemplo de consulta para um app Android. Para apps iOS, use o ID do pacote e IOS (em vez do nome do pacote 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

Exemplo 6: localizar todos os usuários que enfrentam uma falha específica

Sua equipe acidentalmente lançou um bug crítico para um grupo de testadores Beta. Usando a consulta do exemplo "encontrar as falhas de maior impacto" acima, sua equipe conseguiu identificar o ID específico da falha. Agora, ela quer executar uma consulta para extrair a lista de usuários do app que foram afetados pela falha.

Este é um exemplo de consulta para um app Android. Para apps iOS, use o ID do pacote e IOS (em vez do nome do pacote 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;

Exemplo 7: número de usuários afetados por uma falha, divididos por país

Sua equipe detectou um bug crítico durante o lançamento de uma nova versão. Você conseguiu usar a consulta do exemplo "encontrar as falhas de maior impacto" acima para identificar o ID específico da falha. Sua equipe agora quer ver se essa falha se espalhou para usuários em diferentes países ao redor do mundo.

Para criar essa consulta, ela precisa fazer o seguinte:

  1. Ative a exportação de dados do Google Analytics para o BigQuery. Acesse Exportar dados do projeto para o BigQuery.

  2. Atualize o app para transmitir um ID do usuário para o SDK do Google Analytics e para o SDK do 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. Crie uma consulta que use o campo ID do usuário para agrupar eventos no conjunto de dados do Google Analytics com falhas no conjunto de dados do Crashlytics.

    Este é um exemplo de consulta para um app Android. Para apps iOS, use o ID do pacote e IOS (em vez do nome do pacote 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

Exemplo 8: os cinco problemas principais de hoje

Este é um exemplo de consulta para um app Android. Para apps iOS, use o ID do pacote e IOS (em vez do nome do pacote 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;

Exemplo 9: cinco problemas principais desde DATE, incluindo hoje

Também é possível combinar as tabelas em lote e em tempo real com uma consulta de agrupamento para adicionar informações em tempo real aos dados confiáveis em lote. Como event_id é uma chave primária, o DISTINCT event_id pode ser usado para eliminar os eventos em comum das duas tabelas.

Este é um exemplo de consulta para um app Android. Para apps iOS, use o ID do pacote e IOS (em vez do nome do pacote 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;

Entender o esquema do Crashlytics no BigQuery

Quando você configura a exportação de dados do Crashlytics para o BigQuery, o Firebase exporta eventos recentes (falhas, erros não fatais e ANRs), incluindo eventos de até dois dias antes da vinculação, com a opção de adição retroativa de dados de até 30 dias.

Enquanto a vinculação estiver ativada, os eventos do Crashlytics serão exportados diariamente pelo Firebase. Após cada exportação, levará alguns minutos para que os dados estejam disponíveis no BigQuery.

Conjuntos de dados

O Crashlytics cria um novo conjunto de dados no BigQuery para dados do Crashlytics. O conjunto de dados abrange todo o projeto, mesmo que tenha vários apps.

Tabelas

O Crashlytics cria uma tabela no conjunto de dados para cada app no seu projeto, a não ser que tenha recusado a exportação de dados para esse app. O Firebase nomeia as tabelas com base no identificador do pacote do app, com pontos convertidos em sublinhados e um nome de plataforma anexado ao final.

Por exemplo, os dados de um app para Android com o nome do pacote com.google.test ficariam em uma tabela chamada com_google_test_ANDROID e os dados em tempo real (se ativados) ficariam em uma tabela chamada com_google_test_ANDROID_REALTIME

As tabelas contêm um conjunto padrão de dados do Crashlytics, além de chaves personalizadas do Crashlytics definidas por você no app.

Linhas

Cada linha em uma tabela representa um erro encontrado pelo app.

Colunas

As colunas em uma tabela são idênticas para falhas, erros não fatais e ANRs. Se a exportação de streaming do Crashlytics para o BigQuery estiver ativada, a tabela em tempo real terá as mesmas colunas da tabela em lote. Observação: você pode ter colunas em linhas que representam eventos que não têm stack traces.

As colunas na exportação estão listadas nesta tabela:

Nome do campo Tipo de dado Descrição
platform STRING A plataforma do app registrada no projeto do Firebase (valores válidos: IOS ou ANDROID)
bundle_identifier STRING O identificador exclusivo do app como registrado no projeto do Firebase, por exemplo, com.google.gmail.
Para apps da plataforma Apple, é o ID do pacote do app.
Para apps Android, é o nome do pacote do app.
event_id STRING O ID exclusivo do evento
is_fatal BOOLEANO Se o app apresentou uma falha
error_type STRING O tipo de erro do evento (por exemplo, FATAL, NON_FATAL, ANR etc.)
issue_id STRING O problema associado ao evento
variant_id STRING A variante do problema associada a este evento
Nem todos os eventos têm uma variante do problema associada.
event_timestamp TIMESTAMP Quando o evento ocorreu
device RECORD O dispositivo em que o evento ocorreu
device.manufacturer STRING O fabricante do dispositivo
device.model STRING O modelo do dispositivo
device.architecture STRING Por exemplo, X86_32, X86_64, ARMV7, ARM64, ARMV7S ou ARMV7K
memory RECORD O status da memória do dispositivo
memory.used INT64 Bytes de memória usados
memory.free INT64 Bytes de memória restantes
storage RECORD Armazenamento permanente do dispositivo
storage.used INT64 Bytes de armazenamento usados
storage.free INT64 Bytes de armazenamento restantes
operating_system RECORD Os detalhes do SO no dispositivo
operating_system.display_version STRING A versão do SO no dispositivo
operating_system.name STRING O nome do SO no dispositivo
operating_system.modification_state STRING Se o dispositivo foi modificado (por exemplo, um app com jailbreak é MODIFIED e um app com acesso root é UNMODIFIED)
operating_system.type STRING (Somente apps da Apple) O tipo de SO em execução no dispositivo (por exemplo, IOS, MACOS etc.)
operating_system.device_type STRING O tipo de dispositivo (por exemplo, MOBILE, TABLET, TV etc.), também conhecido como categoria do dispositivo
application RECORD O app que gerou o evento
application.build_version STRING A versão do build do app
application.display_version STRING
user RECORD (Opcional) Informações coletadas sobre o usuário do app
user.name STRING Opcional: o nome do usuário
user.email STRING Opcional: o endereço de e-mail do usuário
user.id STRING (Opcional) Um ID específico do app associado ao usuário
custom_keys REGISTRO REPETIDO Pares de chave-valor definidos pelo desenvolvedor
custom_keys.key STRING Uma chave definida pelo desenvolvedor
custom_keys.value STRING Um valor definido pelo desenvolvedor
installation_uuid STRING Um ID que identifica um app e uma instalação exclusivos no dispositivo
crashlytics_sdk_versions STRING A versão do SDK do Crashlytics que gerou o evento
app_orientation STRING Por exemplo, PORTRAIT, LANDSCAPE, FACE_UP, FACE_DOWN etc.
device_orientation STRING Por exemplo, PORTRAIT, LANDSCAPE, FACE_UP, FACE_DOWN etc.
process_state STRING BACKGROUND ou FOREGROUND
logs REGISTRO REPETIDO Mensagens de registro com carimbo de data/hora geradas pelo registrador do Crashlytics, se ativadas
logs.timestamp TIMESTAMP Quando o registro foi feito
logs.message STRING A mensagem registrada
breadcrumbs REGISTRO REPETIDO Google AnalyticsNavegação estrutural, com carimbo de data/hora, se ativado
breadcrumbs.timestamp TIMESTAMP O carimbo de data/hora associado à navegação estrutural
breadcrumbs.name STRING O nome associado à navegação estrutural
breadcrumbs.params REGISTRO REPETIDO Parâmetros associados à navegação estrutural
breadcrumbs.params.key STRING Uma chave de parâmetro associada à navegação estrutural
breadcrumbs.params.value STRING Um valor de parâmetro associado à navegação estrutural
blame_frame RECORD O frame identificado como a causa raiz da falha ou do erro
blame_frame.line INT64 O número da linha no arquivo do frame
blame_frame.file STRING O nome do arquivo do frame
blame_frame.symbol STRING O símbolo hidratado, ou símbolo bruto, se não for hidratável
blame_frame.offset INT64 O deslocamento de bytes na imagem binária que contém o código
não configurado para exceções Java
blame_frame.address INT64 O endereço na imagem binária que contém o código
não configurado para frames Java
blame_frame.library STRING O nome de exibição da biblioteca que inclui o frame
blame_frame.owner STRING Por exemplo, DEVELOPER, VENDOR, RUNTIME, PLATFORM ou SYSTEM
blame_frame.blamed BOOLEANO Se o Crashlytics determinou que esse frame é a causa da falha ou do erro
exceptions REGISTRO REPETIDO (Apenas Android) Exceções que ocorreram durante este evento. As exceções aninhadas são apresentadas em ordem cronológica inversa, o que significa que o último registro é a primeira exceção lançada
exceptions.type STRING O tipo de exceção (por exemplo, java.lang.IllegalStateException)
exceptions.exception_message STRING Uma mensagem associada à exceção
exceptions.nested BOOLEANO Verdadeiro para todas, exceto a última exceção lançada (ou seja, o primeiro registro)
exceptions.title STRING O título da linha de execução
exceptions.subtitle STRING A legenda da linha de execução
exceptions.blamed BOOLEANO Verdadeiro se o Crashlytics determinar que a exceção é responsável pelo erro ou pela falha
exceptions.frames REGISTRO REPETIDO Os frames associados à exceção
exceptions.frames.line INT64 O número da linha no arquivo do frame
exceptions.frames.file STRING O nome do arquivo do frame
exceptions.frames.symbol STRING O símbolo hidratado, ou símbolo bruto, se não for hidratável
exceptions.frames.offset INT64 O deslocamento de bytes na imagem binária que contém o código
não configurado para exceções Java
exceptions.frames.address INT64 O endereço na imagem binária que contém o código
não configurado para frames Java
exceptions.frames.library STRING O nome de exibição da biblioteca que inclui o frame
exceptions.frames.owner STRING Por exemplo, DEVELOPER, VENDOR, RUNTIME, PLATFORM ou SYSTEM
exceptions.frames.blamed BOOLEANO Se o Crashlytics determinou que esse frame é a causa da falha ou do erro
error REGISTRO REPETIDO (Apenas apps da Apple) Erros não fatais
error.queue_name STRING A fila em que a linha de execução estava sendo executada
error.code INT64 Código do erro associado ao NSError personalizado registrado no app
error.title STRING O título da linha de execução
error.subtitle STRING A legenda da linha de execução
error.blamed BOOLEANO Se o Crashlytics determinou que esse frame é a causa do erro
error.frames REGISTRO REPETIDO Os frames do stack trace
error.frames.line INT64 O número da linha no arquivo do frame
error.frames.file STRING O nome do arquivo do frame
error.frames.symbol STRING O símbolo hidratado, ou símbolo bruto, se não for hidratável
error.frames.offset INT64 O deslocamento de bytes na imagem binária que contém o código
error.frames.address INT64 O endereço na imagem binária que contém o código
error.frames.library STRING O nome de exibição da biblioteca que inclui o frame
error.frames.owner STRING Por exemplo, DEVELOPER, VENDOR, RUNTIME, PLATFORM ou SYSTEM
error.frames.blamed BOOLEANO Se o Crashlytics determinou que esse frame é a causa do erro
threads REGISTRO REPETIDO Linhas de execução presentes no momento em que ocorreu o evento
threads.crashed BOOLEANO Se a thread apresentou uma falha
threads.thread_name STRING O nome da thread
threads.queue_name STRING (Apenas apps da Apple) A fila em que a linha de execução estava sendo executada
threads.signal_name STRING O nome do sinal que causou a falha do app. Presente apenas em linhas de execução nativas com falha
threads.signal_code STRING O código do sinal que causou a falha do app. Presente apenas em linhas de execução nativas com falha
threads.crash_address INT64 O endereço do sinal que causou a falha do aplicativo. Presente apenas em linhas de execução nativas com falha
threads.code INT64 (Apenas apps da Apple) Código do erro do NSError personalizado registrado pelo aplicativo
threads.title STRING O título da linha de execução
threads.subtitle STRING A legenda da linha de execução
threads.blamed BOOLEANO Se o Crashlytics determinou que esse frame é a causa da falha ou do erro
threads.frames REGISTRO REPETIDO Os frames da linha de execução
threads.frames.line INT64 O número da linha no arquivo do frame
threads.frames.file STRING O nome do arquivo do frame
threads.frames.symbol STRING O símbolo hidratado, ou bruto, se não for hidratável
threads.frames.offset INT64 O deslocamento de bytes na imagem binária que contém o código
threads.frames.address INT64 O endereço na imagem binária que contém o código
threads.frames.library STRING O nome de exibição da biblioteca que inclui o frame
threads.frames.owner STRING Por exemplo, DEVELOPER, VENDOR, RUNTIME, PLATFORM ou SYSTEM
threads.frames.blamed BOOLEANO Se o Crashlytics determinou que esse frame é a causa do erro
unity_metadata.unity_version STRING A versão do Unity em execução no dispositivo
unity_metadata.debug_build BOOLEANO Se esse é um build de depuração
unity_metadata.processor_type STRING O tipo de processador
unity_metadata.processor_count INT64 O número de processadores (núcleos)
unity_metadata.processor_frequency_mhz INT64 A frequência dos processadores em MHz
unity_metadata.system_memory_size_mb INT64 O tamanho da memória do sistema em MBs
unity_metadata.graphics_memory_size_mb INT64 A memória gráfica em MBs
unity_metadata.graphics_device_id INT64 O identificador do dispositivo gráfico
unity_metadata.graphics_device_vendor_id INT64 O identificador do fornecedor do processador gráfico
unity_metadata.graphics_device_name STRING O nome do dispositivo gráfico
unity_metadata.graphics_device_vendor STRING O fornecedor do dispositivo gráfico
unity_metadata.graphics_device_version STRING A versão do dispositivo gráfico
unity_metadata.graphics_device_type STRING O tipo de dispositivo gráfico
unity_metadata.graphics_shader_level INT64 O nível de sombreador dos gráficos
unity_metadata.graphics_render_target_count INT64 O número de destinos de renderização gráfica
unity_metadata.graphics_copy_texture_support STRING Suporte à cópia de texturas gráficas, conforme definido na API Unity
unity_metadata.graphics_max_texture_size INT64 O tamanho máximo dedicado à renderização de texturas
unity_metadata.screen_size_px STRING O tamanho da tela em pixels, formatado como largura x altura
unity_metadata.screen_resolution_dpi STRING O DPI da tela como um número de ponto flutuante
unity_metadata.screen_refresh_rate_hz INT64 Taxa de atualização da tela em Hz


Visualizar dados exportados do Crashlytics com o Data Studio

O Data Studio do Google transforma os conjuntos de dados do Crashlytics no BigQuery em relatórios totalmente personalizáveis, mais fáceis de ler e de compartilhar.

Para saber como usar o Data Studio, acesse o Introdução ao Data Studio.

Usar um modelo de relatório do Crashlytics

O Data Studio oferece uma amostra de relatório do Crashlytics que inclui um conjunto abrangente de dimensões e métricas do esquema exportado do BigQuery para o Crashlytics. Caso tenha ativado a exportação de streaming do Crashlytics para o BigQuery, será possível visualizar esses dados na página Tendências em tempo real do modelo do Data Studio. Essa amostra pode ser usada como modelo para uma criação rápida de relatórios e visualizações novos com base nos dados brutos de falhas do próprio app:

  1. Abra o modelo do Painel do Data Studio do Crashlytics.

  2. Clique em Usar modelo no canto superior direito.

  3. No menu suspenso Nova fonte de dados, selecione Criar nova fonte de dados.

  4. Clique em Selecionar no card do BigQuery.

  5. Para selecionar uma tabela com os dados exportados do Crashlytics, escolha Meus projetos > PROJECT_ID > firebase_crashlytics > TABLE_NAME.

    Sua tabela em lote está sempre disponível para seleção. Se a exportação de streaming do Crashlytics para o BigQuery estiver ativada, será possível selecionar a tabela em tempo real.

  6. Em Configuração, defina o Nível do modelo do Crashlytics como Padrão.

  7. Clique em Conectar para criar a nova origem de dados.

  8. Clique em Adicionar ao relatório para retornar ao modelo do Crashlytics.

  9. Para concluir, clique em Criar relatório e crie uma cópia do modelo do Painel do Data Studio do Crashlytics.


Fazer upgrade para a nova infraestrutura de exportação

Em meados de outubro de 2024, a Crashlytics lançou uma nova infraestrutura para a exportação em lote de dados de Crashlytics para BigQuery.

Você pode fazer upgrade para a nova infraestrutura, mas verifique se as tabelas de lote BigQuery atendem aos pré-requisitos para upgrade.

Determinar se você está na nova infraestrutura

Se você ativou a exportação em lote em meados de outubro de 2024 ou mais tarde, seu projeto do Firebase usa automaticamente a nova infraestrutura de exportação.

É possível verificar qual infraestrutura seu projeto está usando: acesse o console Google Cloud. Se a "Configuração de transferência de dados" estiver marcada como Firebase Crashlytics with Multi-Region Support, seu projeto está usando a nova infraestrutura de exportação.

Diferenças importantes entre a infraestrutura de exportação antiga e a nova

  • Essa nova infraestrutura oferece suporte a conjuntos de dados do Crashlyticsde locais fora dos Estados Unidos.

    • Exportação ativada antes de meados de outubro de 2024 e upgrade para a nova infraestrutura de exportação: agora é possível mudar o local da exportação de dados.

    • Exportação ativada em meados de outubro de 2024 ou mais tarde: durante a configuração você foi solicitado a selecionar um local para a exportação de dados.

  • A nova infraestrutura não oferece suporte a preenchimentos de dados antes de você ativar a exportação.

    • A infraestrutura antiga oferecia suporte a preenchimentos de até 30 dias antes da data em que você ativou a exportação.

    • A nova infraestrutura oferece suporte a preenchimentos de até 30 dias ou da data mais recente em que você ativou a exportação para BigQuery (o que for mais recente).

  • A nova infraestrutura nomeia as tabelas de lote BigQuery usando os identificadores definidos para seus apps do Firebase no projeto do Firebase.

    • A infraestrutura antiga gravava dados em tabelas de lote com nomes baseados nos IDs ou nomes de pacote na configuração do Firebase na base de código do app.

    • A nova infraestrutura grava dados em tabelas de lote com nomes com base nos IDs ou nomes de pacote definidos para os apps do Firebase registrados no seu projeto do Firebase.

Etapa 1: pré-requisito para a atualização

  1. Verifique se as tabelas de lote BigQuery atuais usam identificadores correspondentes aos IDs ou nomes de pacote definidos para os apps do Firebase registrados no seu projeto do Firebase. Se eles não corresponderem, talvez haja interrupções nos dados exportados em lote. A maioria dos projetos estará em um estado adequado e compatível, mas é importante verificar antes de fazer o upgrade.

    • Você pode encontrar todos os apps do Firebase registrados no seu projeto do Firebase no console Firebase: acesse as Configurações do projeto, role até o card Seus apps para ver todos os apps do Firebase e as informações deles.

    • Todas as tabelas de lote BigQuery estão disponíveis na página BigQuery do console Google Cloud.

    Por exemplo, confira os estados ideais em que você não terá problemas com a atualização:

    • Você tem uma tabela de lote chamada com_yourcompany_yourproject_IOS e um app iOS do Firebase com o ID do pacote com.yourcompany.yourproject registrado no seu projeto do Firebase.

    • Você tem uma tabela de lote chamada com_yourcompany_yourproject_ANDROID e um app Android do Firebase com o nome de pacote com.yourcompany.yourproject registrado no seu projeto do Firebase.

  2. Se você tiver nomes de tabelas de lote que não correspondem aos identificadores definidos para seus apps do Firebase registrados, siga as instruções mais adiante nesta página antes de fazer o upgrade manual para evitar interrupções na exportação em lote.

Etapa 2: fazer upgrade manual para a nova infraestrutura

Se você tiver ativado a exportação em lote antes de meados de outubro de 2024, poderá fazer upgrade manualmente para a nova infraestrutura simplesmente desativando e ativando a exportação de dados Crashlytics no console Firebase.

Veja as etapas detalhadas:

  1. No console do Firebase, acesse a guia Integrações.

  2. No card do BigQuery, clique em Gerenciar.

  3. Desative o controle deslizante Crashlytics para desativar a exportação. Quando solicitado, confirme que você quer interromper a exportação de dados.

  4. Ative imediatamente o controle deslizante Crashlytics para reativar a exportação. Quando solicitado, confirme que você quer exportar os dados.

    A exportação de dados de Crashlytics para BigQuery agora usa a nova infraestrutura de exportação.

O nome da tabela de lote atual não corresponde ao identificador do app do Firebase