Remote Logging — ما هو، أدوات التجميع وطرق التحليل عن بُعد للسجلات

ما هو Remote Logging

Remote Logging هو عملية جمع السجلات من الأجهزة عن بُعد وإرسالها إلى خادم مركزي للتحليل. في سياق التطوير المحمول، يشمل remote logging ليس فقط تقارير الأعطال ولكن أيضًا الأحداث المخصصة وbreadcrumbs ومقاييس الأداء وسيناريوهات المستخدم.

الفرق الرئيسي بين remote logging وcrash reporting هو الاستباقية. Crash reporting يجمع فقط بيانات عن أعطال التطبيق التي حدثت بالفعل. Remote logging يجمع تسلسل الأحداث قبل العطل: أي الشاشات فتحها المستخدم، وما هي الطلبات التي أرسلها، وما هي البيانات التي أدخلها. هذا يتيح إعادة إنتاج سيناريو الخطأ دون التواصل مع المستخدم.

Apple توفر آلية مدمجة للتجميع عن بُعد للسجلات عبر .logarchive، ولكن لتطبيقات الإنتاج تُستخدم دائمًا خدمات الطرف الثالث. يتضمن Android SDK Logcat، والذي يمكن الوصول إليه عن بُعد عبر ADB، ولكن ليس لأجهزة المستخدمين النهائيين دون وضع التصحيح.

هندسة التجميع عن بُعد للسجلات

تتكون هندسة remote logging من ثلاثة مكونات: SDK العميل على الجهاز الذي يجمع السجلات ويخزنها مؤقتًا، بروتوكول النقل لإرسال البيانات، والخادم للتخزين والعرض.

يقوم SDK العميل بتخزين السجلات مؤقتًا في RAM ويُفرغها بشكل دوري إلى الخادم على دفعات. إذا كان الجهاز غير متصل، تُحفظ السجلات في ملف محلي وتُرسل عند الاتصال التالي بالشبكة. حجم المخزن المؤقت وفاصل الإرسال قابلان للتكوين: القيم النموذجية هي 50 حدثًا أو 30 ثانية.

بروتوكولات النقل

HTTPS REST هو البروتوكول الأكثر شيوعًا لـ remote logging. يقوم SDK بتسلسل السجلات إلى JSON وإرسالها عبر طلبات POST إلى نقطة نهاية الخادم. gRPC هو بديل بالتسلسل الثنائي (Protocol Buffers)، وهو أكثر إحكامًا بنسبة 30–40% من JSON وأسرع على الأجهزة المحمولة ذات الاتصالات غير المستقرة. WebSocket يُستخدم للتسجيل في الوقت الفعلي أثناء التصحيح ولكن نادرًا في الإنتاج بسبب استهلاك الطاقة.

Firebase Crashlytics: جمع الأعطال والسجلات

Firebase Crashlytics هو خدمة مجانية من Google لجمع تقارير الأعطال والسجلات المخصصة. إنه مدمج في Firebase SDK ولا يتطلب خادمًا منفصلاً. يقوم Crashlytics تلقائيًا بجمع stack traces وحالة الجهاز وإصدار نظام التشغيل والشاشات المفتوحة وقت العطل.

تُضاف السجلات المخصصة في Crashlytics عبر طريقة log() — لا تُرسل إلى الخادم فورًا بل تُخزن في مخزن مؤقت دائري وتُرفق بتقرير العطل التالي. هذا هو الفرق الرئيسي عن Sentry، حيث كل سجل هو حدث منفصل. الحد الأقصى لحجم السجلات المخصصة في Crashlytics هو 64 كيلوبايت لكل عطل.

// Firebase Crashlytics — سجلات مخصصة على Android
import com.google.firebase.crashlytics.FirebaseCrashlytics

class CheckoutViewModel {
    fun processPayment(amount: Double) {
        FirebaseCrashlytics.getInstance()
            .log("Payment started: amount=$amount")
        try {
            process(amount)
        } catch (e: Exception) {
            FirebaseCrashlytics.getInstance()
                .recordException(e)
        }
    }
}

Firebase Crashlytics يدعم setUserIdentifier لربط الأعطال بمستخدمين محددين. هذا يساعد في تحديد ما إذا كان الخطأ جماعيًا أم يؤثر على مستخدم واحد فقط. setCustomKey يُضيف مفاتيح مخصصة لكل تقرير — إصدار اختبار A/B، المنطقة، الخطة التعريفية.

Sentry: breadcrumbs وسياق المستخدم

Sentry هي منصة لمراقبة الأخطاء تخزن ليس فقط تقارير الأعطال ولكن أيضًا جميع الأحداث المخصصة (breadcrumbs) كسجلات مستقلة. على عكس Crashlytics، يسمح Sentry بعرض تسلسل الأحداث قبل الخطأ بترتيب زمني — breadcrumbs مرئية في الواجهة دون الحاجة إلى إعادة بنائها من سجل العطل.

Breadcrumbs التلقائية في Sentry

يقوم SDK الخاص بـ Sentry تلقائيًا بجمع breadcrumbs للأحداث النظامية: تغييرات دورة حياة UIViewController (viewDidLoad, viewWillAppear)، اللمسات، الضغط على الأزرار، طلبات HTTP عبر URLSession. تظهر كل هذه الأحداث في الجدول الزمني للخطأ إلى جانب breadcrumbs المخصصة. لنظام Android، يتم جمع دورة حياة Activity وFragment وأحداث onClick وطلبات الشبكة عبر OkHttp بالمثل.

