تصدير بيانات Firebase Crashlytics إلى BigQuery

يمكنك تصدير بيانات Firebase Crashlytics إلى BigQuery لإجراء مزيد من التحليل. تتيح لك BigQuery تحليل البيانات باستخدام BigQuery SQL وتصديرها إلى مقدّم خدمة آخر لخدمات السحابة الإلكترونية واستخدامها في التمثيل البصري ولوحات البيانات المخصّصة باستخدام "مركز البيانات من Google".

تفعيل التصدير إلى BigQuery

1. في وحدة تحكّم Firebase، انتقِل إلى صفحة "عمليات الدمج".

2. في بطاقة BigQuery، انقر على ربط.

3. اتّبِع التعليمات الظاهرة على الشاشة لتفعيل التصدير إلى BigQuery.

   إذا أردت الوصول إلى بيانات "Crashlytics" في BigQuery بالقرب من الوقت الفعلي، ننصحك بالترقية إلى بث التصدير.

ماذا يحدث عند تفعيل ميزة التصدير؟

• يمكنك اختيار موقع مجموعة البيانات. بعد إنشاء مجموعة البيانات، لا يمكن تغيير الموقع الجغرافي، ولكن يمكنك نسخ مجموعة البيانات إلى موقع جغرافي مختلف أو نقل مجموعة البيانات يدويًا (إعادة إنشائها) في موقع جغرافي مختلف. للاطّلاع على مزيد من المعلومات، يُرجى الاطّلاع على مقالة تغيير الموقع الجغرافي لعمليات التصدير الحالية.

  لا ينطبق هذا الموقع الجغرافي إلا على البيانات التي يتم تصديرها إلى BigQuery، ولا يؤثّر في الموقع الجغرافي للبيانات المخزّنة لاستخدامها في لوحة بيانات Crashlytics في وحدة تحكّم Firebase أو في Android Studio.

• يتم تلقائيًا ربط جميع التطبيقات في مشروعك بمنصّة BigQuery، وبالنسبة إلى أي تطبيقات تتم إضافتها إلى المشروع لاحقًا، يتم أيضًا ربطها تلقائيًا بمنصّة BigQuery. ويمكنك إدارة اختيار التطبيقات التي ترسل البيانات.

• يُعدّ Firebase عمليات مزامنة يومية لبياناتك مع BigQuery.

  • بعد ربط مشروعك، عليك عادةً الانتظار إلى أن تتم عملية المزامنة في اليوم التالي لتصدير مجموعة البيانات الأولى إلى BigQuery.

  • تحدث المزامنة اليومية مرة واحدة في اليوم، بغض النظر عن أي عملية تصدير مجدوَلة قد تكون قد أعددتها في BigQuery. يُرجى العِلم أنّ توقيت مهمة المزامنة ومدتها يمكن أن يتغيّرا، لذا لا ننصح بجدولة عمليات أو مهام ما بعد التصدير استنادًا إلى توقيت محدّد للتصدير.

• تصدِّر Firebase نسخة من بياناتك الحالية إلى BigQuery. قد تستغرق عملية النشر الأولي للبيانات المخصّصة للتصدير مدّة تصل إلى 48 ساعة.

  • لكل تطبيق مرتبط، تتضمّن عملية التصدير هذه جدول دفعات يحتوي على البيانات من المزامنة اليومية.

  • يمكنك تحديد جدول زمني يدويًا لعمليات إضافة البيانات السابقة لجدول الدفعات حتى آخر 30 يومًا أو لأحدث تاريخ عند تفعيل التصدير إلى BigQuery (أيهما أحدث).

  يُرجى العلم أنّه في حال فعّلت تصدير بيانات Crashlytics قبل منتصف تشرين الأول (أكتوبر) 2024، يمكنك أيضًا إضافة بيانات سابقة لمدة 30 يومًا قبل يوم تفعيل التصدير.

• إذا فعّلت تصدير أحداث البث في Crashlytics إلى BigQuery، سيكون لدى جميع التطبيقات المرتبطة أيضًا جدولاً في الوقت الفعلي يحتوي على data باستمرار.

