Eksportowanie danych Firebase Crashlytics do BigQuery

Możesz wyeksportować dane z Crashlytics do BigQuery na potrzeby dalszej analizy. BigQuery umożliwia analizowanie danych za pomocą BigQuery SQL, eksportowanie ich do innego dostawcy chmury oraz używanie ich do wizualizacji i paneli niestandardowych w Studiu danych Google.

Włącz funkcję eksportowania BigQuery

1. Otwórz stronę Integracje w konsoli Firebase.
2. Na karcie BigQuery kliknij Połącz.
3. Aby włączyć BigQuery, postępuj zgodnie z instrukcjami wyświetlanymi na ekranie.

Po połączeniu projektu z BigQuery:

• Firebase konfiguruje codzienne synchronizacje danych z projektu Firebase w BigQuery.
• Domyślnie wszystkie aplikacje w projekcie są połączone z BigQuery. Wszystkie aplikacje, które dodasz później do projektu, zostaną automatycznie połączone z BigQuery. Możesz określić, które aplikacje mają wysyłać dane.
• Firebase eksportuje kopię istniejących danych do BigQuery. Dla każdej połączonej aplikacji obejmuje to tabelę wsadową zawierającą dane z codziennej synchronizacji.
• Jeśli włączysz eksport strumieniowy BigQuery z Crashlytics, wszystkie połączone aplikacje będą też miały tabelę w czasie rzeczywistym zawierającą stale aktualizowane dane.

Aby wyłączyć eksportowanie danych do BigQuery, 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 dla każdej aplikacji w projekcie są tworzone w zbiorze danych Crashlytics. Firebase nadaje nazwy tabelom na podstawie identyfikatora pakietu aplikacji, przy czym kropki są konwertowane na podkreślenia i dodają nazwę platformy na końcu.

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 BigQuery z Crashlytics, dane z Firebase Crashlytics będą też przesyłane w czasie rzeczywistym do usługi com_google_test_ANDROID_REALTIME.

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

Włącz eksport strumieniowy BigQuery z Crashlytics

Dane z Crashlytics możesz przesyłać strumieniowo w czasie rzeczywistym dzięki funkcji BigQueryStreaming. Możesz go używać do dowolnych celów, które wymagają aktualnych danych, np. do prezentowania informacji w panelu transmisji na żywo, obserwowania wdrożenia na żywo lub monitorowania problemów z aplikacją, które wywołują alerty i niestandardowe przepływy pracy.

Eksport strumieniowy BigQuery z usługi Crashlytics nie jest dostępny w przypadku piaskownicy BigQuery.

Gdy włączysz eksport strumieniowy BigQuery w Crashlytics, oprócz tabeli wsadowej będziesz mieć tabelę czasu rzeczywistego. Oto różnice między tabelami:

Tabela wsadowa doskonale nadaje się do analizy długoterminowej i identyfikowania trendów na przestrzeni czasu, ponieważ trwale przechowujemy zdarzenia przed ich zapisaniem i można je uzupełniać w tabeli przez maksymalnie 30 dni. Dane, które zapisujemy w Twojej tabeli w czasie rzeczywistym, są natychmiast zapisywane w BigQuery, dzięki czemu doskonale sprawdzają się w przypadku aktywnych paneli i alertów niestandardowych. Te 2 tabele można połączyć za pomocą zapytania łączenia, aby korzystać z zalet obu. Zobacz zapytanie Przykład 9 poniżej.

Domyślnie czas wygaśnięcia partycji w tabeli czasu rzeczywistego to 30 dni. Aby dowiedzieć się, jak to zmienić, przeczytaj sekcję o aktualizowaniu daty wygaśnięcia partycji.

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

Aby włączyć strumieniowe przesyłanie danych, otwórz sekcję Crashlytics na stronie Integracje z BigQuery 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 podanymi w artykule Wizualizacja wyeksportowanych danych z Crashlytics przy użyciu Studia danych.

Widoki

Przykładowe zapytania możesz przekształcić w widoki, korzystając z interfejsu BigQuery. Szczegółowe instrukcje znajdziesz w artykule 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 logi Crashlytics, a także inne dane.

Praca z danymi Firebase Crashlytics w BigQuery

Poniższe przykłady pokazują zapytania, które można wykonywać na danych Crashlytics. Te zapytania generują raporty, które nie są dostępne w panelu Crashlytics.

Przykłady zapytań Crashlytics

Podane niżej przykłady pokazują, jak generować raporty, które łączą dane o zdarzeniach awarii w bardziej przystępny sposób.

Przykład 1. Awarie według dnia

Po naprawieniu jak największej liczby błędów jeden z głównych programistów sądzi, że jej zespół jest w końcu gotowy do opublikowania nowej aplikacji do udostępniania zdjęć. Zanim to zrobi, chce sprawdzić liczbę awarii dziennie w poprzednim miesiącu, aby mieć pewność, że błąd w wyniku błędu poprawił stabilność aplikacji.

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 najczęstszych awarii

Aby odpowiednio nadać priorytet planom produkcyjnym, kierownik projektu zastanawia się, jak wskazać 10 najczęstszych awarii w jego usłudze. Tworzą zapytanie, które wskazuje odpowiednie punkty 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 na telefony! Deweloper wie, że to oznacza również nowy sezon problemów z konkretnymi urządzeniami. Aby wyprzedzić rosnące problemy ze zgodnością, zespół utworzył zapytanie identyfikujące 10 urządzeń, na których w ciągu ostatniego tygodnia wystąpiły najwięcej awarii:

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 chce wiedzieć, na którym poziomie w grze występuje najwięcej awarii. Aby ułatwić im śledzenie tych statystyk, ustawili niestandardowy klucz Crashlytics current_level i aktualizowali 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 raportuje 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 identyfikatora użytkownika

