داده های Firebase Crashlytics را به BigQuery صادر کنید

شما می‌توانید داده‌های Firebase Crashlytics خود را برای تجزیه و تحلیل بیشتر به BigQuery منتقل کنید. BigQuery به شما امکان می‌دهد داده‌ها را با استفاده از BigQuery SQL تجزیه و تحلیل کنید، آن را به یک ارائه دهنده ابری دیگر منتقل کنید و از آن برای تجسم و داشبوردهای سفارشی با Looker Studio استفاده کنید.

با داده‌های صادر شده چه کاری می‌توانید انجام دهید؟

خروجی‌ها به BigQuery حاوی داده‌های خام خرابی شامل نوع دستگاه، سیستم عامل، استثنائات (برنامه‌های اندروید) یا خطاها (برنامه‌های اپل) و گزارش‌های Crashlytics و همچنین سایر داده‌ها هستند. می‌توانید بعداً در این صفحه، دقیقاً داده‌های Crashlytics خروجی گرفته شده و طرح جدول آن را بررسی کنید.

در اینجا چند نمونه از کارهایی که می‌توانید با داده‌های Crashlytics صادر شده خود انجام دهید، آورده شده است:

  • اجرای کوئری‌ها
    شما می‌توانید کوئری‌هایی را روی داده‌های Crashlytics خود اجرا کنید تا گزارش‌هایی تولید کنید که داده‌های رویداد خرابی را در خلاصه‌هایی که فهم آنها آسان‌تر است، جمع‌آوری می‌کنند. از آنجایی که این نوع گزارش‌ها در داشبورد Crashlytics کنسول Firebase در دسترس نیستند، می‌توانند تجزیه و تحلیل و درک شما از داده‌های خرابی را تکمیل کنند. در ادامه این صفحه، مجموعه‌ای از کوئری‌های نمونه را خواهید یافت.

  • از یک الگوی Looker Studio استفاده کنید
    Crashlytics یک الگوی از پیش ساخته شده Looker Studio برای تجسم داده‌های خروجی شما ارائه می‌دهد.

  • ایجاد نماها
    با استفاده از رابط کاربری BigQuery ، می‌توانید یک "view" ایجاد کنید که یک جدول مجازی است که توسط یک کوئری SQL تعریف می‌شود. برای دستورالعمل‌های دقیق در مورد انواع مختلف viewها و نحوه ایجاد آنها، به مستندات BigQuery مراجعه کنید.

خروجی گرفتن از Crashlytics به BigQuery

شما می‌توانید داده‌های Crashlytics خود را به صورت بلادرنگ با BigQuery streaming پخش کنید. می‌توانید از آن برای هر هدفی که نیاز به داده‌های زنده دارد، مانند ارائه اطلاعات در یک داشبورد زنده، تماشای یک به‌روزرسانی به صورت زنده یا نظارت بر مشکلات برنامه که باعث ایجاد هشدارها و گردش‌های کاری سفارشی می‌شوند، استفاده کنید.

وقتی Crashlytics streaming export to BigQuery را فعال می‌کنید، علاوه بر جدول دسته‌ای، یک جدول realtime نیز خواهید داشت. در اینجا تفاوت‌هایی که باید بین جداول از آنها آگاه باشید، آورده شده است:

جدول دسته‌ای جدول بی‌درنگ
  • داده‌ها روزی یک بار صادر می‌شوند.
  • رویدادها قبل از نوشتن دسته‌ای در BigQuery به طور پایدار ذخیره می‌شوند.
  • داده‌ها را می‌توان تا 30 روز قبل* دوباره پر کرد .
  • داده‌ها به صورت بلادرنگ صادر می‌شوند.
  • امکان پر کردن مجدد وجود ندارد.

جدول دسته‌ای برای تحلیل بلندمدت و شناسایی روندها در طول زمان ایده‌آل است، زیرا ما رویدادها را قبل از نوشتن به طور مداوم ذخیره می‌کنیم و می‌توان آن‌ها را تا 30 روز* در جدول ذخیره کرد. وقتی داده‌ها را در جدول بلادرنگ شما می‌نویسیم، بلافاصله آن را در BigQuery می‌نویسیم و بنابراین برای داشبوردهای زنده و هشدارهای سفارشی ایده‌آل است. این دو جدول را می‌توان با یک کوئری دوخت ترکیب کرد تا از مزایای هر دو بهره‌مند شوید.

به طور پیش‌فرض، جدول realtime دارای زمان انقضای پارتیشن 30 روزه است. برای یادگیری نحوه تغییر این زمان، به بخش تنظیم انقضای پارتیشن در مستندات BigQuery مراجعه کنید.

* جزئیات مربوط به پشتیبانی از پر کردن مجدد را در ارتقاء به زیرساخت صادرات جدید مشاهده کنید.