لإيقاف عملية التصدير إلى 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

1. في وحدة تحكّم Firebase، انتقِل إلى صفحة "عمليات الدمج".

2. في بطاقة BigQuery، انقر على إدارة.

3. ضَع علامة في مربّع الاختيار تضمين البث.

يؤدي هذا الإجراء إلى تفعيل ميزة البث لجميع تطبيقاتك المرتبطة.

ما هي الإجراءات التي يمكنك اتّخاذها بشأن البيانات التي تم تصديرها؟

تحتوي عمليات التصدير إلى BigQuery على بيانات الأعطال الأوّلية، بما في ذلك نوع الجهاز ونظام التشغيل والاستثناءات (تطبيقات Android) أو الأخطاء (تطبيقات Apple) وملفّات log Crashlytics، بالإضافة إلى بيانات أخرى.

يمكنك مراجعة البيانات التي يتم تصديرها من Crashlytics وجدول مخطّط البيانات لاحقًا في هذه الصفحة.

استخدام نموذج "مركز البيانات"

لتفعيل البيانات في الوقت الفعلي في نموذج "مركز البيانات"، اتّبِع تعليمات عرض بيانات Crashlytics التي تم تصديرها باستخدام "مركز البيانات".

إنشاء طرق عرض

يمكنك تحويل طلبات البحث إلى عروض باستخدام واجهة مستخدم 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. للاستعداد لمعالجة المشاكل المحتملة في التوافق، يمكنك إعداد طلب بحث يحدِّد الأجهزة العشرة التي سجّلت أكبر عدد من الأعطال خلال الأسبوع الماضي (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، وتعديله في كل مرة يصل فيها المستخدم إلى مستوى جديد.

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

CrashlyticsKit setIntValue:3 forKey:@"current_level";

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: استخراج رقم تعريف المستخدِم

إذا كان لديك تطبيق 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: العثور على جميع المستخدمين الذين يواجهون مشكلة تعطُّل معيّنة

أصدر فريقك عن طريق الخطأ خطأً جسيمًا لمجموعة من مختبِري الإصدار التجريبي. تمكّن فريقك من استخدام طلب البحث من المثال التالي: "العثور على الأعطال الأكثر انتشارًا" أعلاه لتحديد رقم تعريف مشكلة الأعطال المحدّدة. يريد فريقك الآن إجراء query لإخراج قائمة مستخدمي التطبيق المتأثّرين بهذا العُطل.

في ما يلي مثال على طلب بحث لتطبيق 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: عدد المستخدمين المتأثّرين بمشكلة عطل، مقسّمة حسب البلد

رصد فريقك خطأً جسيمًا أثناء طرح إصدار جديد. لقد تمكّنت من استخدام طلب البحث من المثال التالي في "العثور على الأعطال الأكثر انتشارًا" أعلاه لتحديد رقم تعريف مشكلة الأعطال المحدّدة. يريد فريقك الآن معرفة ما إذا كان هذا العُطل قد انتشر إلى مستخدمين في بلدان مختلفة حول العالم.

لكتابة هذا الطلب، على فريقك تنفيذ ما يلي:

1. فعِّل تصدير بيانات Google Analytics إلى BigQuery. اطّلِع على تصدير بيانات المشروع إلى BigQuery.

2. عدِّل تطبيقك لإرسال معرّف مستخدم إلى كلّ من حزمة تطوير البرامج (SDK) لنظام التشغيل Google Analytics وحزمة تطوير البرامج (SDK) لنظام التشغيل Crashlytics.

   Swift

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

   Objective-C

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

   جافا

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

3. اكتب طلب بحث يستخدِم حقل "رقم تعريف المستخدِم" لدمج الأحداث في مجموعة بيانات 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 مشاكل منذ التاريخ، بما في ذلك اليوم

يمكنك أيضًا دمج جداول الدفعات والوقت الفعلي من خلال طلب تجميع لإضافة معلومات الوقت الفعلي إلى بيانات الدفعات الموثوقة. بما أنّ 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)، بما في ذلك الأحداث التي حدثت قبل يومَين كحد أقصى من عملية الربط، مع خيار إضافة البيانات السابقة لمدة تصل إلى 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. إذا كان خيار تصدير بيانات البث إلى BigQuery مفعّلاً، سيحتوي جدول الوقت الفعلي على الأعمدة نفسها في جدول الدُفعات.Crashlytics يُرجى العِلم أنّه قد يكون لديك أعمدة في الصفوف تمثّل أحداثًا لا تتضمّن عمليات تتبُّع تسلسل استدعاء الدوال البرمجية.