Deweloper ma aplikację w ramach wcześniejszego dostępu. Większość użytkowników ją uwielbia, ale u 3 użytkowników wystąpiło niezwykła liczba awarii. Aby dotrzeć do sedna problemu, zespół tworzy zapytanie, które pobiera wszystkie zdarzenia awarii tych użytkowników, korzystając z ich identyfikatorów:

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

Przykład 6. Znajdź wszystkich użytkowników, u których występuje określony problem

Deweloper opublikował krytyczny błąd grupie beta-testerów. Na podstawie zapytania z przykładu 2 powyżej udało nam się zidentyfikować identyfikator konkretnego problemu. Teraz chce uruchomić zapytanie, aby wyodrębnić listę użytkowników aplikacji, których dotyczyła 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ł błąd, z podziałem na kraje

Teraz podczas wdrażania nowej wersji zespół wykrył błąd krytyczny. Udało im się zidentyfikować konkretny identyfikator problemu z awarią, korzystając z zapytania z przykładu 2 powyżej. Zespół chce sprawdzić, czy awaria objął użytkowników w różnych krajach na całym świecie.

Aby utworzyć to zapytanie, zespół musi:

1. Włącz eksporty BigQuery dla Google Analytics. Zobacz Eksportowanie danych projektu do BigQuery.

2. Zaktualizuj aplikację tak, aby przekazywała identyfikator użytkownika zarówno do pakietu SDK Google Analytics, jak i do Crashlytics SDK.

   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 wykorzysta pole identyfikatora użytkownika, aby złączyć zdarzenia w zbiorze danych BigQuery w Google Analytics z awariami w zbiorze danych BigQuery Crashlytics:

   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 problemów dzisiaj

Wymaga włączenia eksportu strumieniowego BigQuery do 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 dzisiaj

Wymaga włączenia eksportu strumieniowego BigQuery do Crashlytics.

W tym przykładzie połączyliśmy tabele wsadowe i tabele czasu rzeczywistego, aby dodać informacje w czasie rzeczywistym do rzetelnych danych wsadowych. event_id jest kluczem podstawowym, więc możemy za pomocą DISTINCT event_id usunąć duplikaty typowych zdarzeń z tych 2 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 do 2 dni przed połączeniem, umożliwiając uzupełnienie do 30 dni.

Od tego momentu, dopóki nie wyłączysz połączenia, Firebase codziennie eksportuje zdarzenia z Crashlytics. Po każdym eksporcie dane mogą być dostępne w BigQuery po kilku minutach.

Zbiory danych

Firebase Crashlytics tworzy w BigQuery nowy zbiór danych dla danych z Crashlytics. Zbiór danych obejmuje cały projekt, nawet jeśli obejmuje on wiele aplikacji.

Tabele

Firebase Crashlytics tworzy w zbiorze danych tabelę dla każdej aplikacji w projekcie, chyba że masz wyłączoną opcję eksportowania danych z tej aplikacji. Firebase nadaje nazwy tabelom na podstawie identyfikatora pakietu aplikacji, z kropkami przekształcanymi na podkreślenia i dodaje na końcu nazwę platformy.

Na przykład dane aplikacji na Androida o identyfikatorze com.google.test znajdą się w tabeli o nazwie com_google_test_ANDROID, a dane w czasie rzeczywistym (jeśli ta opcja jest włączona) – w tabeli o nazwie com_google_test_ANDROID_REALTIME

Tabele zawierają standardowy zestaw danych z Crashlytics oraz wszelkie niestandardowe klucze Crashlytics zdefiniowane przez deweloperó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 w Crashlytics, tabela czasu rzeczywistego będzie zawierać te same kolumny co tabela wsadowa. Poniżej wymienione są kolumny eksportowane.

Bez zrzutów stosu

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

Wizualizacja wyeksportowanych danych Crashlytics w Studiu danych

Studio danych Google przekształca zbiory danych Crashlytics w BigQuery w raporty, które można łatwo odczytywać, udostępniać i dostosowywać 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

W Studiu danych znajduje się przykładowy raport na temat Crashlytics, który zawiera pełny zestaw wymiarów i danych z wyeksportowanego schematu BigQuery Crashlytics. Jeśli włączysz 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ć przykładowego szablonu jako szablonu do szybkiego tworzenia nowych raportów i wizualizacji na podstawie nieprzetworzonych danych o awariach Twojej aplikacji:

1. Otwórz szablon panelu Studia danych Crashlytics.
2. W prawym górnym rogu kliknij Użyj szablonu.
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ą dane z Crashlytics, klikając Moje projekty > [nazwa-projektu] > firebase_crashlytics > [nazwa-twojej-tabeli]. Zawsze możesz wybrać tabelę wsadową. Jeśli masz włączony eksport strumieniowy BigQuery w Crashlytics, możesz zamiast niego wybrać tabelę w czasie rzeczywistym.
6. W sekcji Konfiguracja ustaw Poziom szablonu Crashlytics na Domyślny.
7. Kliknij Połącz, aby utworzyć nowe źródło danych.
8. Kliknij Dodaj do raportu, by wrócić do szablonu Crashlytics.
9. Na koniec kliknij Utwórz raport, aby utworzyć kopię szablonu panelu Studia danych Crashlytics.