تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

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

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

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

في وحدة تحكّم Firebase، انتقِل إلى صفحة عمليات الدمج.
في بطاقة BigQuery، انقر على ربط.
اتّبِع التعليمات الظاهرة على الشاشة لتفعيل ميزة التصدير إلى BigQuery.

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

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

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

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

ملاحظة: لا تتوفّر إمكانية اختيار الموقع الجغرافي وتغييره لتصدير البيانات إلا إذا فعّلت ميزة التصدير بعد منتصف أكتوبر 2024 أو إذا رقّيت إلى البنية الأساسية الجديدة للتصدير.
يتم تلقائيًا ربط جميع التطبيقات الموجودة ضمن مشروعك بـ BigQuery، وبالنسبة إلى أية تطبيقات تتم إضافتها إلى المشروع لاحقًا، يتم أيضًا ربطها تلقائيًا بـ 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، سيتوفّر لك جدول في الوقت الفعلي بالإضافة إلى جدول الدفعات. في ما يلي الاختلافات التي يجب أن تكون على دراية بها بين الجدولَين:

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

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

بشكلٍ تلقائي، يبلغ وقت انتهاء صلاحية القسم في جدول الوقت الفعلي 30 يومًا. لمعرفة كيفية تعديل ذلك، راجِع ضبط تاريخ انتهاء صلاحية القسم في مستندات BigQuery.

^{* يمكنك الاطّلاع على تفاصيل حول إمكانية توفير بيانات سابقة في
الترقية إلى البنية الأساسية الجديدة للتصدير.}

تفعيل تصدير بث Crashlytics إلى BigQuery

في وحدة تحكّم Firebase، انتقِل إلى صفحة عمليات الدمج.
في بطاقة BigQuery، انقر على إدارة.
ضَع علامة في مربّع الاختيار تضمين البث.

يتيح هذا الإجراء البث لجميع تطبيقاتك المرتبطة.

ألا تظهر لك البيانات في جدول الوقت الفعلي؟

تأكَّد من أنّك أرسلت حدثَين على الأقل من تطبيقك إلى Crashlytics وانتظرت بضع دقائق بعد إرسالهما.
تأكَّد من أنّ مشروعك على Firebase يستخدِم خطة أسعار Blaze التي تتيح الدفع حسب الاستخدام.
يمكنك التحقّق من ذلك من خلال النظر إلى أسفل يمين وحدة تحكّم Firebase.
إذا لم تظهر أي بيانات في جدول الوقت الفعلي بعد إرسال حدثَين والانتظار بضع دقائق، اتّبِع الخطوات التالية:
1. انتقِل إلى بطاقة BigQuery في وحدة تحكّم Firebase.
2. أوقِف ميزة تصدير البث المباشر ثم أعِد تفعيلها.
3. تأكَّد من أنّ حساب الخدمة service-PROJECT_NUMBER@gcp-sa-crashlytics.iam.gserviceaccount.com موجود في مشروعك على Firebase ولديه دور وكيل خدمة Firebase Crashlytics.
  يمكنك التحقّق من ذلك في صفحة إدارة الهوية وإمكانية الوصول في Google Cloud console (احرص على وضع علامة في مربّع الاختيار تضمين عمليات منح الأدوار التي تقدّمها Google).
4. أرسِل حدثَين على الأقل إلى Crashlytics وانتظِر بضع دقائق.
إذا لم تظهر لك البيانات في الجدول في الوقت الفعلي، يُرجى التواصل مع فريق دعم Firebase.

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

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

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

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

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

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 ساعة).

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 المرتبطة بكل حدث تعطل.

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 متاح للاستخدام قبل إطلاقه. معظم المستخدمين يحبون هذا التطبيق، ولكن ثلاثة منهم واجهوا عددًا غير معتاد من الأعطال. للوصول إلى سبب المشكلة، يمكنك كتابة طلب بحث يستردّ جميع أحداث الأعطال لهؤلاء المستخدمين باستخدام أرقام تعريف المستخدمين.

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

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

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 وحزمة تطوير البرامج Crashlytics.

Swift

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

Objective-C

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