فعال کردن صادرات به BigQuery

  1. در کنسول Firebase ، به صفحه Integrations بروید.

  2. در کارت BigQuery ، روی پیوند (Link) کلیک کنید.

  3. برای فعال کردن صادرات به BigQuery ، دستورالعمل‌های روی صفحه را دنبال کنید.

    اگر می‌خواهید تقریباً به صورت بلادرنگ به داده‌های Crashlytics خود در BigQuery دسترسی داشته باشید، ارتقا به streaming export را در نظر بگیرید.

فعال کردن خروجی گرفتن Crashlytics به BigQuery

  1. در کنسول Firebase ، به صفحه Integrations بروید.

  2. در کارت BigQuery ، روی مدیریت (Manage) کلیک کنید.

  3. کادر انتخاب «شامل پخش جریانی» را علامت بزنید.

این اقدام، پخش جریانی را برای همه برنامه‌های مرتبط شما فعال می‌کند.

وقتی export رو ​​فعال می‌کنی چه اتفاقی می‌افته؟

  • شما مکان مجموعه داده‌ها را انتخاب می‌کنید. پس از ایجاد مجموعه داده‌ها، مکان را نمی‌توان تغییر داد، اما می‌توانید مجموعه داده‌ها را به مکان دیگری کپی کنید یا مجموعه داده‌ها را به صورت دستی در مکان دیگری جابجا (بازسازی) کنید. برای کسب اطلاعات بیشتر، به بخش «تغییر مکان برای خروجی‌های موجود » مراجعه کنید.

    این مکان فقط برای داده‌های صادر شده به BigQuery قابل استفاده است و تاثیری بر مکان داده‌های ذخیره شده برای استفاده در داشبورد Crashlytics کنسول Firebase یا در Android Studio ندارد.

  • به طور پیش‌فرض، تمام برنامه‌های موجود در پروژه شما به BigQuery متصل هستند و هر برنامه‌ای که بعداً به پروژه اضافه کنید، به طور خودکار به BigQuery متصل می‌شود. می‌توانید مدیریت کنید که کدام برنامه‌ها داده ارسال کنند .

  • فایربیس همگام‌سازی‌های روزانه داده‌های شما را با BigQuery تنظیم می‌کند.

    • بعد از اینکه پروژه خود را لینک کردید، معمولاً باید تا همگام‌سازی روز بعد صبر کنید تا اولین مجموعه داده‌ها به BigQuery صادر شوند.

    • همگام‌سازی روزانه، صرف نظر از هرگونه صادرات برنامه‌ریزی‌شده‌ای که ممکن است در BigQuery تنظیم کرده باشید، یک بار در روز اتفاق می‌افتد. توجه داشته باشید که زمان و مدت زمان کار همگام‌سازی می‌تواند تغییر کند، بنابراین توصیه نمی‌کنیم عملیات یا کارهای پایین‌دستی را بر اساس زمان‌بندی خاصی از صادرات برنامه‌ریزی کنید.

  • فایربیس یک کپی از داده‌های موجود شما را به BigQuery ارسال می‌کند. انتشار اولیه داده‌ها برای ارسال ممکن است تا ۴۸ ساعت طول بکشد.

    • برای هر برنامه‌ی لینک‌شده، این خروجی شامل یک جدول دسته‌ای است که شامل داده‌های همگام‌سازی روزانه است.

    • شما می‌توانید به صورت دستی، زمان‌بندی‌های تکمیل داده‌ها را برای جدول دسته‌ای تا 30 روز گذشته یا برای جدیدترین تاریخی که امکان صادرات به BigQuery را فعال کرده‌اید (هر کدام که جدیدتر باشد) برنامه‌ریزی کنید.

    توجه داشته باشید که اگر قبل از اواسط اکتبر ۲۰۲۴، خروجی گرفتن از داده‌های Crashlytics را فعال کرده باشید، می‌توانید ۳۰ روز قبل از روزی که خروجی گرفتن را فعال کرده‌اید، دوباره اطلاعات را پر کنید.

  • اگر قابلیت ارسال جریانی Crashlytics به BigQuery را فعال کنید ، تمام برنامه‌های مرتبط نیز یک جدول بلادرنگ حاوی داده‌های دائماً در حال به‌روزرسانی خواهند داشت.

برای غیرفعال کردن صادرات به BigQuery ، پروژه خود را در کنسول Firebase از حالت اتصال خارج کنید.


مثال‌های پرسشی

مثال ۱: خرابی‌ها بر اساس روز

بعد از تلاش برای رفع هرچه بیشتر اشکالات، فکر می‌کنید تیم شما بالاخره آماده است تا برنامه جدید اشتراک‌گذاری عکس شما را راه‌اندازی کند. قبل از انجام این کار، می‌خواهید تعداد خرابی‌های روزانه را در ماه گذشته بررسی کنید تا مطمئن شوید که رفع اشکالات، برنامه را در طول زمان پایدارتر کرده است.