يقوم SDK الخاص بـ Sentry لنظامي iOS وAndroid تلقائيًا بجمع breadcrumbs لأحداث واجهة المستخدم: اللمسات، التنقل، دورة الحياة. يمكن للمطورين إضافة breadcrumbs مخصصة عبر addBreadcrumb() مع تحديد النوع والفئة والمستوى. يدعم Sentry التتبع الموزع: يقوم المسجل بربط breadcrumbs من جانب العميل مع طلبات الخلفية عبر معرف تتبع (trace ID).

import Sentry

func trackCartEvent(action: String, itemId: String) {
    let crumb = Breadcrumb()
    crumb.level = .info
    crumb.category = "cart"
    crumb.message = "Cart \(action): \(itemId)"
    crumb.data = ["action": action, "item_id": itemId]
    SentrySDK.addBreadcrumb(crumb)
}

Logcat والوصول عن بُعد عبر ADB

Logcat هو نظام التسجيل القياسي لنظام Android، يمكن الوصول إليه عبر Android Debug Bridge (ADB). يقوم Logcat بجمع جميع رسائل النظام والتطبيقات، مصنفة حسب المستويات (V, D, I, W, E, F) والوسوم. يعمل الوصول عن بُعد إلى Logcat عبر ADB عبر USB أو Wi-Fi، ولكن فقط للأجهزة في وضع التصحيح — تطبيقات الإنتاج على الأجهزة بدون اتصال USB غير قابلة للوصول.

للتسجيل عن بُعد في الإنتاج على Android، تُستخدم بدائل: Logcat بحد ذاته لا يمكنه إرسال السجلات إلى خادم. دوره هو التشخيص المحلي. ولكن توجد أغلفة (Timber, LogcatLive) تقوم بتوجيه الرسائل إلى Firebase أو Sentry مع الحفاظ على API المعتادة Log.d / Log.e. يسمح Timber بتبديل المعالجات دون تغيير كود التطبيق — شجرة التصحيح تكتب في Logcat، وشجرة الإصدار ترسل إلى الخادم مع التجميع والضغط.

التجميع (Batching) وتحسين حركة المرور

التجميع (Batching) هو تجميع سجلات متعددة في طلب HTTP واحد لتوفير حركة المرور والبطارية. بدلاً من 50 طلب POST فردي، يرسل SDK مصفوفة JSON واحدة. الاستراتيجيات النموذجية: الإرسال وفقًا لجدول (كل 30 ثانية)، حسب العدد (كل 50 حدثًا)، أو حسب الحدث (فقط عند الأخطاء الحرجة).

للتطبيقات التي تضم ملايين المستخدمين، يمكن أن يصل حجم السجلات إلى تيرابايت يوميًا. يقلل التجميع من عدد الطلبات بمقدار 10–50 مرة ويقلل من حمل الخادم. Sentry يستخدم ضغط gzip على مستوى النقل، مما يقلل حجم البيانات بشكل إضافي بنسبة 60–70%.

// تنفيذ بسيط للتجميع (batching) على Android
class LogBatcher {
    private val buffer = mutableListOf<LogEvent>()
    private val maxSize = 50
    private val intervalMs = 30_000L

    fun append(event: LogEvent) {
        buffer.add(event)
        if (buffer.size >= maxSize) flush()
    }

    suspend fun flush() {
        val batch = buffer.toList()
        buffer.clear()
        sendToServer(batch)
    }
}

الضغط وإزالة التكرار

gzip هو طريقة الضغط القياسية لنقل السجلات عبر HTTP. تقوم SDKs الخاصة بـ Sentry وCrashlytics بضغط جسم الطلب تلقائيًا قبل الإرسال. إزالة التكرار — إزالة الرسائل المكررة على جانب العميل: إذا حدث نفس الحدث 100 مرة في الثانية، يرسله SDK مرة واحدة مع حقل count = 100.

الأخطاء النموذجية للتسجيل عن بُعد

الخطأ الأكثر شيوعًا هو تسجيل البيانات الحساسة. تقوم SDKs الخاصة بـ remote logging بنقل البيانات إلى الخادم، وإذا قام المطور بتسجيل كلمة مرور أو رمز مميز أو بريد إلكتروني للمستخدم عن طريق الخطأ، فستظهر هذه البيانات في البنية التحتية السحابية. استخدم دائمًا تصفية PII (معلومات التعريف الشخصية) على مستوى SDK: لدى Sentry خطاف beforeSend مدمج لتنظيف البيانات قبل الإرسال.

المشكلة الثانية الشائعة هي التسجيل المفرط. إذا تم إرسال كل حركة إصبع إلى الخادم، ينمو حجم البيانات بشكل هائل، وكذلك تكاليف الخادم. حدد ميزانية للتسجيل: لا يزيد عن 1–5 أحداث لكل مستخدم في الدقيقة في الإنتاج. أرسل سجلات التصحيح فقط مع علامة يتم تفعيلها لأجهزة محددة.

الخطأ الثالث هو تجاهل سيناريو عدم الاتصال. إذا فقد SDK السجلات عند عدم وجود شبكة ولم يستعدها عند إعادة الاتصال، يصبح remote logging عديم الفائدة للمستخدمين ذوي الاتصالات غير المستقرة. جميع SDKs (Firebase, Sentry) تخزن السجلات تلقائيًا في ملف محلي وترسلها عند توفر الشبكة، ولكن يجب التحقق من هذا الإعداد.