Java

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

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

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 لإزالة أي أحداث مكرّرة من الجدولَين.

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

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

اسم الحقل	نوع البيانات	الوصف
`platform`	سلسلة	منصّة التطبيق كما تم تسجيلها في مشروع Firebase (القيم الصالحة: `IOS` أو `ANDROID`)
`bundle_identifier`	سلسلة	المعرّف الفريد للتطبيق كما هو مسجّل في مشروع Firebase (مثلاً، `com.google.gmail`) بالنسبة إلى تطبيقات منصة Apple، هذا هو رقم تعريف الحزمة الخاص بالتطبيق. بالنسبة إلى تطبيقات Android، هذا هو اسم حزمة التطبيق.
`event_id`	سلسلة	المعرّف الفريد للحدث
`is_fatal`	قيمة منطقية	تم إيقاف هذا الحقل نهائيًا. استخدِم `error_type` بدلاً من ذلك. ما إذا كان التطبيق قد تعطل
`error_type`	سلسلة	نوع الخطأ في الحدث (على سبيل المثال، `FATAL` أو `NON_FATAL` أو `ANR` أو غير ذلك)
`issue_id`	سلسلة	المشكلة المرتبطة بالحدث
`variant_id`	سلسلة	نوع المشكلة المرتبط بهذا الحدث يُرجى العِلم أنّه لا تتضمّن جميع الأحداث نوع مشكلة مرتبطًا بها.
`event_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` والتطبيق المزوّد بإذن الوصول إلى الجذر `UNMODIFIED`)
`operating_system.type`	سلسلة	(تطبيقات Apple فقط) نوع نظام التشغيل الذي يعمل على الجهاز (على سبيل المثال، `IOS` أو `MACOS` أو غير ذلك)
`operating_system.device_type`	سلسلة	نوع الجهاز (على سبيل المثال، `MOBILE` أو `TABLET` أو `TV` وما إلى ذلك)، ويُعرف أيضًا باسم "فئة الجهاز"
`application`	سجلّ	التطبيق الذي أنشأ الحدث
`application.build_version`	سلسلة	إصدار بنية التطبيق
`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`	سجلّ متكرّر	رسائل السجلّات التي تحمل طابعًا زمنيًا والتي تم إنشاؤها بواسطة أداة تسجيل Crashlytics، في حال تفعيلها
`logs.timestamp`	الطابع الزمني	وقت إنشاء السجلّ
`logs.message`	سلسلة	الرسالة المسجّلة
`breadcrumbs`	سجلّ متكرّر	Google Analytics أشرطة التنقل التي تتضمّن طوابع زمنية، في حال تفعيلها
`breadcrumbs.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`	قيمة منطقية	صحيح لكل الاستثناءات التي تم طرحها باستثناء الاستثناء الأخير (أي السجلّ الأول)
`exceptions.title`	سلسلة	عنوان سلسلة المحادثات
`exceptions.subtitle`	سلسلة	العنوان الفرعي لسلسلة المحادثات
`exceptions.blamed`	قيمة منطقية	صحيح إذا حدّد 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`	قيمة منطقية	إذا كان هذا إصدارًا مخصّصًا لتصحيح الأخطاء
`unity_metadata.processor_type`	سلسلة	نوع المعالج
`unity_metadata.processor_count`	INT64	عدد المعالجات (الأنوية)
`unity_metadata.processor_frequency_mhz`	INT64	تمثّل هذه السمة تردد المعالجات بالميغاهرتز.
`unity_metadata.system_memory_size_mb`	INT64	حجم ذاكرة النظام بالميغابايت
`unity_metadata.graphics_memory_size_mb`	INT64	ذاكرة الرسومات بالميغابايت
`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	مستوى التظليل للرسومات
`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`	سلسلة	حجم الشاشة بالبكسل، ويتم تنسيقه على النحو التالي: العرض × الارتفاع
`unity_metadata.screen_resolution_dpi`	سلسلة	تمثّل هذه السمة عدد النقاط لكل بوصة في الشاشة كعدد عشري.
`unity_metadata.screen_refresh_rate_hz`	INT64	معدّل إعادة تحميل الشاشة بالهرتز