يتم إدراج الأعمدة ضمن عملية التصدير في هذا الجدول:

عرض بيانات Crashlytics المُصدَّرة باستخدام "مركز البيانات"

تعمل أداة مركز البيانات من Google على تحويل مجموعة بيانات Crashlytics في BigQuery إلى تقارير أسهل في قراءة ومشاركتها وقابلة للتخصيص بالكامل.

للاطّلاع على مزيد من المعلومات عن استخدام "مركز البيانات"، يمكنك الاطّلاع على دليل البدء السريع في "مركز البيانات"، وهو بعنوان مرحبًا بك في "مركز البيانات".

استخدام نموذج تقرير Crashlytics

يتضمّن Data Studio نموذج تقرير عن Crashlytics يتضمّن مجموعة شاملة من السمات والمقاييس من مخطّط Crashlytics BigQuery الذي تمّ تصديره. إذا فعّلت تصدير أحداث البث المباشر إلى BigQuery، يمكنك عرض هذه البيانات في صفحة المؤشرات في الوقت الفعلي ضمن نموذج "مركز البيانات". يمكنك استخدام العيّنة كنموذج لإنشاء تقارير وعروض مرئية جديدة بسرعة استنادًا إلى بيانات الأعطال الأوّلية لتطبيقك:Crashlytics

1. افتح Crashlytics نموذج لوحة بيانات "مركز البيانات".

2. انقر على استخدام نموذج في أعلى يسار الصفحة.

3. في القائمة المنسدلة مصدر بيانات جديد، انقر على إنشاء مصدر بيانات جديد.

4. انقر على اختيار في بطاقة BigQuery.

5. اختَر جدولاً يحتوي على بيانات Crashlytics التي تم تصديرها من خلال اختيار مشاريعي > PROJECT_ID > firebase_crashlytics > TABLE_NAME.

   يتوفّر جدول الدفعات دائمًا للاختيار. إذا كان خيار تصدير بيانات البث إلى Crashlytics مفعّلاً، يمكنك اختيار جدول الوقت الفعلي بدلاً من ذلك.BigQuery

6. ضمن الإعداد، اضبط Crashlytics مستوى النموذج على تلقائي.

7. انقر على ربط لإنشاء مصدر البيانات الجديد.

8. انقر على الإضافة إلى التقرير للعودة إلى نموذج Crashlytics.

9. أخيرًا، انقر على إنشاء تقرير لإنشاء نسختك من Crashlytics نموذج لوحة البيانات في "مركز البيانات".

الترقية إلى البنية الأساسية الجديدة للتصدير

في منتصف تشرين الأول (أكتوبر) 2024، أطلقت Crashlytics بنية أساسية جديدة لتصدير data Crashlytics إلى BigQuery. في الوقت الحالي، عملية الترقية إلى هذه البنية الأساسية الجديدة اختيارية.

تتيح هذه البنية الأساسية الجديدة Crashlytics موقعًا جغرافيًا لمجموعة البيانات خارج الولايات المتحدة.

• إذا فعّلت ميزة التصدير قبل منتصف تشرين الأول (أكتوبر) 2024، يمكنك الآن اختياريًا تغيير موقع تصدير البيانات إلى أي موقع لمجموعة بيانات متوافقة مع BigQuery.

