Skip to main content
أرسل السجلات من تطبيق React Native إلى LogBrew. ابدأ بسجل تجريبي واحد، ثم استخدم CLI للعثور عليه في المشروع الصحيح. تستخدم هذه الإرشادات Expo. أما تطبيق React Native المجرد (bare)، فيحمّل المفتاح عبر إعداداته الخاصة. قبل أن تبدأ، تحتاج إلى:
  • تطبيق React Native تستطيع تشغيله محليًا.
  • مشروع LogBrew. راجع المشاريع.
  • CLI مسجَّل الدخول. راجع إعداد CLI.

ثبّت الـ SDK

ثبّت الحزمتين كلتيهما في مجلد التطبيق. أبقِ تبعيات React وReact Native الخاصة بالتطبيق كما هي:

أنشئ مفتاح SDK للمشروع

أعطِ التطبيق مفتاح SDK خاصًا بالمشروع وللكتابة فقط. يضع Expo كل قيمة EXPO_PUBLIC_* في حزمة التطبيق. لا تضع أبدًا بيانات اعتماد الحساب أو الخادم في هذا المتغير. ينشئ CLI بالإصدار v0.1.32 أو أحدث مفتاحًا لمشروع موجود. ولا ينشئ مشروعًا جديدًا. اعثر على معرّف المشروع:
أنشئ المفتاح. استخدم مسار ملف جديدًا في مجلد لا يصل إليه إلا مالكه:
لا تتابع إلا بعد نجاح الأمر. إذا كانت النتيجة غير واضحة، فشغّل الأمر نفسه مرة أخرى بالوسائط نفسها. لا تستخدم --abandon-retry. أبقِ ملف المفتاح خارج نظام التحكم في المصدر. لا تستخدم بيانات اعتماد الحساب التي أذنت لـ CLI. للتطوير المحلي باستخدام Expo، ضع المفتاح في ملف .env.local متجاهَل في جذر التطبيق:
أبقِ المرجع المباشر process.env.EXPO_PUBLIC_LOGBREW_CLIENT_KEY في وحدة الإعداد أدناه. أعد تحميل التطبيق بالكامل بعد أن تغيّر القيمة. راجع متغيرات البيئة في Expo لإعدادات وقت البناء. أما تطبيق React Native المجرد، فيحمّل المفتاح عبر إعداداته الخاصة بدلًا من ذلك.

أنشئ العميل

ضع هذا الإعداد في وحدة واحدة يحمّلها التطبيق عند بدء التشغيل. لا تنشئ عميلًا عند كل عملية عرض (render). ضع الخدمة والبيئة والإصدار في context:
تفعّل وسيلة النقل fetch التسليم التلقائي مع عدد محدود من إعادات المحاولة وطابور. لا تضف مؤقّت تفريغ (flush) ثانيًا. يطلب مستمع AppState تفريغًا أخيرًا عندما يصبح التطبيق غير نشط أو ينتقل إلى الخلفية. استدعِ stopAppStateListener() عند إغلاق التطبيق. مع الطابور الأصلي (native)، لا يستطيع استخدام المفتاح إلا عميل نشط واحد. العميل الثاني للمفتاح نفسه يفشل مع configuration_error. وهذا سبب إضافي لإنشاء العميل مرة واحدة.

أرسل السجل التجريبي واعثر عليه

استدعِ verifyLogBrewSetup() مرة واحدة من إجراء اختبار مخصص للتطوير فقط. انتظر النتيجة، وتعامل مع الـ promise المرفوض. لا تطبع المفتاح أو دفعة الأحداث. النتيجة 2xx مع قيمة batches أكبر من 0 تثبت أن LogBrew قبل الدفعة. والتفريغ الفارغ يعيد 204 مع 0 محاولات و0 دفعات، لأن التسليم التلقائي قد يرسل الحدث أولًا. في الحالتين، اقرأ السجل المحفوظ باستخدام CLI:
افحص وقت الحدث والخدمة في النتيجة. النتيجة الفارغة لا توضح السبب. افحص المشروع والمفتاح والنطاق الزمني. RecordingTransport.alwaysAccept() للاختبارات المحلية فقط. يعيد 202 اصطناعيًا ولا يرسل أي طلب.

