Eksportowanie danych z Firebase Crashlytics do BigQuery

Dane z Crashlytics możesz wyeksportować do BigQuery, analizy. BigQuery umożliwia analizowanie i eksportowanie danych za pomocą BigQuery SQL. do innego dostawcy chmury i używać ich do wizualizacji i niestandardowych paneli w Studiu danych Google.

Włącz funkcję eksportowania BigQuery

1. Przejdź do Integracje w konsoli Firebase.
2. Na karcie BigQuery kliknij Połącz.
3. Postępuj zgodnie z instrukcjami wyświetlanymi na ekranie, aby włączyć BigQuery.

Po połączeniu projektu z BigQuery:

• Firebase konfiguruje codzienne synchronizacje danych z projektu Firebase w BigQuery;
• Domyślnie wszystkie aplikacje w Twoim projekcie są połączone z BigQuery i wszelkimi aplikacjami dodane później do projektu zostaną automatycznie połączone z BigQuery. Ty określić, które aplikacje mają wysyłać dane.
• Firebase wyeksportuje kopię dotychczasowych danych do BigQuery. W przypadku każdej połączonej aplikacji obejmuje to tabelę wsadową zawierającą z codziennej synchronizacji.
• Jeśli włączysz eksport strumieniowy BigQuery z Crashlytics, wszystkie połączone aplikacje będzie też miał tabelę czasu rzeczywistego zawierającą dane na bieżąco są aktualizowane.

Aby wyłączyć funkcję BigQuery Export, odłącz projekt w konsoli Firebase.

Jakie dane są eksportowane do BigQuery?

Dane Firebase Crashlytics są eksportowane do zbioru danych BigQuery o nazwie firebase_crashlytics Domyślnie poszczególne tabele będą tworzone wewnątrz zbiór danych Crashlytics dla każdej aplikacji w Twoim projekcie. Firebase nadaje nazwę na podstawie identyfikatora pakietu aplikacji, z okresami konwertowanymi na podkreśleń, a na końcu będzie nazwa platformy.

Na przykład dane aplikacji o identyfikatorze com.google.test znajdą się w tabeli o nazwie com_google_test_ANDROID. Ta tabela zbiorcza jest aktualizowana raz dziennie. Jeśli włączysz eksport strumieniowy Crashlytics do BigQuery, Firebase Crashlytics dane będą też przesyłane w czasie rzeczywistym do com_google_test_ANDROID_REALTIME.

Każdy wiersz w tabeli odpowiada zdarzeniu, które wystąpiło w aplikacji, w tym oraz błędów niekrytycznych i błędów ANR.

Włącz eksport strumieniowy BigQuery z Crashlytics

Możesz przesyłać strumieniowo dane Crashlytics w czasie rzeczywistym za pomocą BigQueryStreaming. Możesz z niej skorzystać do dowolnych celów, które wymagają danych w czasie rzeczywistym, takich jak prezentowanie informacji panelu transmisji na żywo, oglądania wdrożenia na żywo lub monitorowania problemów z aplikacją, uruchamiać alerty i niestandardowe przepływy pracy.

Eksport strumieniowy BigQuery z Crashlytics jest niedostępny w trybie piaskownicy BigQuery.

Gdy włączysz eksport strumieniowy BigQuery w Crashlytics, oprócz tabela wsadowa zawiera tabelę czasu rzeczywistego. Oto różnice, które należy wziąć pod uwagę między tabelami:

Tabela wsadowa jest idealna do długoterminowej analizy i identyfikowania trendów w czasie. bo przechowujemy zdarzenia przed ich napisaniem i można je uzupełniać z perspektywy maksymalnie 30 dni. Przy zapisie danych w tabeli czasu rzeczywistego od razu zapisywać je w BigQuery. Dzięki temu idealnie sprawdza się w przypadku paneli alertów niestandardowych. Te 2 tabele można połączyć za pomocą zapytania łączenia, aby uzyskać korzyści obu stron. Zobacz zapytanie Przykład 9 poniżej.

Domyślnie tabela czasu rzeczywistego ma okres ważności partycji wynoszący 30 dni. Do dowiedzieć się, jak to zmienić, zobacz Aktualizuj datę wygaśnięcia partycji.

