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) کے ساتھ ایک متبادل ہے، جو JSON سے 30–40% زیادہ کمپیکٹ ہے اور غیر مستحکم کنکشن والے موبائل ڈیوائسز پر تیز تر ہے۔ WebSocket ڈیبگنگ میں ریئل ٹائم لاگنگ کے لیے استعمال ہوتا ہے لیکن بجلی کی کھپت کی وجہ سے پروڈکشن میں شاذ و نادر ہی استعمال ہوتا ہے۔

Firebase Crashlytics: کریش اور لاگ جمع کرنا

Firebase Crashlytics کریش رپورٹس اور کسٹم لاگ جمع کرنے کے لیے Google کی مفت سروس ہے۔ یہ Firebase SDK میں شامل ہے اور اسے علیحدہ سرور کی ضرورت نہیں ہے۔ Crashlytics خود بخود کریش کے وقت اسٹیک ٹریس، ڈیوائس کی حالت، OS ورژن اور کھلی اسکرینیں جمع کرتا ہے۔

Crashlytics میں کسٹم لاگ log() طریقہ کے ذریعے شامل کیے جاتے ہیں — یہ فوری طور پر سرور پر نہیں بھیجے جاتے بلکہ رنگ بفر میں محفوظ ہوتے ہیں اور اگلی کریش رپورٹ کے ساتھ منسلک ہو جاتے ہیں۔ یہ Sentry سے بنیادی فرق ہے، جہاں ہر لاگ ایک علیحدہ واقعہ ہے۔ Crashlytics میں کسٹم لاگ کا زیادہ سے زیادہ حجم 64 KB فی کریش ہے۔

// 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 انٹرفیس میں کریش لاگ سے دوبارہ تعمیر کیے بغیر نظر آتے ہیں۔

Sentry میں خودکار breadcrumbs

Sentry SDK خود بخود سسٹم ایونٹس کے لیے breadcrumbs جمع کرتا ہے: UIViewController لائف سائیکل تبدیلیاں (viewDidLoad, viewWillAppear)، ٹچز، بٹن دباؤ، URLSession کے ذریعے HTTP درخواستیں۔ یہ تمام واقعات کسٹم breadcrumbs کے ساتھ غلطی کی ٹائم لائن میں ظاہر ہوتے ہیں۔ Android کے لیے، Activity اور Fragment لائف سائیکل، onClick ایونٹس اور OkHttp کے ذریعے نیٹ ورک کی درخواستیں اسی طرح جمع کی جاتی ہیں۔

iOS اور Android کے لیے Sentry SDK خود بخود UI ایونٹس (ٹچز، نیویگیشن، لائف سائیکل) کے breadcrumbs جمع کرتا ہے۔ ڈیولپرز قسم، زمرہ اور سطح بتا کر addBreadcrumb() کے ذریعے کسٹم breadcrumbs شامل کر سکتے ہیں۔ Sentry distributed tracing کو سپورٹ کرتا ہے: لاگر کلائنٹ سائڈ breadcrumbs کو ٹریس 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 تک ریموٹ رسائی USB یا Wi-Fi پر ADB کے ذریعے کام کرتی ہے، لیکن صرف ڈیبگ موڈ میں ڈیوائسز کے لیے — USB کنکشن کے بغیر ڈیوائسز پر پروڈکشن ایپلیکیشنز قابل رسائی نہیں ہیں۔

Android پر پروڈکشن میں ریموٹ لاگنگ کے لیے متبادل استعمال کیے جاتے ہیں: Logcat خود سرور پر لاگ بھیج نہیں سکتا۔ اس کا کردار مقامی تشخیص ہے۔ تاہم، ریپرز (Timber, LogcatLive) موجود ہیں جو واقف Log.d / Log.e API کو برقرار رکھتے ہوئے پیغامات کو Firebase یا Sentry پر فارورڈ کرتے ہیں۔ Timber ایپلیکیشن کوڈ تبدیل کیے بغیر ہینڈلرز کو تبدیل کرنے کی اجازت دیتا ہے — ایک ڈیبگ ٹری Logcat میں لکھتا ہے، ایک ریلیز ٹری بیچنگ اور کمپریشن کے ساتھ سرور پر بھیجتا ہے۔