در اینجا یک نمونه کوئری برای یک برنامه اندروید آورده شده است. برای یک برنامه 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;

مثال ۲: فراگیرترین خرابی‌ها را پیدا کنید

برای اولویت‌بندی صحیح برنامه‌های تولید، باید 10 مورد از رایج‌ترین خرابی‌ها را در برنامه خود پیدا کنید. شما یک پرس‌وجو ایجاد می‌کنید که نکات مربوط به داده‌ها را ارائه می‌دهد.

در اینجا یک نمونه کوئری برای یک برنامه اندروید آورده شده است. برای یک برنامه 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;

مثال ۳: ۱۰ دستگاهی که بیشترین خرابی را دارند

پاییز فصل گوشی‌های جدید است! شرکت شما می‌داند که این به معنای فصل مشکلات جدید مختص دستگاه‌ها - به خصوص برای اندروید - نیز هست. برای جلوگیری از نگرانی‌های مربوط به سازگاری قریب‌الوقوع، شما یک کوئری (پرس‌وجو) ایجاد می‌کنید که 10 دستگاهی را که بیشترین خرابی را در هفته گذشته (168 ساعت) تجربه کرده‌اند، شناسایی می‌کند.

در اینجا یک نمونه کوئری برای یک برنامه اندروید آورده شده است. برای یک برنامه 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;

مثال ۴: فیلتر بر اساس کلید سفارشی

شما یک توسعه‌دهنده بازی هستید که می‌خواهید بدانید کدام سطح از بازی شما بیشترین خرابی را تجربه می‌کند.

برای کمک به ردیابی این آمار، شما یک کلید سفارشی Crashlytics به نام current_level تنظیم می‌کنید و هر بار که کاربر به سطح جدیدی می‌رسد، آن را به‌روزرسانی می‌کنید.

سویفت 

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

هدف-سی 

CrashlyticsKit setIntValue:3 forKey:@"current_level";

جاوا 

Crashlytics.setInt("current_level", 3);

با استفاده از آن کلید در خروجی خود به BigQuery ، می‌توانید یک کوئری بنویسید تا توزیع مقادیر current_level مرتبط با هر رویداد خرابی را گزارش دهد.

در اینجا یک نمونه کوئری برای یک برنامه اندروید آورده شده است. برای یک برنامه 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

مثال ۵: استخراج شناسه کاربر

شما یک برنامه اندروید در مرحله دسترسی زودهنگام دارید. اکثر کاربران شما آن را دوست دارند، اما سه نفر از آنها تعداد غیرمعمولی از خرابی‌ها را تجربه کرده‌اند. برای رسیدن به ریشه مشکل، شما یک کوئری می‌نویسید که تمام رویدادهای خرابی را برای آن کاربران، با استفاده از شناسه کاربری آنها، استخراج می‌کند.

در اینجا یک نمونه کوئری برای یک برنامه اندروید آورده شده است. برای یک برنامه 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

مثال ۶: یافتن تمام کاربرانی که با یک مشکل خرابی خاص مواجه هستند

تیم شما به‌طور تصادفی یک اشکال بحرانی را برای گروهی از آزمایش‌کنندگان بتا منتشر کرده است. تیم شما توانست با استفاده از پرس‌وجوی مثال «یافتن فراگیرترین خرابی‌ها» در بالا، شناسه مشکل خرابی خاص را شناسایی کند. اکنون تیم شما می‌خواهد یک پرس‌وجو برای استخراج لیست کاربران برنامه که تحت تأثیر این خرابی قرار گرفته‌اند، اجرا کند.

در اینجا یک نمونه کوئری برای یک برنامه اندروید آورده شده است. برای یک برنامه 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;

مثال ۷: تعداد کاربرانی که تحت تأثیر مشکل خرابی قرار گرفته‌اند، به تفکیک کشور

تیم شما در طول انتشار یک نسخه جدید، یک اشکال بحرانی را شناسایی کرده است. شما توانستید از پرس و جوی مثال "یافتن فراگیرترین خرابی‌ها" در بالا برای شناسایی شناسه مشکل خرابی خاص استفاده کنید. تیم شما اکنون می‌خواهد ببیند که آیا این خرابی به کاربران در کشورهای مختلف جهان سرایت کرده است یا خیر.