إنشاء عرض مرئي لبيانات Crashlytics التي تم تصديرها باستخدام "مركز البيانات"

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

لمزيد من المعلومات حول استخدام "مركز البيانات"، يمكنك تجربة دليل البدء السريع في "مركز البيانات"، مرحبًا بك في "مركز البيانات".

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

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

افتح Crashlytics نموذج لوحة بيانات "مركز البيانات".
انقر على استخدام النموذج في أعلى يسار الصفحة.
في القائمة المنسدلة مصدر بيانات جديد، اختَر إنشاء مصدر بيانات جديد.
انقر على اختيار في بطاقة BigQuery.
اختَر جدولاً يحتوي على بيانات Crashlytics تم تصديرها من خلال النقر على مشاريعي > PROJECT_ID > firebase_crashlytics > TABLE_NAME.

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

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

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

ستتم تلقائيًا ترقية جميع مشاريع Firebase إلى البنية الأساسية الجديدة لتصدير البيانات المجمّعة في موعد أقصاه 15 سبتمبر 2025. يمكنك الترقية قبل هذا التاريخ، ولكن تأكَّد من أنّ جداول الدفعة BigQuery تستوفي المتطلبات الأساسية للترقية.

يمكنك الترقية إلى البنية الأساسية الجديدة، ولكن تأكَّد من أنّ جداول الدفعات BigQuery تستوفي المتطلبات الأساسية للترقية.

تحديد ما إذا كنت تستخدم البنية الأساسية الجديدة

إذا فعّلت ميزة التصدير المجمّع في منتصف أكتوبر 2024 أو بعده، سيستخدم مشروعك على Firebase تلقائيًا البنية الأساسية الجديدة للتصدير.

يمكنك التحقّق من البنية الأساسية التي يستخدمها مشروعك: انتقِل إلى وحدة تحكّم Google Cloud، وإذا كان إعداد نقل البيانات يحمل التصنيف Firebase Crashlytics with Multi-Region Support، يعني ذلك أنّ مشروعك يستخدم بنية التصدير الأساسية الجديدة.

الاختلافات المهمة بين البنية الأساسية القديمة للتصدير والبنية الأساسية الجديدة للتصدير

تتيح البنية الأساسية الجديدة تحديد مواقع جغرافية لمجموعات البيانات خارج الولايات المتحدة.Crashlytics
- تم تفعيل التصدير قبل منتصف أكتوبر 2024 وتمت ترقيته إلى البنية الأساسية الجديدة للتصدير: يمكنك الآن تغيير الموقع الجغرافي لتصدير البيانات بشكل اختياري.
- تم تفعيل التصدير في منتصف أكتوبر 2024 أو بعد ذلك — طُلب منك أثناء عملية الإعداد اختيار موقع جغرافي لتصدير البيانات.
لا تتيح البنية الأساسية الجديدة إعادة ملء البيانات من قبل تفعيل التصدير.
- كانت البنية الأساسية القديمة تتيح إعادة تعبئة البيانات لمدة تصل إلى 30 يومًا قبل تاريخ تفعيل ميزة التصدير.
- تتيح البنية الأساسية الجديدة إمكانية تعبئة البيانات السابقة لغاية آخر 30 يومًا أو لأحدث تاريخ فعّلت فيه ميزة التصدير إلى BigQuery (أيّهما أحدث).
تسمّي البنية الأساسية الجديدة جداول الدفعات BigQuery باستخدام المعرّفات التي تم ضبطها لتطبيقات Firebase في مشروعك على Firebase.
- كانت البنية الأساسية القديمة تكتب البيانات في جداول مجمّعة بأسماء تستند إلى أرقام تعريف الحِزم أو أسماء الحِزم في إعدادات Firebase في قاعدة رموز تطبيقك.
- تكتب البنية الأساسية الجديدة البيانات في جداول مجمّعة بأسماء تستند إلى أرقام تعريف الحِزم أو أسماء الحِزم المحدّدة لتطبيقات Firebase المسجّلة في مشروعك على Firebase.
ملاحظة مهمة: إذا فعّلت ميزة التصدير المجمّع قبل منتصف أكتوبر 2024، عليك التأكّد من أنّ جداولك المجمّعة الحالية تستوفي المتطلبات الأساسية المتعلّقة بمعرّفات الحِزم وأسماء الحِزم قبل الترقية يدويًا إلى البنية الأساسية الجديدة للتصدير أو قبل 15 سبتمبر 2025 (وهو الموعد الذي من المقرر أن تتم فيه ترقية جميع المشاريع تلقائيًا).