Włącz strumieniowe przesyłanie danych z Crashlytics z BigQuery

Aby włączyć strumieniowe przesyłanie danych, przejdź do sekcji Crashlytics w BigQuery integracje i zaznacz pole wyboru Uwzględnij strumieniowanie.

Szablon Studia danych

Aby włączyć w szablonie Studia danych dane w czasie rzeczywistym, postępuj zgodnie z instrukcjami znajdziesz w artykule Wizualizacja danych wyeksportowanych z Crashlytics w Studiu danych.

Wyświetlenia

Możesz przekształcić poniższe przykładowe zapytania w widoki za pomocą interfejsu BigQuery. Zobacz Tworzenie widoków .

Co można zrobić z wyeksportowanymi danymi?

Eksporty BigQuery zawierają nieprzetworzone dane o awariach, w tym typ urządzenia, system operacyjny wyjątki (aplikacje na Androida) i błędy (aplikacje Apple) oraz dzienniki Crashlytics, tak jak inne dane.

Praca z danymi Firebase Crashlytics w BigQuery

Poniższe przykłady pokazują zapytania, które możesz uruchamiać na danych z Crashlytics. Te zapytania generują raporty, które są niedostępne w Crashlytics panelu.

Przykłady zapytań dotyczących Crashlytics

Poniższe przykłady pokazują, jak generować raporty zawierające zbiorcze dane o awariach danych o zdarzeniach w czytelniejsze podsumowania.

Przykład 1: awarie według dnia

Po naprawieniu jak największej liczby błędów główny deweloper uważa, że jej zespół jest gotowa na wprowadzenie swojej nowej aplikacji do udostępniania zdjęć. Zanim to zrobią, chcą sprawdzić liczbę awarii w minionym miesiącu, aby upewnić się, poprawki błędów sprawiły, że aplikacja z czasem stała się bardziej stabilna:

SELECT
  COUNT(DISTINCT event_id) AS number_of_crashes,
  FORMAT_TIMESTAMP("%F", event_timestamp) AS date_of_crashes
FROM
 `projectId.firebase_crashlytics.package_name_ANDROID`
GROUP BY
  date_of_crashes
ORDER BY
  date_of_crashes DESC
LIMIT 30;

Przykład 2. Wyszukiwanie najbardziej powszechnych awarii

Aby odpowiednio nadać planom produkcyjnym priorytety, kierownik projektu zastanawia się, z 10 najczęstszych awarii w swojej usłudze. Tworzą zapytanie który dostarcza istotnych danych:

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
  `projectId.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;

Przykład 3. 10 urządzeń, na których najczęściej występują awarie

Jesień to nowy sezon telefonów! Deweloper wie, że to też nowe urządzenie, konkretnych problemów. Aby uniknąć pojawiających się problemów ze zgodnością, tworzymy zapytanie identyfikujące 10 urządzeń, na których występuje największy liczba awarii w ciągu ostatniego tygodnia:

SELECT
  device.model,
COUNT(DISTINCT event_id) AS number_of_crashes
FROM
  `projectId.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;

Przykład 4. Filtrowanie według klucza niestandardowego

Deweloper gier chce wiedzieć, na jakim poziomie jest najciekawszy. awarii. Aby ułatwić śledzenie tych statystyk, firma ustawiła niestandardowy klucz Crashlytics current_level i aktualizuj go za każdym razem, gdy użytkownik osiągnie nowy poziom.

CrashlyticsKit setIntValue:3 forKey:@"current_level";

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

Crashlytics.setInt("current_level", 3);

Mając ten klucz w eksporcie BigQuery, tworzy zapytanie, które zgłasza rozkład wartości current_level powiązanych z każdym zdarzeniem awarii:

SELECT
COUNT(DISTINCT event_id) AS num_of_crashes,
  value
FROM
  `projectId.firebase_crashlytics.package_name_ANDROID`
UNNEST(custom_keys)
WHERE
  key = "current_level"
GROUP BY
  key,
  value
ORDER BY
  num_of_crashes DESC

Przykład 5. Wyodrębnianie identyfikatorów użytkownika