برای نوشتن این پرس و جو، تیم شما باید موارد زیر را انجام دهد:

  1. فعال کردن خروجی گرفتن از داده‌های Google Analytics به BigQuery . به بخش خروجی گرفتن از داده‌های پروژه به BigQuery مراجعه کنید.

  2. برنامه خود را به‌روزرسانی کنید تا یک شناسه کاربری را هم به Google Analytics SDK و هم به Crashlytics SDK ارسال کند.

    سویفت 

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

    هدف-سی 

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

    جاوا 

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

  3. یک کوئری بنویسید که از فیلد شناسه کاربری برای اتصال رویدادهای مجموعه داده Google Analytics به رویدادهای خرابی در مجموعه داده Crashlytics استفاده کند.

    در اینجا یک نمونه کوئری برای یک برنامه اندروید آورده شده است. برای یک برنامه 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

مثال ۸: ۵ شماره برتر تا به امروز

در اینجا یک نمونه کوئری برای یک برنامه اندروید آورده شده است. برای یک برنامه 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;

مثال ۹: ۵ شماره برتر از تاریخ DATE، شامل امروز

همچنین می‌توانید جداول batch و realtime را با یک کوئری stitching ترکیب کنید تا اطلاعات realtime را به داده‌های batch قابل اعتماد اضافه کنید. از آنجایی که event_id یک کلید اصلی است، می‌توانید از DISTINCT event_id برای dedupe کردن هرگونه رویداد مشترک از دو جدول استفاده کنید.

در اینجا یک نمونه کوئری برای یک برنامه اندروید آورده شده است. برای یک برنامه 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 >= PARSE_TIMESTAMP("%Y_%m_%d", "YYYY_MM_DD")
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;


تجسم داده‌های خروجی Crashlytics با Looker Studio

Looker Studio مجموعه داده‌های Crashlytics شما را در BigQuery به گزارش‌هایی تبدیل می‌کند که خواندن، اشتراک‌گذاری و قابلیت شخصی‌سازی آنها آسان‌تر است.

برای کسب اطلاعات بیشتر در مورد استفاده از Looker Studio ، راهنمای خوشامدگویی آنها را بررسی کنید.

از یک الگوی گزارش Crashlytics استفاده کنید

Looker Studio یک گزارش نمونه برای Crashlytics دارد که شامل مجموعه‌ای جامع از ابعاد و معیارها از طرح Crashlytics BigQuery صادر شده است. اگر Crashlytics streaming export to BigQuery را فعال کرده باشید، می‌توانید آن داده‌ها را در صفحه روندهای Realtime قالب Looker Studio مشاهده کنید. می‌توانید از این نمونه به عنوان یک الگو برای ایجاد سریع گزارش‌ها و تجسم‌های جدید بر اساس داده‌های خام خرابی برنامه خود استفاده کنید:

  1. الگوی داشبورد Crashlytics Looker Studio را باز کنید.

  2. روی «استفاده از الگو» در گوشه بالا سمت راست کلیک کنید.

  3. در منوی کشویی منبع داده جدید ، گزینه ایجاد منبع داده جدید را انتخاب کنید.

  4. روی گزینه‌ی «انتخاب» در کارت BigQuery کلیک کنید.

  5. با انتخاب My Projects > PROJECT_ID > firebase_crashlytics > TABLE_NAME ، جدولی حاوی داده‌های خروجی Crashlytics انتخاب کنید.

    جدول دسته‌ای شما همیشه برای انتخاب در دسترس است. اگر قابلیت ارسال خروجی Crashlytics به BigQuery فعال باشد، می‌توانید جدول بلادرنگ خود را انتخاب کنید.

  6. در قسمت پیکربندی ، سطح قالب Crashlytics را روی پیش‌فرض تنظیم کنید.

  7. برای ایجاد منبع داده جدید، روی «اتصال» کلیک کنید.

  8. برای بازگشت به الگوی Crashlytics ، روی «افزودن به گزارش» کلیک کنید.

  9. در نهایت، روی ایجاد گزارش کلیک کنید تا نسخه خود از الگوی داشبورد Crashlytics Looker Studio ایجاد شود.


آشنایی با طرحواره Crashlytics در BigQuery

داده‌های Firebase Crashlytics به یک مجموعه داده BigQuery به نام firebase_crashlytics منتقل می‌شوند. این مجموعه داده کل پروژه شما را پوشش می‌دهد، حتی اگر چندین برنامه داشته باشد.

جداول

به طور پیش‌فرض، فایربیس برای هر برنامه در پروژه شما که به BigQuery لینک شده است، جداول جداگانه‌ای را در داخل مجموعه داده‌های Crashlytics ایجاد می‌کند. این جداول بر اساس شناسه برنامه (با تبدیل نقطه به زیرخط) نامگذاری شده و پلتفرم برنامه ( _IOS یا _ANDROID ) به آنها اضافه می‌شود. به عنوان مثال، داده‌های یک برنامه اندروید با نام بسته com.google.test در جدولی به نام com_google_test_ANDROID قرار می‌گیرند.