• إذا فعّلت ميزة التصدير في منتصف تشرين الأول (أكتوبر) 2024 أو لاحقًا، يمكنك اختيار أي موقع جغرافي لمجموعة بيانات متوافقة مع BigQuery أثناء الإعداد.

هناك اختلاف آخر في البنية الأساسية الجديدة، وهو أنّها لا تتيح إعادة تعبئة البيانات من قبل تفعيل التصدير. (باستخدام البنية الأساسية القديمة، يمكنك إضافة بيانات سابقة لمدة تصل إلى 30 يومًا قبل تاريخ التفعيل). تتيح البنية الأساسية الجديدةعمليات إضافة البيانات السابقة لآخر 30 يومًا أو لآخر تاريخ فعّلت فيه التصدير إلى BigQuery (أيهما أحدث).

شرط أساسي للترقية

قبل الترقية إلى البنية الأساسية الجديدة، تأكَّد من استيفاء المتطلبات الأساسية التالية: أن تحتوي جداول الدفعات BigQuery الحالية على معرّفات متطابقة مع معرّفات الحِزم أو أسماء الحِزم التي تم ضبطها لتطبيقات Firebase المسجّلة.

على سبيل المثال:

• إذا كان لديك جدول BigQuery باسم com_yourcompany_yourproject_IOS، من المفترض أن يكون لديك تطبيق Firebase لنظام التشغيل iOS والإصدارات الأحدث مسجَّلًا في مشروعك على Firebase باستخدام رقم تعريف الحِزمة com.yourcompany.yourproject.

• إذا كان لديك جدول BigQuery باسم com_yourcompany_yourproject_ANDROID، من المفترض أن يكون لديك تطبيق Android على Firebase مسجَّل في مشروعك على Firebase باسم الحزمة com.yourcompany.yourproject.

في ما يلي كيفية العثور على جميع تطبيقات Firebase المسجّلة في مشروعك على Firebase:

1. في وحدة تحكّم Firebase، انتقِل إلى settings إعدادات المشروع.

2. انتقِل للأسفل إلى بطاقة تطبيقاتك، ثم انقر على تطبيق Firebase المطلوب لعرض معلومات التطبيق، بما في ذلك معرّفه.

ستصدِّر البنية الأساسية الجديدة للتصدير بيانات كل تطبيق استنادًا إلى اسم الحزمة أو معرّف الحزمة المحدَّد لتطبيق Firebase المسجَّل. ولتجنُّب تعطيل سير عمل BigQuery، من المهم التأكّد من أنّ جداول المعالجة المُجمَّعة الحالية تحتوي على الأسماء الصحيحة حتى تتمكّن البنية الأساسية الجديدة من إلحاق كل البيانات الجديدة بالجداول الحالية. إذا كانت لديك أسماء جداول دفعات لا تطابق تطبيقات Firebase المسجّلة، ولكنك لا تزال تريد الترقية، تواصَل مع فريق دعم Firebase.

كيفية الترقية إلى البنية الأساسية الجديدة

إذا سبق لك تفعيل ميزة التصدير، يمكنك الترقية إلى البنية الأساسية الجديدة ببساطة من خلال إيقاف ميزة تصدير بيانات Crashlytics ثم تفعيلها مرة أخرى في وحدة تحكّم Firebase.

في ما يلي الخطوات المفصّلة التي يجب اتّباعها:

1. في وحدة تحكّم Firebase، انتقِل إلى صفحة "عمليات الدمج".

2. في بطاقة BigQuery، انقر على إدارة.

3. أوقِف شريط التمرير Crashlytics لإيقاف التصدير. عندما يُطلب منك ذلك، أكِّد أنّك تريد إيقاف تصدير البيانات.

4. فعِّل شريط التمرير Crashlytics مرة أخرى على الفور لإعادة تفعيل التصدير. أكِّد أنّك تريد تصدير البيانات عندما يُطلب منك ذلك.

   تستخدم الآن عملية تصدير بيانات Crashlytics إلى BigQuery البنية الأساسية الجديدة للتصدير.