Remote Logging — چیست، ابزارهای جمع‌آوری و روش‌های تحلیل از راه دور لاگ‌ها

Remote Logging چیست

Remote Logging فرآیند جمع‌آوری لاگ‌ها از دستگاه‌های راه دور و ارسال آنها به سرور مرکزی برای تحلیل است. در زمینه توسعه موبایل، remote logging نه تنها گزارش‌های کرش (crash reporting) بلکه رویدادهای سفارشی، breadcrumbs، معیارهای عملکرد و سناریوهای کاربری را نیز شامل می‌شود.

تفاوت اصلی remote logging با crash reporting در پیش‌فعالی بودن آن است. Crash reporting فقط داده‌های مربوط به کرش‌های رخ‌داده را جمع‌آوری می‌کند. Remote logging توالی رویدادهای قبل از کرش را جمع‌آوری می‌کند: کاربر چه صفحه‌هایی را باز کرده، چه درخواست‌هایی ارسال کرده، چه داده‌هایی وارد کرده است. این امکان بازتولید سناریوی خطا را بدون نیاز به ارتباط با کاربر فراهم می‌کند.

Apple یک مکانیزم داخلی برای جمع‌آوری از راه دور لاگ‌ها از طریق .logarchive ارائه می‌دهد، اما برای برنامه‌های تولیدی تقریباً همیشه از سرویس‌های شخص ثالث استفاده می‌شود. Android SDK شامل Logcat است که از طریق ADB از راه دور قابل دسترسی است، اما برای دستگاه‌های کاربران نهایی بدون حالت اشکال‌زدایی نیست.

معماری جمع‌آوری از راه دور لاگ‌ها

معماری remote logging از سه مؤلفه تشکیل شده است: SDK سمت کلient روی دستگاه که لاگ‌ها را جمع‌آوری و بافر می‌کند، پروتکل انتقال برای ارسال داده‌ها و سرور برای ذخیره و نمایش.

SDK سمت کلient لاگ‌ها را در حافظه رم بافر می‌کند و به صورت دوره‌ای آنها را به صورت دسته‌ای (batches) به سرور ارسال می‌کند. اگر دستگاه آفلاین باشد، لاگ‌ها در فایل محلی ذخیره می‌شوند و در اتصال بعدی به شبکه ارسال می‌گردند. اندازه بافر و فاصله ارسال قابل تنظیم است: مقادیر معمول 50 رویداد یا 30 ثانیه است.

پروتکل‌های انتقال

HTTPS REST — رایج‌ترین پروتکل برای remote logging. SDK لاگ‌ها را به JSON سریالایز کرده و با درخواست‌های POST به endpoint سرور ارسال می‌کند. gRPC — جایگزینی با سریالایز باینری (Protocol Buffers) که 30–40% فشرده‌تر از JSON و روی دستگاه‌های موبایل با اتصال ناپایدار سریع‌تر است. WebSocket برای لاگ‌گیری بلادرنگ در اشکال‌زدایی استفاده می‌شود اما به دلیل مصرف انرژی به ندرت در تولید استفاده می‌شود.

Firebase Crashlytics: جمع‌آوری کرش‌ها و لاگ‌ها

Firebase Crashlytics — سرویس رایگان Google برای جمع‌آوری گزارش‌های کرش و لاگ‌های سفارشی است. این سرویس در Firebase SDK تعبیه شده و نیازی به سرور جداگانه ندارد. Crashlytics به طور خودکار stack trace، وضعیت دستگاه، نسخه سیستم عامل و صفحه‌های باز در لحظه کرش را جمع‌آوری می‌کند.

لاگ‌های سفارشی در 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 در رابط کاربری بدون نیاز به بازسازی آنها از لاگ کرش قابل مشاهده هستند.

Breadcrumbs خودکار در Sentry

SDK Sentry به طور خودکار breadcrumbs را برای رویدادهای سیستمی جمع‌آوری می‌کند: تغییرات چرخه حیات UIViewController (viewDidLoad, viewWillAppear)، touches، کلیک روی دکمه‌ها، درخواست‌های HTTP از طریق URLSession. همه این رویدادها در تایملاین خطا همراه با breadcrumbs سفارشی نمایش داده می‌شوند. برای Android نیز به طور مشابه lifecycle Activity و Fragment، رویدادهای onClick و درخواست‌های شبکه از طریق OkHttp جمع‌آوری می‌شوند.

SDK Sentry برای iOS و Android به طور خودکار breadcrumbs رویدادهای UI را جمع‌آوری می‌کند: touches، ناوبری، lifecycle. توسعه‌دهنده می‌تواند breadcrumbs سفارشی را از طریق addBreadcrumb() با تعیین نوع، دسته و سطح اضافه کند. Sentry از distributed tracing پشتیبانی می‌کند: لاگر breadcrumbs را در کلient با درخواست‌های backend از طریق 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 به خودی خود نمی‌تواند لاگ‌ها را به سرور ارسال کند. نقش آن تشخیص محلی است. اما wrapperهایی مانند Timber و LogcatLive وجود دارند که پیام‌ها را به Firebase یا Sentry ارسال می‌کنند و API آشنا Log.d / Log.e را حفظ می‌کنند. Timber امکان تغییر handlerها را بدون تغییر کد برنامه فراهم می‌کند — درخت debug به Logcat می‌نویسد، درخت release با بچینگ و فشرده‌سازی به سرور ارسال می‌کند.

بچینگ و بهینه‌سازی ترافیک

بچینگ — گروه‌بندی چندین لاگ در یک درخواست 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 لاگ‌ها. SDKهای Sentry و Crashlytics به طور خودکار بدنه درخواست را قبل از ارسال فشرده می‌کنند. حذف تکراری — حذف پیام‌های تکراری در سمت کلient: اگر یک رویداد 100 بار در ثانیه ثبت شود، SDK آن را یک بار با فیلد count = 100 ارسال می‌کند.

اشتباهات رایج لاگ‌گیری از راه دور

رایج‌ترین اشتباه — لاگ‌گیری داده‌های حساس. Remote logging SDK داده‌ها را به سرور ارسال می‌کند و اگر توسعه‌دهنده تصادفاً رمز عبور، توکن یا ایمیل کاربر را لاگ کند، این داده‌ها در زیرساخت ابری قرار می‌گیرند. همیشه از فیلتراسیون PII (اطلاعات قابل شناسایی شخصی) در سطح SDK استفاده کنید: Sentry یک هوک beforeSend داخلی برای پاکسازی داده‌ها قبل از ارسال دارد.

دومین مشکل رایج — لاگ‌گیری بیش از حد. اگر هر حرکت انگشت به سرور ارسال شود، حجم داده به صورت نمایی رشد می‌کند و هزینه‌های سرور نیز افزایش می‌یابد. یک بودجه برای لاگ‌ها تعیین کنید: در تولید بیش از 1–5 رویداد به ازای هر کاربر در دقیقه نباشد. لاگ‌های اشکال‌زدایی را فقط با پرچمی ارسال کنید که برای دستگاه‌های خاص فعال می‌شود.

سومین اشتباه — نادیده گرفتن سناریوی آفلاین. اگر SDK در غیاب شبکه لاگ‌ها را از دست بدهد و در اتصال مجدد آنها را بازیابی نکند، remote logging برای کاربران با اتصال ناپایدار بی‌فایده است. همه SDKها (Firebase, Sentry) به طور خودکار لاگ‌ها را در فایل محلی کش می‌کنند و هنگام ظهور شبکه ارسال می‌کنند، اما این تنظیمات باید بررسی شود.