اگر قابلیت ارسال جریانی Crashlytics به BigQuery را فعال کنید، داده‌های Crashlytics نیز به صورت بلادرنگ در جدولی که با _REALTIME (برای مثال، com_google_test_ANDROID_REALTIME ) مشخص شده است، جریان می‌یابند.

هر ردیف در یک جدول، نشان‌دهنده‌ی رویدادی است که در برنامه رخ داده است، از جمله خرابی‌ها، خطاهای غیرمهلک و ANRها.

جداول علاوه بر کلیدهای سفارشی Crashlytics که توسط شما در برنامه‌تان تعریف شده‌اند، حاوی مجموعه‌ای استاندارد از داده‌های Crashlytics هستند.

ردیف‌ها

هر سطر در یک جدول نشان دهنده خطایی است که برنامه با آن مواجه شده است.

ستون‌ها

ستون‌های یک جدول برای خرابی‌ها، خطاهای غیرمهلک و ANRها یکسان هستند. اگر Crashlytics streaming export to BigQuery فعال باشد، جدول realtime ستون‌های مشابه جدول batch را خواهد داشت. توجه داشته باشید که ممکن است ستون‌هایی در ردیف‌ها داشته باشید که نشان‌دهنده رویدادهایی باشند که ردیابی پشته‌ای ندارند.

ستون‌های جدول مربوط به داده‌های خروجی Crashlytics به شرح زیر است:

نام فیلد نوع داده توضیحات
app_orientation رشته برای مثال، PORTRAIT ، LANDSCAPE ، FACE_UP ، FACE_DOWN و غیره.
application رکورد برنامه‌ای که این رویداد را ایجاد کرده است
application.build_version رشته نسخه ساخت برنامه
application.display_version رشته
blame_frame رکورد فریمی که به عنوان علت اصلی خرابی یا خطا شناسایی شده است
blame_frame.address INT64 آدرس موجود در تصویر دودویی که حاوی کد است
برای فریم‌های جاوا تنظیم نشده است
blame_frame.blamed بولی اینکه آیا Crashlytics تشخیص داده است که این فریم علت خرابی یا خطا است یا خیر
blame_frame.file رشته نام فایل فریم
blame_frame.library رشته نام نمایشی کتابخانه‌ای که شامل قاب است
blame_frame.line INT64 شماره خط فایل فریم
blame_frame.offset INT64 بایت آفست به تصویر دودویی که حاوی کد است
برای استثنائات جاوا تنظیم نشده است
blame_frame.owner رشته برای مثال، DEVELOPER ، VENDOR ، RUNTIME ، PLATFORM یا SYSTEM
blame_frame.symbol رشته نماد هیدراته یا نماد خام در صورت عدم هیدراته بودن
breadcrumbs رکورد تکرار شده در صورت فعال بودن، مسیریاب‌های Google Analytics با مهر زمانی
breadcrumbs.name رشته نام مرتبط با بردکرامب
breadcrumbs.params رکورد تکرار شده پارامترهای مرتبط با breadcrumb
breadcrumbs.params.key رشته یک کلید پارامتر مرتبط با breadcrumb
breadcrumbs.params.value رشته مقدار پارامتر مرتبط با breadcrumb
breadcrumbs.timestamp مهر زمانی مهر زمانی مرتبط با breadcrumb
bundle_identifier رشته شناسه منحصر به فرد برای برنامه همانطور که در پروژه Firebase ثبت شده است (برای مثال، com.google.gmail )
برای برنامه‌های پلتفرم اپل، این شناسه بسته (bundle ID) برنامه است.
برای برنامه‌های اندروید، این نام بسته‌ی برنامه است.
crashlytics_sdk_versions رشته نسخه SDK Crashlytics که این رویداد را ایجاد کرده است
custom_keys رکورد تکرار شده جفت‌های کلید-مقدار تعریف‌شده توسط توسعه‌دهنده
custom_keys.key رشته یک کلید تعریف‌شده توسط توسعه‌دهنده
custom_keys.value رشته مقداری که توسط توسعه‌دهنده تعریف شده است
device رکورد دستگاهی که رویداد روی آن رخ داده است
device_orientation رشته برای مثال، PORTRAIT ، LANDSCAPE ، FACE_UP ، FACE_DOWN و غیره.
device.architecture رشته برای مثال، X86_32 ، X86_64 ، ARMV7 ، ARM64 ، ARMV7S یا ARMV7K
device.manufacturer رشته سازنده دستگاه
device.model رشته مدل دستگاه
error رکورد تکرار شده (فقط برنامه‌های اپل) خطاهای غیرمهلک
error_type رشته نوع خطای رویداد (برای مثال، FATAL ، NON_FATAL ، ANR و غیره)
error.blamed بولی آیا Crashlytics تشخیص داده است که این فریم علت خطا است یا خیر
error.code INT64 کد خطای مرتبط با NSError ثبت‌شده‌ی سفارشی برنامه
error.frames رکورد تکرار شده فریم‌های stacktrace
error.frames.address INT64 آدرس موجود در تصویر دودویی که حاوی کد است
error.frames.blamed بولی آیا Crashlytics تشخیص داده است که این فریم علت خطا است یا خیر
error.frames.file رشته نام فایل فریم
error.frames.library رشته نام نمایشی کتابخانه‌ای که شامل قاب است
error.frames.line INT64 شماره خط فایل فریم
error.frames.offset INT64 بایت آفست به تصویر دودویی که حاوی کد است
error.frames.owner رشته برای مثال، DEVELOPER ، VENDOR ، RUNTIME ، PLATFORM یا SYSTEM
error.frames.symbol رشته نماد هیدراته یا نماد خام در صورت عدم هیدراته بودن
error.queue_name رشته صفی که نخ در آن اجرا می‌شد
error.subtitle رشته زیرعنوان تاپیک
error.title رشته عنوان تاپیک
event_id رشته شناسه منحصر به فرد برای رویداد
event_timestamp مهر زمانی وقتی رویداد رخ داد
exceptions رکورد تکرار شده (فقط اندروید) استثناهایی که در طول این رویداد رخ داده‌اند. استثناهای تو در تو به ترتیب زمانی معکوس نمایش داده می‌شوند، به این معنی که آخرین رکورد، اولین استثنای رخ داده است.
exceptions.blamed بولی اگر Crashlytics تشخیص دهد که استثنا مسئول خطا یا خرابی است، صحیح است.
exceptions.exception_message رشته پیامی مرتبط با استثنا
exceptions.frames رکورد تکرار شده فریم‌های مرتبط با استثنا
exceptions.frames.address INT64 آدرس موجود در تصویر دودویی که حاوی کد است
برای فریم‌های جاوا تنظیم نشده است
exceptions.frames.blamed بولی اینکه آیا Crashlytics تشخیص داده است که این فریم علت خرابی یا خطا است یا خیر
exceptions.frames.file رشته نام فایل فریم
exceptions.frames.library رشته نام نمایشی کتابخانه‌ای که شامل قاب است
exceptions.frames.line INT64 شماره خط فایل فریم
exceptions.frames.offset INT64 بایت آفست به تصویر دودویی که حاوی کد است
برای استثنائات جاوا تنظیم نشده است
exceptions.frames.owner رشته برای مثال، DEVELOPER ، VENDOR ، RUNTIME ، PLATFORM یا SYSTEM
exceptions.frames.symbol رشته نماد هیدراته یا نماد خام در صورت عدم هیدراته بودن
exceptions.nested بولی برای همه موارد به جز استثنای آخرین رکورد (یعنی اولین رکورد) صادق است.
exceptions.subtitle رشته زیرعنوان تاپیک
exceptions.title رشته عنوان تاپیک
exceptions.type رشته نوع استثنا (برای مثال، java.lang.IllegalStateException)
installation_uuid رشته شناسه‌ای که یک برنامه و نصب دستگاه منحصر به فرد را مشخص می‌کند
is_fatal بولی اینکه آیا برنامه از کار افتاده است یا خیر
issue_id رشته مسئله مرتبط با رویداد
logs رکورد تکرار شده پیام‌های لاگ با مهر زمانی تولید شده توسط ثبت‌کننده‌ی Crashlytics ، در صورت فعال بودن
logs.message رشته پیام ثبت شده
logs.timestamp مهر زمانی وقتی لاگ ساخته شد
memory رکورد وضعیت حافظه دستگاه
memory.free INT64 بایت‌های حافظه باقی مانده
memory.used INT64 بایت‌های حافظه استفاده شده
operating_system رکورد جزئیات سیستم عامل روی دستگاه
operating_system.device_type رشته نوع دستگاه (مثلاً MOBILE ، TABLET ، TV و غیره)؛ همچنین به عنوان "دسته دستگاه" شناخته می‌شود.
operating_system.display_version رشته نسخه سیستم عامل روی دستگاه
operating_system.modification_state رشته اینکه آیا دستگاه تغییر داده شده است یا خیر (برای مثال، یک برنامه جیلبریک شده MODIFIED و یک برنامه روت شده UNMODIFIED )
operating_system.name رشته نام سیستم عامل روی دستگاه
operating_system.type رشته (فقط برنامه‌های اپل) نوع سیستم عامل در حال اجرا روی دستگاه (مثلاً IOS ، MACOS و غیره)
platform رشته پلتفرم برنامه همانطور که در پروژه Firebase ثبت شده است (مقادیر معتبر: IOS یا ANDROID )
process_state رشته BACKGROUND یا FOREGROUND
storage رکورد حافظه دائمی دستگاه
storage.free INT64 بایت‌های فضای ذخیره‌سازی باقی‌مانده
storage.used INT64 بایت‌های فضای ذخیره‌سازی استفاده شده
threads رکورد تکرار شده موضوعات موجود در زمان رویداد
threads.blamed بولی اینکه آیا Crashlytics تشخیص داده است که این فریم علت خرابی یا خطا است یا خیر
threads.code INT64 (فقط برنامه‌های اپل) کد خطای NSError ثبت‌شده‌ی سفارشی برنامه
threads.crash_address INT64 آدرس سیگنالی که باعث از کار افتادن برنامه شده است؛ فقط در نخ‌های بومی از کار افتاده وجود دارد
threads.crashed بولی اینکه آیا تاپیک از کار افتاده یا نه
threads.frames رکورد تکرار شده قاب‌های نخ
threads.frames.address INT64 آدرس موجود در تصویر دودویی که حاوی کد است
threads.frames.blamed بولی آیا Crashlytics تشخیص داده است که این فریم علت خطا است یا خیر
threads.frames.file رشته نام فایل فریم
threads.frames.library رشته نام نمایشی کتابخانه‌ای که شامل قاب است
threads.frames.line INT64 شماره خط فایل فریم
threads.frames.offset INT64 بایت آفست به تصویر دودویی که حاوی کد است
threads.frames.owner رشته برای مثال، DEVELOPER ، VENDOR ، RUNTIME ، PLATFORM یا SYSTEM
threads.frames.symbol رشته نماد هیدراته یا نماد خام در صورت غیرقابل هیدراته بودن
threads.queue_name رشته (فقط برنامه‌های اپل) صفی که رشته در آن اجرا می‌شد
threads.signal_code رشته کد سیگنالی که باعث خرابی برنامه شده است؛ فقط در نخ‌های بومی خراب‌شده وجود دارد
threads.signal_name رشته نام سیگنالی که باعث خرابی برنامه شده است، فقط در نخ‌های بومی خراب‌شده وجود دارد
threads.subtitle رشته زیرعنوان تاپیک
threads.thread_name رشته نام تاپیک
threads.title رشته عنوان تاپیک
unity_metadata.debug_build بولی اگر این یک ساخت اشکال‌زدایی است
unity_metadata.graphics_copy_texture_support رشته پشتیبانی از کپی کردن بافت گرافیکی همانطور که در API یونیتی تعریف شده است
unity_metadata.graphics_device_id INT64 شناسه دستگاه گرافیکی
unity_metadata.graphics_device_name رشته نام دستگاه گرافیکی
unity_metadata.graphics_device_type رشته نوع دستگاه گرافیکی
unity_metadata.graphics_device_vendor_id INT64 شناسه فروشنده پردازنده گرافیکی
unity_metadata.graphics_device_vendor رشته فروشنده دستگاه گرافیکی
unity_metadata.graphics_device_version رشته نسخه دستگاه گرافیکی
unity_metadata.graphics_max_texture_size INT64 حداکثر اندازه اختصاص داده شده به رندر بافت
unity_metadata.graphics_memory_size_mb INT64 حافظه گرافیکی بر حسب مگابایت
unity_metadata.graphics_render_target_count INT64 تعداد اهداف رندر گرافیکی
unity_metadata.graphics_shader_level INT64 سطح سایه‌زنی گرافیک
unity_metadata.processor_count INT64 تعداد پردازنده‌ها (هسته‌ها)
unity_metadata.processor_frequency_mhz INT64 فرکانس پردازنده (ها) بر حسب مگاهرتز
unity_metadata.processor_type رشته نوع پردازنده
unity_metadata.screen_refresh_rate_hz INT64 نرخ تازه‌سازی صفحه نمایش بر حسب هرتز
unity_metadata.screen_resolution_dpi رشته DPI صفحه نمایش به عنوان یک عدد ممیز شناور
unity_metadata.screen_size_px رشته اندازه صفحه نمایش بر حسب پیکسل، با فرمت عرض × ارتفاع
unity_metadata.system_memory_size_mb INT64 اندازه حافظه سیستم بر حسب مگابایت
unity_metadata.unity_version رشته نسخه یونیتی که روی این دستگاه اجرا می‌شود
user رکورد (اختیاری) اطلاعات جمع‌آوری‌شده درباره کاربر برنامه
user.email رشته (اختیاری) آدرس ایمیل کاربر
user.id رشته (اختیاری) یک شناسه مخصوص برنامه که به کاربر مرتبط است
user.name رشته (اختیاری) نام کاربر
variant_id رشته نوع مشکل مرتبط با این رویداد
توجه داشته باشید که همه رویدادها دارای یک نوع مشکل مرتبط نیستند.