التسليم دون اتصال وبعد إعادة التشغيل

اقرأ client.deliveryHealth().storage في التطبيق أثناء تشغيله:
  • persistent: يستخدم العميل الطابور الأصلي. تُحمَّل الأحداث المعلّقة مرة أخرى بعد إعادة تشغيل التطبيق.
  • memory: تضيع الأحداث المعلّقة عند إعادة تشغيل بيئة JavaScript.
الإعداد الافتراضي persistentQueue: "auto" يستخدم الطابور الأصلي عندما يحتوي ملف التطبيق الثنائي على وحدة LogBrew الأصلية. يستخدم Expo Go والملفات الثنائية الأقدم الذاكرة. لا يستطيع تحديث JavaScript فقط إضافة الوحدة الأصلية. إذا احتاج تطبيق في بيئة الإنتاج إلى التسليم بعد إعادة التشغيل، فاضبط persistentQueue: "required". عندها يفشل إنشاء العميل مع configuration_error عندما يكون الطابور الأصلي مفقودًا. أعد بناء التطبيق مع الوحدة الأصلية. استخدم persistentQueue: "disabled" فقط عندما تريد طابورًا في الذاكرة. يتسع الطابور الأصلي لـ 1,000 حدث و4 MiB من بيانات الأحداث على الأكثر. وتنطبق أيضًا حدود العميل الأصغر. تحتفظ الأحداث في الطابور الأصلي بمعرّفاتها بعد إعادة التشغيل. التسليم يحدث مرة واحدة على الأقل، لذا قد ترسل إعادة المحاولة الحدث مرتين. عندما يطابق معرّف الحدث ومحتواه حدثًا قبله LogBrew من قبل، لا يخزّنه LogBrew مرة أخرى. التفريغ في الخلفية محاولة، وليس دليلًا على التسليم. اختبر الالتقاط دون اتصال وإعادة تشغيل التطبيق. ثم اعثر على الحدث المحفوظ في المشروع.

اقرأ حالة التسليم

تعيد client.deliveryHealth() حالة الطابور والتسليم دون محتوى الأحداث. اقرأ هذه الحقول أولًا:

اختر محتوى السجل

اجعل كل رسالة قصيرة ومحددة. صِف نتيجة التطبيق، مثل طلب فاشل أو إعادة محاولة مجدولة. لا تضمّن الأسماء أو عناوين البريد الإلكتروني أو رموز الوصول المميزة أو قيم النماذج أو نصوص الطلبات. استخدم مستوى الخطورة الذي يطابق الحدث: info أو warning أو error أو critical. أبقِ الخدمة والبيئة والإصدار متسقة حتى تستطيع العثور على القيود المرتبطة. يعرض npx react-native log-ios وnpx react-native log-android سجلات الجهاز المحلية. ولا يستعلمان من LogBrew. راجع تصحيح الشيفرة الأصلية في React Native.

تعافَ من فحص فاشل

يُرفض flush() الفاشل مع رمز خطأ من الـ SDK. أبقِ المفاتيح ونصوص الأحداث خارج تقارير الأخطاء. راجع استكشاف الأخطاء وإصلاحها لمزيد من الفحوص.

احتفظ بمعرّفات Debug ID من Expo في حزم الإصدار

أنشئ إعدادات Metro الخاصة بـ Expo عبر LogBrew. عندها تحصل حزمة وقت التشغيل على Debug ID نفسه الموجود في خريطة المصدر (Source map) الخاصة بها:
إذا كان التطبيق يستخدم وضع الحزم في React Native Worklets، فطبّق ذلك التحويل بعد الدالة المساعدة من LogBrew:
تحتفظ الدالة المساعدة بإضافات Expo الموجودة التي تعمل قبل التسلسل (pre-serialization). أما تطبيق React Native المجرد، فيغلّف إعدادات Metro النهائية باستخدام withLogBrewMetroConfig() بدلًا من ذلك. لا تستخدم هذا الغلاف مع Expo. إذا استخدمته، فسيتوقف بناء الإنتاج برسالة تشير إلى getLogBrewExpoConfig().