الخطوة 1: المتطلبات الأساسية للترقية

تأكَّد من أنّ جداول الدفعات الحالية BigQuery تستخدم معرّفات مطابقة لمعرّفات الحِزم أو أسماء الحِزم المحدّدة لتطبيقاتك المسجّلة على Firebase في مشروعك على Firebase. في حال عدم تطابقها، قد تحدث انقطاعات في بيانات الدُفعات التي تم تصديرها. ستكون معظم المشاريع في حالة مناسبة ومتوافقة، ولكن من المهم التحقّق من ذلك قبل الترقية.
- يمكنك العثور على جميع تطبيقات Firebase المسجّلة في مشروعك على Firebase في Firebase وحدة التحكّم: انتقِل إلى إعدادات المشروع، ثم انتقِل إلى بطاقة تطبيقاتك للاطّلاع على جميع تطبيقات Firebase ومعلوماتها.
- يمكنك العثور على جميع جداول الدفعات في BigQuery ضمن صفحة BigQuery في وحدة تحكّم Google Cloud.
ملاحظة: لا تتأثّر جداول البث BigQuery التي تنتهي بـ REALTIME بالبنية الأساسية الجديدة للتصدير ويمكن تجاهلها.

على سبيل المثال، إليك الحالات المثالية التي لن تواجه فيها أي مشاكل عند الترقية:
- لديك جدول دفعات باسم com_yourcompany_yourproject_IOS وتطبيق Firebase iOS+ بمعرّف الحزمة com.yourcompany.yourproject مسجَّل في مشروعك على Firebase.
- لديك جدول دفعي باسم com_yourcompany_yourproject_ANDROID وتطبيق Android على Firebase باسم الحزمة com.yourcompany.yourproject مسجَّل في مشروعك على Firebase.
إذا كانت لديك أسماء جداول دفعية لا تتطابق مع المعرّفات التي تم ضبطها لتطبيقات Firebase المسجّلة، عليك اتّباع التعليمات الواردة لاحقًا في هذه الصفحة قبل الترقية يدويًا أو قبل 15 سبتمبر 2025 لتجنُّب حدوث انقطاع في عملية التصدير الدفعي.

الخطوة 2: الترقية يدويًا إلى البنية الأساسية الجديدة

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

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

في وحدة تحكّم Firebase، انتقِل إلى صفحة عمليات الدمج.
في بطاقة BigQuery، انقر على إدارة.
انقر على شريط التمرير Crashlytics لإيقاف خيار التصدير. عندما يُطلب منك ذلك، أكِّد رغبتك في إيقاف عملية تصدير البيانات.
أعِد تفعيل شريط التمرير Crashlytics على الفور لإعادة تفعيل التصدير. عندما يُطلب منك ذلك، أكِّد أنّك تريد تصدير البيانات.

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

لا يتطابق اسم جدول الدفعات الحالي مع معرّف تطبيق Firebase

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

إذا كانت لديك جداول دفعات BigQuery حالية في هذه الحالة، يعني ذلك أنّها غير متوافقة مع البنية الأساسية الجديدة لعملية التصدير إلى BigQuery في Firebase. يُرجى العلم أنّه سيتم نقل جميع مشاريع Firebase تلقائيًا إلى البنية الأساسية الجديدة للتصدير في أقرب وقت ممكن من 15 سبتمبر 2025.

يُرجى اتّباع الإرشادات الواردة في هذا القسم قبل الترقية يدويًا أو قبل 15 أيلول (سبتمبر) 2025 لتجنُّب حدوث أي مشاكل في عملية التصدير المجمّع لبيانات Crashlytics إلى BigQuery.

الانتقال إلى تعليمات الخيارات لتجنُّب حدوث انقطاعات

