אפשר לייצא את נתוני Firebase Crashlytics אל BigQuery לצורך ניתוח נוסף. BigQuery מאפשר לנתח את הנתונים באמצעות BigQuery SQL, לייצא אותם לספק ענן אחר ולהשתמש בהם להמחשה וליצירת מרכזי בקרה בהתאמה אישית באמצעות Google Data Studio.
הפעלת הייצוא אל BigQuery
נכנסים לדף Integrations במסוף Firebase.
בכרטיס BigQuery, לוחצים על קישור.
פועלים לפי ההוראות במסך כדי להפעיל את הייצוא אל BigQuery.
אם אתם רוצים גישה כמעט בזמן אמת לנתוני Crashlytics ב-BigQuery, כדאי לשדרג לייצוא בסטרימינג.
מה קורה כשמפעילים את הייצוא?
בוחרים את המיקום של מערך הנתונים. אי אפשר לשנות את המיקום אחרי שיוצרים את מערך הנתונים, אבל אפשר להעתיק את מערך הנתונים למיקום אחר או להעביר אותו ידנית למיקום אחר (וליצור אותו מחדש). למידע נוסף, ראו שינוי המיקום של פעולות ייצוא קיימות.
המיקום הזה רלוונטי רק לנתונים שיוצאו אל BigQuery, והוא לא משפיע על המיקום של הנתונים שנשמרים לשימוש בלוח הבקרה Crashlytics במסוף Firebase או ב-Android Studio.
כברירת מחדל, כל האפליקציות בפרויקט מקושרות אל BigQuery וכל האפליקציות שתוסיפו לפרויקט במועד מאוחר יותר יקושרו באופן אוטומטי אל BigQuery. אתם יכולים לקבוע אילו אפליקציות ישלחו נתונים.
מערכת Firebase מגדירה סנכרון יומי של הנתונים שלכם אל BigQuery.
אחרי שמקשרים את הפרויקט, בדרך כלל צריך להמתין עד לסנכרון של היום הבא כדי שקבוצת הנתונים הראשונה תוצג ב-BigQuery.
הסנכרון היומי מתבצע פעם ביום, ללא קשר לייצוא מתוזמן שייתכן שהגדרתם ב-BigQuery. חשוב לזכור שהתזמון והמשך של משימת הסנכרון עשויים להשתנות, לכן לא מומלץ לתזמן פעולות או משימות במורד הזרם על סמך תזמון ספציפי של הייצוא.
מערכת Firebase מייצאת עותק של הנתונים הקיימים אל BigQuery. ההפצה הראשונית של הנתונים לייצוא עשויה להימשך עד 48 שעות.
לכל אפליקציה מקושרת, הייצוא הזה כולל טבלת אצוות שמכילה את הנתונים מהסנכרון היומי.
אתם יכולים לתזמן באופן ידני מילוי חוסרים של נתונים לטבלת האצווה עד 30 הימים האחרונים או עד לתאריך האחרון שבו הפעלתם את הייצוא אל BigQuery (המאוחר מביניהם).
לתשומת ליבכם: אם הפעלתם את הייצוא של נתוני Crashlytics לפני אמצע אוקטובר 2024, תוכלו גם למלא את החוסרים בנתונים מ-30 יום לפני היום שבו הפעלתם את הייצוא.
אם מפעילים את הייצוא בסטרימינג של Crashlytics אל BigQuery, לכל האפליקציות המקושרות תהיה גם טבלה בזמן אמת שמכילה נתונים שמתעדכנים כל הזמן.
כדי להשבית את הייצוא אל BigQuery, צריך לבטל את הקישור של הפרויקט במסוף Firebase.
אילו נתונים מיוצאים אל BigQuery?
הנתונים של Firebase Crashlytics מיוצאים למערך נתונים של BigQuery בשם firebase_crashlytics
. כברירת מחדל, טבלאות נפרדות ייוצרו בתוך מערך הנתונים Crashlytics לכל אפליקציה בפרויקט. מערכת Firebase נותנת לשמות הטבלאות שמות על סמך המזהה של האפליקציה, כאשר הנקודות הופכות לקווים תחתונים ושם הפלטפורמה מצורף בסוף.
לדוגמה, נתונים של אפליקציה ל-Android עם שם החבילה com.google.test
יופיעו בטבלה בשם com_google_test_ANDROID
. טבלת האצווה הזו מתעדכנת פעם ביום. אם מפעילים את הייצוא בסטרימינג של Crashlytics אל BigQuery, הנתונים של Crashlytics ישודרו גם בסטרימינג בזמן אמת לטבלה בשם com_google_test_ANDROID_REALTIME
.
כל שורה בטבלה מייצגת אירוע שהתרחש באפליקציה, כולל קריסות, שגיאות לא קטלניות ומקרי ANR.
Crashlytics ייצוא בסטרימינג אל BigQuery
אתם יכולים להעביר את נתוני Crashlytics בסטרימינג בזמן אמת באמצעות סטרימינג של BigQuery. אפשר להשתמש בו לכל מטרה שדורשת נתונים בזמן אמת, כמו הצגת מידע בלוח בקרה בזמן אמת, צפייה בהשקה בזמן אמת או מעקב אחרי בעיות באפליקציה שמפעילות התראות ותהליכי עבודה מותאמים אישית.
כשמפעילים ייצוא בסטרימינג של Crashlytics אל BigQuery, בנוסף לטבלת האצווה תהיה לכם גם טבלה בזמן אמת. אלה ההבדלים בין הטבלאות שכדאי לדעת:
טבלת אצווה | טבלה בזמן אמת |
---|---|
|
|
טבלת האצווה אידיאלית לניתוח לטווח ארוך ולזיהוי מגמות לאורך זמן, כי אנחנו מאחסנים את האירועים באופן עמיד לפני שאנחנו כותבים אותם, ואפשר למלא את הטבלה בנתונים חסרים עד 30 יום*. כשאנחנו כותבים נתונים לטבלה שלכם בזמן אמת, אנחנו כותבים אותם מיד ל-BigQuery, ולכן היא אידיאלית ללוחות בקרה בזמן אמת ולהתראות בהתאמה אישית. אפשר לשלב את שתי הטבלאות עם שאילתת סטיצ'ינג כדי ליהנות מהיתרונות של שתיהן.
כברירת מחדל, תאריך התפוגה של המחיצה בטבלה בזמן אמת הוא 30 יום. במאמר הגדרת תאריך התפוגה של מחיצה במסמכי העזרה של BigQuery מוסבר איך לשנות את התאריך הזה.
* פרטים על תמיכה במילוי חוסרים מופיעים במאמר שדרוג לתשתית הייצוא החדשה.
הפעלת ייצוא סטרימינג של Crashlytics אל BigQuery
נכנסים לדף Integrations במסוף Firebase.
בכרטיס BigQuery, לוחצים על Manage (ניהול).
מסמנים את התיבה Include streaming (הכללת סטרימינג).
הפעולה הזו מאפשרת סטרימינג בכל האפליקציות המקושרות.
מה אפשר לעשות עם הנתונים שיוצאו?
הייצוא אל BigQuery מכיל נתוני קריסה גולמיים, כולל סוג המכשיר, מערכת ההפעלה, חריגות (אפליקציות ל-Android) או שגיאות (אפליקציות ל-Apple), יומני Crashlytics ונתונים אחרים.
בהמשך הדף מוסבר בדיוק אילו נתונים של Crashlytics מיוצאים ואילו סכמות של טבלאות הן רלוונטיות.
שימוש בתבנית של Data Studio
כדי להפעיל נתונים בזמן אמת בתבנית של Data Studio, פועלים לפי ההוראות במאמר הצגה חזותית של נתוני Crashlytics מיוצאים באמצעות Data Studio.
יצירת תצוגות
אפשר להפוך שאילתות לתצוגות באמצעות ממשק המשתמש של BigQuery. הוראות מפורטות זמינות במאמר יצירת תצוגות במסמכי העזרה של BigQuery.
הרצת שאילתות
בדוגמאות הבאות מפורטות שאילתות שאפשר להריץ על נתוני Crashlytics כדי ליצור דוחות שמאגדים נתונים של אירועי תאונות לסיכומים שקל יותר להבין. מאחר שסוגי הדוחות האלה לא זמינים במרכז הבקרה Crashlytics במסוף Firebase, הם יכולים להשלים את הניתוח וההבנה של נתוני התקלות.
דוגמה 1: קריסות לפי יום
אחרי שתיקנתם כמה שיותר באגים, אתם חושבים שהצוות שלכם מוכן סוף סוף להשיק את אפליקציית שיתוף התמונות החדשה. לפני שתעשו זאת, אתם רוצים לבדוק את מספר הקריסות ביום בחודש האחרון, כדי לוודא שהבאג-באש עזר לכם לשפר את היציבות של האפליקציה לאורך זמן.
זוהי דוגמה לשאילתה לאפליקציה ל-Android. באפליקציה ל-iOS, צריך להשתמש במזהה החבילה וב-IOS
(במקום בשם החבילה וב-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;
דוגמה 2: איתור קריסות נפוצות במיוחד
כדי לתת עדיפות נכונה לתוכניות הייצור, אתם רוצים למצוא את 10 התקריות הנפוצות ביותר של קריסות באפליקציה. אתם יוצרים שאילתה שמספקת את נקודות הנתונים הרלוונטיות.
זוהי דוגמה לשאילתה לאפליקציה ל-Android. באפליקציה ל-iOS, צריך להשתמש במזהה החבילה וב-IOS
(במקום בשם החבילה וב-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;
דוגמה 3: 10 המכשירים המובילים שמתרסקים
הסתיו הוא העונה של טלפונים חדשים! בחברה שלכם יודעים שזה גם אומר שזו עונת הבעיות החדשות שספציפיות למכשיר – במיוחד ל-Android. כדי להתכונן מראש לבעיות התאימות הצפויות, אתם יוצרים שאילתה שמזהה את 10 המכשירים שהכי הרבה פעמים קרסו בשבוע האחרון (168 שעות).
זוהי דוגמה לשאילתה לאפליקציה ל-Android. באפליקציה ל-iOS, צריך להשתמש במזהה החבילה וב-IOS
(במקום בשם החבילה וב-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;
דוגמה 4: סינון לפי מפתח מותאם אישית
אתם מפתחי משחקים שרוצים לדעת באיזה שלב במשחק מתרחשים הכי הרבה קריסות.
כדי לעקוב אחרי הנתון הסטטיסטי הזה, מגדירים מפתח Crashlytics בהתאמה אישית בשם current_level
ומעדכנים אותו בכל פעם שהמשתמש מגיע לרמה חדשה.
Swift
Crashlytics.sharedInstance().setIntValue(3, forKey: "current_level");
Objective-C
CrashlyticsKit setIntValue:3 forKey:@"current_level";
Java
Crashlytics.setInt("current_level", 3);
אחרי שמוסיפים את המפתח הזה לייצוא אל BigQuery, אפשר לכתוב שאילתה כדי לדווח על התפלגות הערכים של current_level
שמשויכים לכל אירוע התרסקות.
זוהי דוגמה לשאילתה לאפליקציה ל-Android. באפליקציה ל-iOS, צריך להשתמש במזהה החבילה וב-IOS
(במקום בשם החבילה וב-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
דוגמה 5: חילוץ User‑ID
יש לכם אפליקציה ל-Android בגרסת גישה מוקדמת. רוב המשתמשים שלכם אוהבים את האפליקציה, אבל שלושה מהם נתקלו במספר לא רגיל של קריסות. כדי להגיע לשורש הבעיה, כותבים שאילתה שמושכת את כל אירועי ההתרסקות של המשתמשים האלה, באמצעות מזהי המשתמשים שלהם.
זוהי דוגמה לשאילתה לאפליקציה ל-Android. באפליקציה ל-iOS, צריך להשתמש במזהה החבילה וב-IOS
(במקום בשם החבילה וב-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
דוגמה 6: חיפוש כל המשתמשים שנתקלו בבעיה ספציפית של קריסה
הצוות שלכם השיק בטעות באג קריטי לקבוצה של בודקי בטא. הצוות שלך הצליח להשתמש בשאילתה מהדוגמה 'חיפוש התקלות הנפוצות ביותר' שלמעלה כדי לזהות את מזהה הבעיה הספציפית של הקריסה. עכשיו הצוות שלך רוצה להריץ שאילתה כדי לחלץ את רשימת משתמשי האפליקציה שהושפעו מהקריסה הזו.
זוהי דוגמה לשאילתה לאפליקציה ל-Android. באפליקציה ל-iOS, צריך להשתמש במזהה החבילה וב-IOS
(במקום בשם החבילה וב-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;
דוגמה 7: מספר המשתמשים שהושפעו מבעיה של קריסה, לפי מדינה
הצוות שלכם זיהה באג קריטי במהלך ההשקה של גרסה חדשה. השתמשתם בשאילתה מהדוגמה 'חיפוש תאונות הדרכים הנפוצות ביותר' שלמעלה כדי לזהות את מזהה הבעיה הספציפית של התאונה. הצוות שלך רוצה לבדוק עכשיו אם הקריסה הזו התרחשה גם אצל משתמשים במדינות שונות ברחבי העולם.
כדי לכתוב את השאילתה הזו, הצוות יצטרך לבצע את הפעולות הבאות:
מפעילים את הייצוא של נתוני Google Analytics אל BigQuery. ייצוא נתוני פרויקטים ל-BigQuery
מעדכנים את האפליקציה כך שתעבירו מזהה משתמש גם ל-Google Analytics SDK וגם ל-Crashlytics SDK.
Swift
Crashlytics.sharedInstance().setUserIdentifier("123456789"); Analytics.setUserID("123456789");
Objective-C
CrashlyticsKit setUserIdentifier:@"123456789"; FIRAnalytics setUserID:@"12345678 9";
Java
Crashlytics.setUserIdentifier("123456789"); mFirebaseAnalytics.setUserId("123456789");
כותבים שאילתה שמשתמשת בשדה user_id כדי לצרף אירועים במערך הנתונים Google Analytics לתאונות במערך הנתונים Crashlytics.
זוהי דוגמה לשאילתה לאפליקציה ל-Android. באפליקציה ל-iOS, צריך להשתמש במזהה החבילה וב-
IOS
(במקום שם החבילה וב-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
דוגמה 8: 5 הבעיות המובילות עד עכשיו היום
זוהי דוגמה לשאילתה לאפליקציה ל-Android. באפליקציה ל-iOS, צריך להשתמש במזהה החבילה וב-IOS
(במקום בשם החבילה וב-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;
דוגמה 9: 5 הבעיות המובילות מאז DATE, כולל היום
אפשר גם לשלב את הטבלאות של האצווה והטבלאות בזמן אמת עם שאילתת 'חיבור' כדי להוסיף מידע בזמן אמת לנתוני האצווה המהימנים. מכיוון ש-event_id
הוא מפתח ראשי, אפשר להשתמש ב-DISTINCT event_id
כדי למחוק כפילויות של אירועים משותפים משתי הטבלאות.
זוהי דוגמה לשאילתה לאפליקציה ל-Android. באפליקציה ל-iOS, צריך להשתמש במזהה החבילה וב-IOS
(במקום בשם החבילה וב-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;
הסבר על הסכימה Crashlytics ב-BigQuery
כשמגדירים ייצוא נתונים מ-Crashlytics אל BigQuery, מערכת Firebase מייצאת אירועים מהזמן האחרון (קריסות, שגיאות לא קטלניות ואירועי ANR), כולל אירועים מ-2 ימים לפני הקישור, עם אפשרות למילוי החוסרים עד 30 יום.
מנקודה זו ואילך, עד להשבתת הייצוא, מערכת Firebase תייצא אירועי Crashlytics על בסיס יומי. יכול להיות שיחלפו כמה דקות עד שהנתונים יהיו זמינים ב-BigQuery אחרי כל ייצוא.
מערכי נתונים
Crashlytics יוצר מערך נתונים חדש ב-BigQuery לנתוני Crashlytics. מערך הנתונים מכסה את כל הפרויקט, גם אם יש בו כמה אפליקציות.
טבלאות
הפונקציה Crashlytics יוצרת טבלה במערך הנתונים לכל אפליקציה בפרויקט, אלא אם בחרתם לבטל את הייצוא של הנתונים של האפליקציה הזו. מערכת Firebase נותנת שמות לטבלאות על סמך המזהה של האפליקציה, נקודה מוצגת כקו תחתון ושם הפלטפורמה מצורף בסוף.
לדוגמה, נתונים של אפליקציה ל-Android עם שם החבילה com.google.test
יהיו בטבלה בשם com_google_test_ANDROID
, ונתונים בזמן אמת (אם הם מופעלים) יהיו בטבלה בשם com_google_test_ANDROID_REALTIME
.
הטבלאות מכילות קבוצה רגילה של נתוני Crashlytics, בנוסף לכל מפתחות Crashlytics מותאמים אישית שהגדרתם באפליקציה.
שורות
כל שורה בטבלה מייצגת שגיאה שהאפליקציה נתקלה בה.
עמודות
העמודות בטבלה זהות לקריסות, לשגיאות לא קטלניות ולמקרים של ANR. אם הייצוא בסטרימינג של Crashlytics ל-BigQuery מופעל, לטבלה בזמן אמת יהיו אותן עמודות כמו לטבלת האצווה. שימו לב: יכול להיות שיהיו עמודות בשורות שמייצגות אירועים שאין להם מעקב סטאק.
העמודות בתוך הייצוא מפורטות בטבלה הבאה:
שם השדה | סוג הנתונים | תיאור |
---|---|---|
platform |
מחרוזת | הפלטפורמה של האפליקציה כפי שרשומה בפרויקט Firebase (ערכים חוקיים: IOS או ANDROID )
|
bundle_identifier |
מחרוזת | המזהה הייחודי של האפליקציה כפי שהוא רשום בפרויקט Firebase (לדוגמה, com.google.gmail באפליקציות לפלטפורמות של Apple, זהו מזהה החבילה של האפליקציה. באפליקציות ל-Android, זהו שם החבילה של האפליקציה. |
event_id |
מחרוזת | המזהה הייחודי של האירוע |
is_fatal |
בוליאני | אם האפליקציה קרסה |
error_type |
מחרוזת | סוג השגיאה של האירוע (לדוגמה, FATAL , NON_FATAL , ANR וכו') |
issue_id |
מחרוזת | הבעיה שמשויכת לאירוע |
variant_id |
מחרוזת | וריאנט הבעיה שמשויך לאירוע הזה שימו לב: לא לכל האירועים יש וריאנט בעיה משויך. |
event_timestamp |
TIMESTAMP | מתי האירוע התרחש |
device |
רשומה | המכשיר שבו התרחש האירוע |
device.manufacturer |
מחרוזת | יצרן המכשיר |
device.model |
מחרוזת | דגם המכשיר |
device.architecture |
מחרוזת | לדוגמה, X86_32 , X86_64 , ARMV7 ,
ARM64 , ARMV7S או ARMV7K |
memory |
רשומה | סטטוס הזיכרון של המכשיר |
memory.used |
INT64 | בייטים של זיכרון בשימוש |
memory.free |
INT64 | הבייטים הנותרים בזיכרון |
storage |
רשומה | האחסון המתמיד של המכשיר |
storage.used |
INT64 | נפח האחסון שנמצא בשימוש בבייט |
storage.free |
INT64 | נפח האחסון שנותר בבייט |
operating_system |
רשומה | פרטי מערכת ההפעלה במכשיר |
operating_system.display_version |
מחרוזת | גרסת מערכת ההפעלה במכשיר |
operating_system.name |
מחרוזת | שם מערכת ההפעלה במכשיר |
operating_system.modification_state |
מחרוזת | האם המכשיר עבר שינוי (לדוגמה, אפליקציה שנפרצה היא MODIFIED ואפליקציה עם הרשאת Root היא UNMODIFIED ) |
operating_system.type |
מחרוזת | (אפליקציות של Apple בלבד) סוג מערכת ההפעלה שפועלת במכשיר (לדוגמה, IOS , MACOS וכו') |
operating_system.device_type |
מחרוזת | סוג המכשיר (לדוגמה, MOBILE , TABLET , TV וכו'). נקרא גם 'קטגוריית מכשיר' |
application |
רשומה | האפליקציה שיצרה את האירוע |
application.build_version |
מחרוזת | גרסת ה-build של האפליקציה |
application.display_version |
מחרוזת | |
user |
רשומה | (אופציונלי) מידע שנאסף על משתמש האפליקציה |
user.name |
מחרוזת | (אופציונלי) שם המשתמש |
user.email |
מחרוזת | (אופציונלי) כתובת האימייל של המשתמש |
user.id |
מחרוזת | (אופציונלי) מזהה ספציפי לאפליקציה שמשויך למשתמש |
custom_keys |
רשומה חוזרת | צמדי מפתח/ערך שהוגדרו על ידי המפתח |
custom_keys.key |
מחרוזת | מפתח שהוגדר על ידי המפתח |
custom_keys.value |
מחרוזת | ערך שהוגדר על ידי המפתח |
installation_uuid |
מחרוזת | מזהה שמזהה התקנה ייחודית של אפליקציה ומכשיר |
crashlytics_sdk_versions |
מחרוזת | גרסת ה-SDK Crashlytics שיצרה את האירוע |
app_orientation |
מחרוזת | לדוגמה, PORTRAIT , LANDSCAPE ,
FACE_UP , FACE_DOWN וכו'. |
device_orientation |
מחרוזת | לדוגמה, PORTRAIT , LANDSCAPE ,
FACE_UP , FACE_DOWN וכו'. |
process_state |
מחרוזת | BACKGROUND או FOREGROUND |
logs |
רשומה חוזרת | הודעות ביומן עם חותמת זמן שנוצרו על ידי ה-logger של Crashlytics, אם הוא מופעל |
logs.timestamp |
TIMESTAMP | מתי נוצר היומן |
logs.message |
מחרוזת | ההודעה ביומן |
breadcrumbs |
רשומה חוזרת | נתיבי ניווט Google Analytics עם חותמת זמן, אם הם מופעלים |
breadcrumbs.timestamp |
TIMESTAMP | חותמת הזמן שמשויכת לנתיב הניווט |
breadcrumbs.name |
מחרוזת | השם שמשויך לנתיב הניווט |
breadcrumbs.params |
רשומה חוזרת | פרמטרים שמשויכים לנתיב הניווט |
breadcrumbs.params.key |
מחרוזת | מפתח פרמטר שמשויך לנתיב הניווט |
breadcrumbs.params.value |
מחרוזת | ערך פרמטר שמשויך לנתיב הניווט |
blame_frame |
רשומה | המסגרת שזוהתה כגורם העיקרי לקריסה או לשגיאה |
blame_frame.line |
INT64 | מספר השורה בקובץ של הפריים |
blame_frame.file |
מחרוזת | השם של קובץ המסגרת |
blame_frame.symbol |
מחרוזת | הסמל המשופר או הסמל הגולמי, אם לא ניתן לשפר אותו |
blame_frame.offset |
INT64 | היסט הבייט בתוך התמונה הבינארית שמכילה את הקוד לא מוגדר בחריגות של Java |
blame_frame.address |
INT64 | הכתובת בתמונה הבינארית שמכילה את הקוד לא מוגדר למסגרות Java |
blame_frame.library |
מחרוזת | השם המוצג של הספרייה שכוללת את המסגרת |
blame_frame.owner |
מחרוזת | לדוגמה, DEVELOPER , VENDOR ,
RUNTIME , PLATFORM או SYSTEM |
blame_frame.blamed |
בוליאני | אם Crashlytics קבע שהפריים הזה הוא הגורם לקריסה או לשגיאה |
exceptions |
רשומה חוזרת | (Android בלבד) חריגים שהתרחשו במהלך האירוע הזה. חריגות בתצוגת עץ מוצגות בסדר כרונולוגי הפוך, כלומר הרשומה האחרונה היא החריגה הראשונה שהופקה. |
exceptions.type |
מחרוזת | סוג החריגה (לדוגמה, java.lang.IllegalStateException) |
exceptions.exception_message |
מחרוזת | הודעה שמשויכת לחריג |
exceptions.nested |
בוליאני | הערך True לכל החריגות מלבד החריגה האחרונה שהוצגה (כלומר הרשומה הראשונה) |
exceptions.title |
מחרוזת | שם השרשור |
exceptions.subtitle |
מחרוזת | כותרת המשנה של השרשור |
exceptions.blamed |
בוליאני | הערך true אם Crashlytics קובע שהחריגה אחראית לשגיאה או לקריסה |
exceptions.frames |
רשומה חוזרת | הפריימים שמשויכים לחריג |
exceptions.frames.line |
INT64 | מספר השורה בקובץ של הפריים |
exceptions.frames.file |
מחרוזת | השם של קובץ המסגרת |
exceptions.frames.symbol |
מחרוזת | הסמל המשופר או הסמל הגולמי, אם לא ניתן לשפר אותו |
exceptions.frames.offset |
INT64 | היסט הבייט בתוך התמונה הבינארית שמכילה את הקוד לא מוגדר בחריגות של Java |
exceptions.frames.address |
INT64 | הכתובת בתמונה הבינארית שמכילה את הקוד לא מוגדר למסגרות Java |
exceptions.frames.library |
מחרוזת | השם המוצג של הספרייה שכוללת את המסגרת |
exceptions.frames.owner |
מחרוזת | לדוגמה, DEVELOPER , VENDOR ,
RUNTIME , PLATFORM או SYSTEM |
exceptions.frames.blamed |
בוליאני | אם Crashlytics קבע שהפריים הזה הוא הגורם לקריסה או לשגיאה |
error |
רשומה חוזרת | (אפליקציות של Apple בלבד) שגיאות לא קטלניות |
error.queue_name |
מחרוזת | התור שבו התנהל השרשור |
error.code |
INT64 | קוד השגיאה שמשויך ל-NSError בהתאמה אישית של האפליקציה שרשום ביומן |
error.title |
מחרוזת | שם השרשור |
error.subtitle |
מחרוזת | כותרת המשנה של השרשור |
error.blamed |
בוליאני | אם Crashlytics קבע שהפריים הזה הוא הגורם לשגיאה |
error.frames |
רשומה חוזרת | הפריימים של סטאק-טראק |
error.frames.line |
INT64 | מספר השורה בקובץ של הפריים |
error.frames.file |
מחרוזת | השם של קובץ המסגרת |
error.frames.symbol |
מחרוזת | הסמל המשופר או הסמל הגולמי, אם לא ניתן לשפר אותו |
error.frames.offset |
INT64 | היסט הבייט בתמונה הבינארית שמכילה את הקוד |
error.frames.address |
INT64 | הכתובת בתמונה הבינארית שמכילה את הקוד |
error.frames.library |
מחרוזת | השם המוצג של הספרייה שכוללת את המסגרת |
error.frames.owner |
מחרוזת | לדוגמה, DEVELOPER , VENDOR ,
RUNTIME , PLATFORM או SYSTEM |
error.frames.blamed |
בוליאני | אם Crashlytics קבע שהפריים הזה הוא הגורם לשגיאה |
threads |
רשומה חוזרת | שרשורים שהיו קיימים בזמן האירוע |
threads.crashed |
בוליאני | האם השרשור קרס |
threads.thread_name |
מחרוזת | שם השרשור |
threads.queue_name |
מחרוזת | (אפליקציות של Apple בלבד) התור שבו התנהל השרשור |
threads.signal_name |
מחרוזת | שם האות שגרם לקריסת האפליקציה, מופיע רק בשרשראות מקוריות שנכשלו |
threads.signal_code |
מחרוזת | הקוד של האות שגרם לאפליקציה לקרוס. הוא מופיע רק בשרשראות מקוריות שנכשלו |
threads.crash_address |
INT64 | הכתובת של האות שגרם לקריסת האפליקציה. הנתון הזה מופיע רק בשרשראות מקוריות שנכשלו |
threads.code |
INT64 | (אפליקציות של Apple בלבד) קוד השגיאה של ה-NSError המותאם אישית של האפליקציה שרשום ביומן |
threads.title |
מחרוזת | שם השרשור |
threads.subtitle |
מחרוזת | כותרת המשנה של השרשור |
threads.blamed |
בוליאני | אם Crashlytics קבע שהפריים הזה הוא הגורם לקריסה או לשגיאה |
threads.frames |
רשומה חוזרת | הפריימים של השרשור |
threads.frames.line |
INT64 | מספר השורה בקובץ של הפריים |
threads.frames.file |
מחרוזת | השם של קובץ המסגרת |
threads.frames.symbol |
מחרוזת | הסמל של המבנה המנוזל, או הסמל של המבנה הגולמי אם לא ניתן להוסיף לו מים |
threads.frames.offset |
INT64 | היסט הבייט בתמונה הבינארית שמכילה את הקוד |
threads.frames.address |
INT64 | הכתובת בתמונה הבינארית שמכילה את הקוד |
threads.frames.library |
מחרוזת | השם המוצג של הספרייה שכוללת את המסגרת |
threads.frames.owner |
מחרוזת | לדוגמה, DEVELOPER , VENDOR ,
RUNTIME , PLATFORM או SYSTEM |
threads.frames.blamed |
בוליאני | אם Crashlytics קבע שהפריים הזה הוא הגורם לשגיאה |
unity_metadata.unity_version |
מחרוזת | גרסת Unity שפועלת במכשיר הזה |
unity_metadata.debug_build |
בוליאני | אם מדובר ב-build לניפוי באגים |
unity_metadata.processor_type |
מחרוזת | סוג המעבד |
unity_metadata.processor_count |
INT64 | מספר המעבדים (הליבות) |
unity_metadata.processor_frequency_mhz |
INT64 | התדר של המעבדים במגה-הרץ |
unity_metadata.system_memory_size_mb |
INT64 | גודל הזיכרון של המערכת ב-MB |
unity_metadata.graphics_memory_size_mb |
INT64 | נפח זיכרון ה-GPU ב-MB |
unity_metadata.graphics_device_id |
INT64 | המזהה של מכשיר הגרפיקה |
unity_metadata.graphics_device_vendor_id |
INT64 | המזהה של ספק מעבד הגרפיקה |
unity_metadata.graphics_device_name |
מחרוזת | השם של מכשיר הגרפיקה |
unity_metadata.graphics_device_vendor |
מחרוזת | הספק של מכשיר הגרפיקה |
unity_metadata.graphics_device_version |
מחרוזת | הגרסה של מכשיר הגרפיקה |
unity_metadata.graphics_device_type |
מחרוזת | סוג מכשיר הגרפיקה |
unity_metadata.graphics_shader_level |
INT64 | רמת ה-shader של הגרפיקה |
unity_metadata.graphics_render_target_count |
INT64 | מספר היעדים לעיבוד גרפי |
unity_metadata.graphics_copy_texture_support |
מחרוזת | תמיכה בהעתקת טקסטורה של גרפיקה כפי שמוגדרת ב-Unity API |
unity_metadata.graphics_max_texture_size |
INT64 | הגודל המקסימלי הייעודי לעיבוד הגימור |
unity_metadata.screen_size_px |
מחרוזת | גודל המסך בפיקסלים, בפורמט רוחב x גובה |
unity_metadata.screen_resolution_dpi |
מחרוזת | דחיסות המסך (DPI) כמספר נקודה צפה (floating-point) |
unity_metadata.screen_refresh_rate_hz |
INT64 | קצב הרענון של המסך ב-Hz |
הצגה חזותית של נתוני Crashlytics שיוצאו באמצעות Data Studio
Google Data Studio הופך את מערכי הנתונים של Crashlytics ב-BigQuery לדוחות שקל יותר לקרוא ולשתף, וניתנים להתאמה אישית.
למידע נוסף על השימוש ב-Data Studio, כדאי לעיין במדריך למתחילים ב-Data Studio, ברוכים הבאים ל-Data Studio.
שימוש בתבנית של דוח Crashlytics
ב-Data Studio יש דוח לדוגמה ל-Crashlytics שכולל קבוצה מקיפה של מאפיינים ומדדים מהסכימת Crashlytics BigQuery שמיוצאת. אם הפעלתם את הייצוא בסטרימינג של Crashlytics אל BigQuery, תוכלו להציג את הנתונים האלה בדף מגמות בזמן אמת בתבנית של Data Studio.אפשר להשתמש בדוגמה הזו כתבנית כדי ליצור במהירות דוחות ותרשימים חדשים על סמך נתוני הקריסות הגולמיים של האפליקציה שלכם:
לוחצים על שימוש בתבנית בפינה השמאלית העליונה.
בתפריט הנפתח New Data Source, בוחרים באפשרות Create New Data Source.
לוחצים על בחירה בכרטיס BigQuery.
בוחרים טבלה שמכילה נתוני Crashlytics שיוצאו, על ידי בחירה באפשרות My Projects > PROJECT_ID > firebase_crashlytics > TABLE_NAME.
תמיד אפשר לבחור את טבלת האצווה. אם הייצוא בסטרימינג של Crashlytics אל BigQuery מופעל, תוכלו לבחור במקום זאת את הטבלה בזמן אמת.
בקטע Configuration, מגדירים את Crashlytics Template level לערך Default.
לוחצים על קישור כדי ליצור את מקור הנתונים החדש.
לוחצים על הוספה לדוח כדי לחזור לתבנית Crashlytics.
בסיום, לוחצים על Create Report (יצירת דוח) כדי ליצור עותק של התבנית Crashlytics של מרכז הבקרה ב-Data Studio.
שדרוג לתשתית הייצוא החדשה
באמצע אוקטובר 2024, Crashlytics השיקה תשתית חדשה לייצוא באצווה של נתוני Crashlytics אל BigQuery.
אפשר לשדרג לתשתית החדשה, אבל חשוב לוודא ששולחות ה-batch של BigQuery עומדות בדרישות המוקדמות לשדרוג.
איך בודקים אם אתם משתמשים בתשתית החדשה
אם הפעלתם ייצוא באצווה באמצע אוקטובר 2024 ואילך, פרויקט Firebase שלכם משתמש באופן אוטומטי בתשתית הייצוא החדשה.
אתם יכולים לבדוק באיזו תשתית הפרויקט שלכם משתמש: נכנסים למסוף Google Cloud, ואם הערך של data transfer config הוא Firebase Crashlytics with Multi-Region Support
, המשמעות היא שהפרויקט שלכם משתמש בתשתית הייצוא החדשה.
הבדלים חשובים בין תשתית הייצוא הישנה לבין תשתית הייצוא החדשה
התשתית החדשה תומכת ב-Crashlytics מיקומים של מערכי נתונים מחוץ לארה"ב.
ייצוא שהופעל לפני אמצע אוקטובר 2024 ו שדרוג לתשתית הייצוא החדשה – עכשיו אפשר לשנות את המיקום של ייצוא הנתונים.
הייצוא הופעל באמצע אוקטובר 2024 או מאוחר יותר – במהלך ההגדרה, התבקשת לבחור מיקום לייצוא הנתונים.
התשתית החדשה לא תומכת במילוי חוסרים של נתונים מהתקופה לפני שהפעלתם את הייצוא.
התשתית הישנה תמכה במילוי חוסרים עד 30 יום לפני התאריך שבו הפעלתם את הייצוא.
התשתית החדשה תומכת במילוי חוסרים עד 30 הימים האחרונים או עד לתאריך האחרון שבו הפעלתם את הייצוא אל BigQuery (המוקדם מביניהם).
התשתית החדשה נותנת שמות לטבלאות האצווה BigQuery באמצעות המזהים שהוגדרו לאפליקציות Firebase בפרויקט Firebase.
בתשתית הישנה, הנתונים נכתבו בטבלאות אצווה עם שמות שמבוססים על מזהי החבילות או שמות החבילות בתצורה של Firebase בקוד הבסיסי של האפליקציה.
התשתית החדשה כותבת נתונים לטבלאות אצווה עם שמות שמבוססים על מזהי החבילות או שמות החבילות שמוגדרים לאפליקציות Firebase הרשומים בפרויקט Firebase.
שלב 1: דרישה מוקדמת לשדרוג
בודקים שבטבלאות האצווה הקיימות של BigQuery נעשה שימוש במזהים תואמים למזהי החבילות או לשמות החבילות שהוגדרו לאפליקציות ה-Firebase הרשומים בפרויקט ב-Firebase. אם הם לא זהים, יכול להיות שיהיו שיבושים בנתוני האצווה שיוצאו. רוב הפרויקטים יהיו במצב תקין ותואם, אבל חשוב לבדוק לפני השדרוג.
כל האפליקציות ב-Firebase שרשמות בפרויקט ב-Firebase מופיעות במסוף Firebase: עוברים אל הגדרות הפרויקט ב- , גוללים אל הכרטיס האפליקציות שלך כדי לראות את כל האפליקציות ב-Firebase ואת המידע שלהן.
כל טבלאות האצווה של BigQuery מופיעות בדף BigQuery במסוף Google Cloud.
לדוגמה, אלה מצבים אידיאליים שבהם לא יהיו בעיות בשדרוג:
יש לכם טבלת באצ'ט בשם
com_yourcompany_yourproject_IOS
ואפליקציית Firebase ל-iOS עם מזהה החבילהcom.yourcompany.yourproject
שרשומה בפרויקט ב-Firebase.יש לכם טבלת באצ'ט בשם
com_yourcompany_yourproject_ANDROID
ואפליקציית Android של Firebase עם שם החבילהcom.yourcompany.yourproject
שרשומה בפרויקט ב-Firebase.
אם יש לכם שמות של טבלאות אצווה שלא תואמים למזהים שהוגדרו לאפליקציות ה-Firebase הרשומים שלכם, עליכם לפעול לפי ההוראות בהמשך הדף לפני השדרוג הידני כדי למנוע שיבושים בייצוא האצווה.
שלב 2: שדרוג ידני לתשתית החדשה
אם הפעלתם ייצוא באצווה לפני אמצע אוקטובר 2024, תוכלו לשדרג באופן ידני לתשתית החדשה פשוט על ידי השבתה והפעלה מחדש של ייצוא הנתונים מ-Crashlytics במסוף Firebase.
אלה השלבים המפורטים:
נכנסים לדף Integrations במסוף Firebase.
בכרטיס BigQuery, לוחצים על Manage (ניהול).
כדי להשבית את הייצוא, מעבירים את פס ההזזה Crashlytics למצב כבוי. כשמוצגת הבקשה, מאשרים שרוצים להפסיק את ייצוא הנתונים.
מיד לאחר מכן, מחליפים את המצב של פס ההזזה Crashlytics חזרה למצב מופעל כדי להפעיל מחדש את הייצוא. כשמוצגת הנחיה, מאשרים שרוצים לייצא את הנתונים.
ייצוא הנתונים של Crashlytics אל BigQuery מתבצע עכשיו באמצעות תשתית הייצוא החדשה.