ارتقاء به زیرساخت‌های صادراتی جدید

در اواسط اکتبر ۲۰۲۴، Crashlytics زیرساخت جدیدی را برای صادرات دسته‌ای داده‌های Crashlytics به BigQuery راه‌اندازی کرد.

تمام پروژه‌های فایربیس از ۱۵ سپتامبر ۲۰۲۵ به طور خودکار به زیرساخت جدید صادرات دسته‌ای ارتقا خواهند یافت. می‌توانید قبل از این تاریخ ارتقا دهید ، اما مطمئن شوید که جداول دسته‌ای BigQuery شما پیش‌نیازهای ارتقا را برآورده می‌کنند.

شما می‌توانید به زیرساخت جدید ارتقا دهید ، اما مطمئن شوید که جداول دسته‌ای BigQuery شما پیش‌نیازهای ارتقا را برآورده می‌کنند.

مشخص کنید که آیا روی زیرساخت جدید هستید یا خیر

اگر صادرات دسته‌ای را در اواسط اکتبر ۲۰۲۴ یا بعد از آن فعال کرده باشید، پروژه Firebase شما به طور خودکار از زیرساخت صادرات جدید استفاده می‌کند.

می‌توانید بررسی کنید که پروژه شما از کدام زیرساخت استفاده می‌کند: به کنسول Google Cloud بروید و اگر "پیکربندی انتقال داده" شما با عنوان Firebase Crashlytics with Multi-Region Support برچسب‌گذاری شده باشد، پروژه شما از زیرساخت صادرات جدید استفاده می‌کند.