فهم كيفية استخدام البنية الأساسية للتصدير المعرّفات لكتابة البيانات في جداول BigQuery

في ما يلي كيفية كتابة بنيتَي التصدير لبيانات Crashlytics في جداول الدفعات BigQuery:

البنية الأساسية القديمة للتصدير: تكتب البيانات في جدول باسم يستند إلى معرّف الحزمة أو اسم الحزمة في إعدادات Firebase في قاعدة رموز تطبيقك (عادةً من ملف GoogleService-Info.plist أو ملف google-services.json).
بنية أساسية جديدة للتصدير: تكتب البيانات في جدول باسم يستند إلى معرّف الحزمة أو اسم الحزمة المحدّد لتطبيقك المسجّل على Firebase في مشروعك على Firebase.

في بعض الأحيان، لا يتطابق معرّف الحزمة أو اسم الحزمة في الإعدادات في قاعدة الرموز مع معرّف الحزمة أو اسم الحزمة المحدّد لتطبيق Firebase المسجّل في مشروع Firebase. يحدث ذلك عادةً إذا عدّل أحد المستخدمين ملف الإعداد يدويًا في قاعدة الرموز البرمجية لتطبيقك أو إذا لم يُدخل المعرّف الفعلي أثناء تسجيل التطبيق.

ماذا يحدث إذا لم يتم حلّ هذه المشكلة قبل الترقية؟

إذا لم تتطابق المعرّفات في هذين الموقعَين، سيحدث ما يلي بعد الترقية إلى البنية الأساسية الجديدة للتصدير:

ستبدأ بيانات Crashlytics في الكتابة إلى جدول دفعات جديد BigQuery، أي جدول جديد باسم يستند إلى معرّف الحزمة أو اسم الحزمة المحدّد لتطبيقك المسجّل على Firebase في مشروعك على Firebase.
لن يتم بعد ذلك كتابة البيانات في أي جدول "قديم" حالي يحمل اسمًا يستند إلى المعرّف في ملف الإعدادات في قاعدة الرموز.

أمثلة على سيناريوهات عدم تطابق المعرّفات

يُرجى العِلم أنّه تتم إضافة BigQuery تلقائيًا إلى أسماء جداول الدفعات مع _IOS أو _ANDROID للإشارة إلى نظام تشغيل التطبيق.

المعرّفات في قاعدة رموز تطبيقك	المعرّفات التي تم ضبطها لتطبيقاتك على Firebase	الإجراء القديم	السلوك بعد الترقية إلى البنية الأساسية الجديدة للتصدير	بدون نظام تشغيل
`foo`	`bar`	تتم الكتابة إلى جدول واحد يحمل اسم المعرّف في قاعدة الرموز البرمجية للتطبيق (`foo`)	تنشئ هذه العملية جدولاً واحدًا ثم تكتب فيه، ويتم تسمية الجدول باسم مجموعة المعرّفات الخاصة بتطبيق Firebase (`bar`).	نفِّذ الخيار 1 أو 2 الموضّح أدناه.
`foo`	‫`bar` و`qux` وما إلى ذلك	تتم الكتابة إلى جدول واحد يحمل اسم المعرّف في قاعدة الرموز البرمجية للتطبيق (`foo`)	تُنشئ* ثم تكتب في جداول متعدّدة تحمل أسماء المعرّفات التي تم ضبطها لتطبيقات Firebase (`bar` و`qux` وما إلى ذلك).	نفِّذ الخيار 2 الموضّح أدناه.
‫`foo` و`baz` وما إلى ذلك	`bar`	تتم الكتابة إلى جداول متعددة تحمل أسماء المعرّفات المتعددة في قاعدة رموز التطبيق (`foo` و`baz` وما إلى ذلك).	يتم إنشاء** ثم كتابة بيانات كل تطبيق في جدول واحد باسم بعد المعرّف الذي تم ضبطه لتطبيق Firebase (`bar`)	لا يمكن تنفيذ أي من الخيارات. سيظل بإمكانك التمييز بين البيانات من كل تطبيق داخل الجدول الواحد باستخدام `bundle_identifier` الخاص بالتطبيق، والذي يتم تصديره مع البيانات.