بیچنگ اور ٹریفک کی اصلاح

بیچنگ (Batching) ٹریفک اور بیٹری بچانے کے لیے متعدد لاگ کو ایک HTTP درخواست میں گروپ کرنا ہے۔ 50 انفرادی POST درخواستوں کے بجائے، SDK ایک JSON صف بھیجتا ہے۔ عام حکمت عملیاں: شیڈول کے مطابق بھیجنا (ہر 30 سیکنڈ)، تعداد کے مطابق (ہر 50 واقعہ)، یا واقعہ کے مطابق (صرف سنگین غلطیوں پر)۔

لاکھوں صارفین والی ایپلیکیشنز کے لیے، لاگ کا حجم روزانہ ٹیرابائٹس تک پہنچ سکتا ہے۔ بیچنگ درخواستوں کی تعداد کو 10–50 گنا کم کرتی ہے اور سرور کے بوجھ کو کم کرتی ہے۔ Sentry ٹرانسپورٹ کی سطح پر gzip کمپریشن استعمال کرتا ہے، جو ڈیٹا کے حجم کو مزید 60–70% تک کم کرتا ہے۔

// 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 منتقلی کے لیے معیاری کمپریشن طریقہ ہے۔ Sentry اور Crashlytics SDK بھیجنے سے پہلے خود بخود درخواست کے باڈی کو کمپریس کرتے ہیں۔ ڈیڈپلیکیشن — کلائنٹ سائڈ پر ڈپلیکیٹ پیغامات کو ہٹانا: اگر ایک ہی واقعہ فی سیکنڈ 100 بار ہوتا ہے، تو SDK اسے count = 100 فیلڈ کے ساتھ ایک بار بھیجتا ہے۔

ریموٹ لاگنگ کی عام غلطیاں

سب سے عام غلطی حساس ڈیٹا کو لاگ کرنا ہے۔ Remote logging SDK سرور پر ڈیٹا منتقل کرتے ہیں، اور اگر کوئی ڈیولپر غلطی سے پاس ورڈ، ٹوکن یا صارف کا ای میل لاگ کر لیتا ہے، تو یہ ڈیٹا کلاؤڈ انفراسٹرکچر میں چلا جاتا ہے۔ ہمیشہ SDK کی سطح پر PII (ذاتی شناخت کی معلومات) فلٹرنگ استعمال کریں: Sentry میں بھیجنے سے پہلے ڈیٹا صاف کرنے کے لیے بلٹ ان beforeSend ہک ہے۔

دوسرا عام مسئلہ ضرورت سے زیادہ لاگنگ ہے۔ اگر ہر انگلی کی حرکت سرور پر بھیجی جائے تو ڈیٹا کا حجم تیزی سے بڑھتا ہے اور سرور کے اخراجات بھی۔ لاگنگ کا بجٹ طے کریں: پروڈکشن میں فی صارف فی منٹ 1–5 واقعات سے زیادہ نہیں۔ ڈیبگ لاگ صرف اس جھنڈی کے ساتھ بھیجیں جو مخصوص ڈیوائسز کے لیے فعال ہو۔

تیسری غلطی آف لائن منظرنامے کو نظر انداز کرنا ہے۔ اگر SDK نیٹ ورک نہ ہونے پر لاگ کھو دیتا ہے اور دوبارہ کنیکٹ ہونے پر انہیں بحال نہیں کرتا، تو remote logging غیر مستحکم کنکشن والے صارفین کے لیے بیکار ہے۔ تمام SDK (Firebase, Sentry) خود بخود لاگ کو مقامی فائل میں کیش کرتے ہیں اور نیٹ ورک دستیاب ہونے پر بھیجتے ہیں، لیکن اس ترتیب کو چیک کرنا ضروری ہے۔