Deweloper ma aplikację w ramach wcześniejszego dostępu. Większość użytkowników je uwielbia, ale dla trzech ma miejsce nadzwyczajna liczba awarii. Aby przejść do dołu pisze zapytanie, które pobiera wszystkie zdarzenia awarii dotyczące tych użytkowników, za pomocą identyfikatorów użytkowników:

SELECT *
FROM
  `projectId.firebase_crashlytics.package_name_ANDROID`
WHERE
  user.id IN ("userid1", "userid2", "userid3")
ORDER BY
  user.id
 

Przykład 6. Znajdowanie wszystkich użytkowników, u których występuje konkretny problem z awarią

Pewien deweloper zgłosił krytyczny błąd grupie beta-testerów. Zespół udało mi się użyć zapytania z przykładu 2 powyżej, aby zidentyfikować konkretną awarię identyfikator problemu. Teraz chce uruchomić zapytanie, aby wyodrębnić listę użytkowników aplikacji. których dotyczy ta awaria:

SELECT user.id as user_id
FROM
  `projectId.firebase_crashlytics.package_name_ANDROID`
WHERE
  issue_id = "YOUR_ISSUE_ID"
  AND application.display_version = ""
  AND user.id != ""
ORDER BY
  user.id;

Przykład 7. Liczba użytkowników, których dotyczy awaria, z podziałem na kraje

Teraz zespół wykrył błąd krytyczny podczas wdrażania nowej wersji. Mogli wykorzystać zapytanie z przykładu 2 powyżej, aby zidentyfikować identyfikator problemu. Zespół chce teraz sprawdzić, czy awaria rozprzestrzeniła się na użytkownikom w różnych krajach na całym świecie.

Aby napisać to zapytanie, zespół musi:

1. Włącz eksportowanie danych do BigQuery w Google Analytics. Zobacz Eksportowanie danych projektu do BigQuery.

2. Zaktualizować aplikację tak, aby przekazywał identyfikator użytkownika zarówno do pakietu SDK Google Analytics, oraz pakiet SDK Crashlytics.

   Objective-C

   CrashlyticsKit setUserIdentifier:@"123456789";
   FIRAnalytics setUserID:@"12345678 9";
   

   Swift

   Crashlytics.sharedInstance().setUserIdentifier("123456789");
   Analytics.setUserID("123456789");
   

   Java

   Crashlytics.setUserIdentifier("123456789");
   mFirebaseAnalytics.setUserId("123456789");
   

3. Utwórz zapytanie, które korzysta z pola User-ID, aby łączyć zdarzenia w Zbiór danych BigQuery w Google Analytics z awariami w Crashlytics Zbiór danych BigQuery:

   SELECT DISTINCT c.issue_id, a.geo.country, COUNT(DISTINCT c.user.id) as num_users_impacted
   FROM `projectId.firebase_crashlytics.package_name_ANDROID` c
   INNER JOIN  `projectId.analytics_YOUR_TABLE.events_*` a on c.user.id = a.user_id
   WHERE
    c.issue_id = "YOUR_ISSUE_ID"
    AND a._TABLE_SUFFIX BETWEEN '20190101'
    AND '20200101'
   GROUP BY
    c.issue_id,
    a.geo.country,
    c.user.id
   

Przykład 8. 5 najważniejszych do tej pory tematów na dziś

Wymaga włączenia eksportu strumieniowego BigQuery Crashlytics

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM
  `your_project.firebase_crashlytics.package_name_ANDROID_REALTIME`
WHERE
  DATE(event_timestamp) = CURRENT_DATE()
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

Przykład 9: 5 najważniejszych problemów od DATE, w tym dziś

Wymaga włączenia eksportu strumieniowego BigQuery Crashlytics.

W tym przykładzie łączymy tabele wsadowe i w czasie rzeczywistym, aby dodać do niezawodnych danych wsadowych. event_id jest kluczem podstawowym, może użyć DISTINCT event_id do usunięcia duplikatów wspólnych zdarzeń z obu tabel.

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM (
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `your_project.firebase_crashlytics.package_name_ANDROID_REALTIME`
  UNION ALL
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `your_project.firebase_crashlytics.package_name_ANDROID`)
WHERE
  event_timestamp >= "2020-01-13"
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

Schemat Firebase Crashlytics w BigQuery