^{* إذا كان المعرّف في قاعدة رموز تطبيقك مطابقًا لأحد المعرّفات التي تم ضبطها لتطبيق Firebase، لن تنشئ البنية الأساسية الجديدة للتصدير جدولاً جديدًا لهذا المعرّف. بدلاً من ذلك، سيواصل كتابة البيانات الخاصة بهذا التطبيق. سيتم تسجيل جميع التطبيقات الأخرى في جداول جديدة.}

^{** إذا تطابق أحد المعرّفات في قاعدة رموز تطبيقك مع المعرّف الذي تم ضبطه لتطبيق Firebase، لن تنشئ البنية الأساسية الجديدة للتصدير جدولاً جديدًا. بدلاً من ذلك، سيتم الاحتفاظ بهذا الجدول والبدء في كتابة البيانات الخاصة بجميع التطبيقات فيه.}

خيارات لتجنُّب انقطاع الخدمة

لتجنُّب أي انقطاع في الخدمة، اتّبِع التعليمات الخاصة بأحد الخيارات الموضّحة أدناه قبل الترقية يدويًا أو قبل 15 أيلول (سبتمبر) 2025.

الخيار 1:
استخدام الجدول الجديد الذي أنشأته البنية الأساسية الجديدة للتصدير عليك نسخ البيانات من الجدول الحالي إلى الجدول الجديد.
1. في Firebase console، يمكنك الترقية إلى البنية الأساسية الجديدة للتصدير من خلال إيقاف التصدير ثم إعادة تفعيله للتطبيق المرتبط.
  
  يؤدي هذا الإجراء إلى إنشاء جدول مجموعة جديد باسم يستند إلى معرّف الحزمة أو اسم الحزمة المحدّد لتطبيقك المسجّل على Firebase في مشروعك على Firebase.
2. في Google Cloud وحدة التحكّم، انسخ كل البيانات من الجدول القديم إلى الجدول الجديد الذي تم إنشاؤه للتو.
3. إذا كانت لديك أي تبعيات لاحقة تعتمد على جدول الدفعات، غيِّرها لاستخدام الجدول الجديد.
ملاحظة: بعد الترقية، لن يتم كتابة البيانات الجديدة في جدولك القديم. لن يتم حذف أي بيانات تمت كتابتها سابقًا في الجدول القديم.
الخيار 2:
مواصلة الكتابة في جدولك الحالي ولتحقيق ذلك، عليك تجاوز بعض الإعدادات التلقائية في ملف إعدادات BigQuery.
1. في Firebase، ابحث عن معرّف تطبيق Firebase (على سبيل المثال، 1:1234567890:ios:321abc456def7890) للتطبيق الذي يتضمّن اسم جدول الدفعات ومعرّفه غير المتطابقَين، واحتفظ به:
  انتقِل إلى إعدادات المشروع، ثم انتقِل إلى بطاقة تطبيقاتك للاطّلاع على جميع تطبيقاتك على Firebase ومعلوماتها.
2. في Firebase console، يمكنك الترقية إلى البنية الأساسية الجديدة للتصدير من خلال إيقاف التصدير ثم إعادة تفعيله للتطبيق المرتبط.
  
  يؤدي هذا الإجراء إلى ما يلي:
  - تُنشئ هذه الطريقة جدولاً جديدًا للدفعات باسم يستند إلى رقم تعريف الحزمة أو اسم الحزمة المحدّد لتطبيقك المسجّل على Firebase في مشروعك على Firebase. (ستحذف هذا الجدول في النهاية، ولكن لا تحذفه بعد).
  - تُنشئ هذه الطريقة BigQuery "إعداد نقل بيانات" مع المصدر Firebase Crashlytics with Multi-Region Support.