تفاوت‌های مهم بین زیرساخت‌های صادراتی قدیمی و زیرساخت‌های صادراتی جدید

  • زیرساخت جدید از مجموعه داده‌های Crashlytics در مکان‌های خارج از ایالات متحده پشتیبانی می‌کند.

    • صادرات قبل از اواسط اکتبر ۲۰۲۴ فعال شده و به زیرساخت صادرات جدید ارتقا یافته است - اکنون می‌توانید به صورت اختیاری مکان صادرات داده‌ها را تغییر دهید .

    • فعال‌سازی صادرات در اواسط اکتبر ۲۰۲۴ یا بعد از آن — در هنگام راه‌اندازی از شما خواسته شد تا مکانی را برای صادرات داده‌ها انتخاب کنید.

  • زیرساخت جدید از پر کردن مجدد داده‌های مربوط به قبل از فعال کردن قابلیت خروجی گرفتن پشتیبانی نمی‌کند.

    • زیرساخت قدیمی تا 30 روز قبل از تاریخی که شما صادرات را فعال کردید، از پر کردن مجدد پشتیبانی می‌کرد.

    • زیرساخت جدید از پر کردن مجدد داده‌ها تا 30 روز گذشته یا برای جدیدترین تاریخی که امکان صادرات به BigQuery را فعال کرده‌اید (هر کدام که جدیدتر باشد) پشتیبانی می‌کند.

  • این زیرساخت جدید، جداول دسته‌ای BigQuery را با استفاده از شناسه‌های تعیین‌شده برای برنامه‌های 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 و یک برنامه اندروید Firebase با نام بسته com.yourcompany.yourproject در پروژه Firebase خود ثبت کرده‌اید.

  2. اگر نام جدول‌های دسته‌ای شما با شناسه‌های تعیین‌شده برای برنامه‌های Firebase ثبت‌شده‌تان مطابقت ندارد ، قبل از به‌روزرسانی دستی یا قبل از ۱۵ سپتامبر ۲۰۲۵، دستورالعمل‌های بعدی در این صفحه را دنبال کنید تا از اختلال در خروجی دسته‌ای خود جلوگیری کنید.

مرحله ۲ : ارتقاء دستی به زیرساخت جدید

اگر قبل از اواسط اکتبر ۲۰۲۴، قابلیت صادرات دسته‌ای را فعال کرده باشید، می‌توانید به صورت دستی و با خاموش و روشن کردن صادرات داده‌های Crashlytics در کنسول Firebase ، زیرساخت جدید را ارتقا دهید.

در اینجا مراحل دقیق آمده است:

  1. در کنسول Firebase ، به صفحه Integrations بروید.

  2. در کارت BigQuery ، روی مدیریت (Manage) کلیک کنید.

  3. برای غیرفعال کردن خروجی، نوار لغزنده Crashlytics را به حالت خاموش تغییر دهید. وقتی از شما خواسته شد، تأیید کنید که می‌خواهید خروجی داده‌ها متوقف شود.

  4. بلافاصله دوباره نوار لغزنده Crashlytics را روشن کنید تا صادرات دوباره فعال شود. وقتی از شما خواسته شد، تأیید کنید که می‌خواهید داده‌ها را صادر کنید.

    اکنون داده‌های Crashlytics شما از طریق زیرساخت جدید به BigQuery منتقل می‌شوند.

نام جدول دسته‌ای فعلی شما با شناسه برنامه Firebase شما مطابقت ندارد