Gdy połączysz Crashlytics z BigQuery, Firebase eksportuje ostatnie zdarzenia (awarie, błędy niekrytyczne i błędy ANR), w tym zdarzenia z ostatnich 2 dni przed linkiem, dodając opcję backfill do 30 dni.

Od tego momentu do momentu wyłączenia połączenia Firebase eksportuje Crashlytics wydarzenia na co dzień. Może minąć kilka minut, zanim dane będą dostępne w BigQuery po każdym eksporcie.

Zbiory danych

Firebase Crashlytics tworzy w BigQuery nowy zbiór danych na potrzeby Crashlytics i skalowalnych danych. Zbiór danych obejmuje cały projekt, nawet jeśli obejmuje on kilka aplikacji.

Tabele

Firebase Crashlytics tworzy w zbiorze danych tabelę dla każdej aplikacji w z projektem, chyba że zrezygnujesz z eksportowania danych z tej aplikacji. Nazwy Firebase tabele na podstawie identyfikatora pakietu aplikacji, z okresami konwertowanymi na podkreśleń, a na końcu będzie nazwa platformy.

Na przykład dane aplikacji na Androida o identyfikatorze com.google.test znajdują się w tabeli tabeli o nazwie com_google_test_ANDROID, a dane w czasie rzeczywistym (jeśli są włączone) zostaną w tabeli o nazwie com_google_test_ANDROID_REALTIME

Tabele zawierają standardowy zestaw danych Crashlytics, a także wszelkie niestandardowe Klucze Crashlytics zdefiniowane przez programistów.

Wiersze

Każdy wiersz w tabeli oznacza błąd napotkany przez aplikację.

Kolumny

Kolumny w tabeli są identyczne w przypadku awarii, błędów niekrytycznych i błędów ANR. Jeśli Włączony jest eksport strumieniowy BigQuery z Crashlytics, a potem tabela czasu rzeczywistego zawiera te same kolumny co tabela zbiorcza. Kolumny w eksporcie to wymienionych poniżej.

Bez zrzutów stosu

Kolumny występujące w wierszach reprezentujących zdarzenia bez zrzutów stosu.

Wizualizacja wyeksportowanych danych z Crashlytics w Studiu danych

Studio danych Google przekształca ze zbiorów danych Crashlytics w BigQuery przekształconych w czytelne raporty do udostępniania i dostosowywania do własnych potrzeb.

Więcej informacji o korzystaniu ze Studia danych znajdziesz w krótkim przewodniku po Studiu danych: Witamy w Studiu danych

Korzystanie z szablonu raportu Crashlytics

Studio danych zawiera przykładowy raport Crashlytics, który zawiera obszerne zbiór wymiarów i danych z wyeksportowanego schematu BigQuery z Crashlytics. Jeśli masz włączony eksport strumieniowy BigQuery z Crashlytics, możesz wyświetlić te dane na stronie Trendy w czasie rzeczywistym w szablonie Studia danych.Możesz użyć komponentu próbek jako szablonu, aby szybko tworzyć nowe raporty i wizualizacje na podstawie nieprzetworzone dane awarii Twojej aplikacji:

1. Otwórz szablon panelu Studia danych Crashlytics.
2. Kliknij Użyj szablonu w prawym górnym rogu.
3. W menu Nowe źródło danych wybierz Utwórz nowe źródło danych.
4. Na karcie BigQuery kliknij Wybierz.
5. Wybierz tabelę zawierającą wyeksportowane dane z Crashlytics, wybierając Moje projekty > [nazwa-twojego-projektu] > firebase_crashlytics > [nazwa-twojej-tabeli]. Tabela wsadowa jest zawsze dostępna do wyboru. jeśli Eksport strumieniowy BigQuery z Crashlytics jest włączony, możesz wybrać tabeli w czasie rzeczywistym.
6. W sekcji Configuration (Konfiguracja) ustaw opcję Crashlytics level level (Poziom szablonu Crashlytics) na Default (Domyślny).
7. Kliknij Połącz, aby utworzyć nowe źródło danych.
8. Kliknij Add to Report (Dodaj do raportu), aby wrócić do szablonu Crashlytics.
9. Na koniec kliknij Utwórz raport, aby utworzyć kopię Crashlytics Szablon panelu Studia danych.