3. في وحدة تحكّم Google Cloud، غيِّر "إعداد نقل البيانات" الجديد حتى تستمر كتابة البيانات في جدولك الحالي:
  1. انتقِل إلى BigQuery > عمليات نقل البيانات للاطّلاع على "إعدادات نقل البيانات".
  2. اختَر الإعداد الذي يتضمّن المصدر Firebase Crashlytics with Multi-Region Support.
  3. انقر على تعديل في أعلى يسار الصفحة.
  4. في قسم تفاصيل مصدر البيانات، ابحث عن قائمة gmp_app_id وقائمة client_namespace.
    
    في BigQuery، يُطلق على معرّف التطبيق في Firebase اسم gmp_app_id. بشكلٍ تلقائي، تكون قيمة client_namespace في BigQuery هي المعرّف الفريد لحزمة التطبيق أو اسم الحزمة المقابل، ولكن سيتم إلغاء هذا الإعداد التلقائي.
    
    تستخدِم BigQuery قيمة client_namespace لاسم جدول الدفعات الذي يكتب إليه كل تطبيق مرتبط على Firebase.
  5. ابحث عن gmp_app_id لتطبيق Firebase الذي تريد إلغاء الإعدادات التلقائية له. غيِّر قيمة client_namespace إلى اسم الجدول الذي تريد أن يكتب إليه تطبيق Firebase بدلاً من ذلك (عادةً ما يكون هذا هو اسم الجدول القديم الذي كان التطبيق يكتب إليه باستخدام البنية الأساسية القديمة للتصدير).
    
    ملاحظة: إذا كنت تكتب سابقًا في جدول واحد وأصبح لديك الآن جداول متعددة بعد الترقية، يمكنك استخدام الرمز نفسه client_namespace لكل gmp_app_id ينطبق عليه ذلك. سيؤدي ذلك بشكل أساسي إلى دمج جميع الجداول وكتابة جميع البيانات لجميع تطبيقات Firebase في جدول واحد.
    BigQuery
  6. احفظ التغيير في الإعدادات.
4. جدولة عملية إضافة البيانات السابقة للأيام التي لا يتضمّن جدولك الحالي بياناتها
5. بعد اكتمال عملية إعادة التعبئة، عليك حذف الجدول الجديد الذي أنشأته بنية التصدير الجديدة تلقائيًا.

تصدير بيانات Firebase Crashlytics إلى BigQuery تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

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

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

ما هي البيانات التي يتم تصديرها إلى BigQuery؟

Crashlytics تصدير متواصل إلى BigQuery

تفعيل تصدير بث Crashlytics إلى BigQuery

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

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

إنشاء طرق عرض

تنفيذ طلبات البحث

المثال 1: الأعطال حسب اليوم

المثال 2: العثور على الأعطال الأكثر انتشارًا

المثال 3: أفضل 10 أجهزة تحدث فيها أعطال

المثال 4: الفلترة حسب مفتاح مخصّص

Swift

Objective-C

Java

المثال 5: استخراج رقم تعريف المستخدم

المثال 6: العثور على جميع المستخدمين الذين يواجهون مشكلة معيّنة في الأعطال

المثال 7: عدد المستخدمين المتأثّرين بمشكلة عُطل، مقسَّم حسب البلد

Swift

Objective-C

Java

المثال 8: أهم 5 مشاكل حتى الآن اليوم

المثال 9: أهم 5 مشاكل منذ تاريخ معين، بما في ذلك اليوم

فهم مخطط Crashlytics في BigQuery

مجموعات البيانات

الجداول

الصفوف

الأعمدة

إنشاء عرض مرئي لبيانات Crashlytics التي تم تصديرها باستخدام "مركز البيانات"

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

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

تحديد ما إذا كنت تستخدم البنية الأساسية الجديدة

الاختلافات المهمة بين البنية الأساسية القديمة للتصدير والبنية الأساسية الجديدة للتصدير

الخطوة 1: المتطلبات الأساسية للترقية

الخطوة 2: الترقية يدويًا إلى البنية الأساسية الجديدة

لا يتطابق اسم جدول الدفعات الحالي مع معرّف تطبيق Firebase

فهم كيفية استخدام البنية الأساسية للتصدير المعرّفات لكتابة البيانات في جداول BigQuery

ماذا يحدث إذا لم يتم حلّ هذه المشكلة قبل الترقية؟

أمثلة على سيناريوهات عدم تطابق المعرّفات

خيارات لتجنُّب انقطاع الخدمة

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