Remote Logging — bu nədir, toplama alətləri və uzaqdan loq analizi üsulları

Remote Logging nədir

Remote Logging — uzaq cihazlardan loqların toplanması və analiz üçün mərkəzi serverə ötürülməsi prosesidir. Mobil inkişaf kontekstində remote logging təkcə qəza reportlarını (crash reporting) deyil, həm də xüsusi hadisələri, breadcrumbs, performans metrikalarını və istifadəçi ssenarilərini əhatə edir.

Remote logging-in crash reporting-dən əsas fərqi proaktivlikdir. Crash reporting yalnız artıq baş vermiş tətbiq qəzaları haqqında məlumat toplayır. Remote logging qəzadan əvvəlki hadisələr ardıcıllığını toplayır: istifadəçinin hansı ekranları açdığını, hansı sorğuları göndərdiyini, hansı məlumatları daxil etdiyini. Bu, istifadəçi ilə əlaqə saxlamadan səhv ssenarisini bərpa etməyə imkan verir.

Apple .logarchive vasitəsilə uzaqdan loq toplama üçün daxili mexanizm təqdim edir, lakin istehsalat tətbiqləri üçün demək olar ki, həmişə üçüncü tərəf xidmətlərindən istifadə olunur. Android SDK ADB vasitəsilə uzaqdan əlçatan olan Logcat-i ehtiva edir, lakin sazlama rejimi olmayan son istifadəçi cihazları üçün deyil.

Uzaqdan loq toplama arxitekturası

Remote logging arxitekturası üç komponentdən ibarətdir: loqları toplayan və buferləşdirən cihazdakı klient SDK, məlumat göndərmək üçün nəqliyyat protokolu və saxlama və vizuallaşdırma üçün server.

Klient SDK loqları operativ yaddaşda buferləşdirir və dövri olaraq onları partiyalar (batches) şəklində serverə göndərir. Cihaz oflayndırsa, loqlar lokal faylda saxlanılır və növbəti şəbəkə qoşulmasında göndərilir. Bufer ölçüsü və göndərmə intervalı konfiqurasiya edilə bilər: tipik dəyərlər 50 hadisə və ya 30 saniyədir.

Nəqliyyat protokolları

HTTPS REST — remote logging üçün ən geniş yayılmış protokol. SDK loqları JSON-a serializasiya edir və serverin endpoint-inə POST sorğuları ilə göndərir. gRPC — ikili serializasiya (Protocol Buffers) ilə alternativdir, JSON-dan 30–40% daha yığcamdır və qeyri-sabit əlaqəsi olan mobil cihazlarda daha sürətlidir. WebSocket sazlama zamanı real-vaxt loqlaması üçün istifadə olunur, lakin enerji istehlakı səbəbindən istehsalatda nadir hallarda tətbiq edilir.

Firebase Crashlytics: qəza və loqların toplanması

Firebase Crashlytics — qəza reportları və xüsusi loqların toplanması üçün Google-ın pulsuz xidmətidir. Firebase SDK-ya daxildir və ayrıca server tələb etmir. Crashlytics avtomatik olaraq stack trace, cihaz vəziyyəti, əməliyyat sistemi versiyası və qəza anında açıq olan ekranları toplayır.

Crashlytics-də xüsusi loqlar log() metodu ilə əlavə edilir — onlar dərhal serverə göndərilmir, halqa buferində saxlanılır və növbəti qəza reportuna əlavə olunur. Bu, hər loqun ayrıca hadisə olduğu Sentry-dən əsas fərqdir. Crashlytics-də xüsusi loqların maksimum həcmi bir qəza üçün 64 KB-dır.

// Firebase Crashlytics — Android-də xüsusi loqlar
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 qəzaları konkret istifadəçilərlə əlaqələndirmək üçün setUserIdentifier-i dəstəkləyir. Bu, səhvin kütləvi olub-olmadığını və ya yalnız bir istifadəçiyə təsir etdiyini müəyyən etməyə kömək edir. setCustomKey hər reporta ixtiyari açarlar əlavə edir — A/B test versiyası, region, tarif planı.

Sentry: breadcrumbs və istifadəçi konteksti

Sentry — təkcə qəza reportlarını deyil, həm də bütün xüsusi hadisələri (breadcrumbs) müstəqil qeydlər kimi saxlayan səhv monitorinq platformasıdır. Crashlytics-dən fərqli olaraq, Sentry səhvə qədər olan hadisələr ardıcıllığına xronoloji sırada baxmağa imkan verir — breadcrumbs interfeysdə görünür və onları qəza loqundan bərpa etmək tələb olunmur.

Sentry-də avtomatik breadcrumbs

Sentry SDK sistem hadisələri üçün avtomatik breadcrumbs toplayır: UIViewController həyat dövrü dəyişiklikləri (viewDidLoad, viewWillAppear), touches, düymə klikləri, URLSession vasitəsilə HTTP sorğuları. Bütün bu hadisələr xüsusi breadcrumbs ilə birlikdə səhv zaman xəttində göstərilir. Android üçün eyni şəkildə Activity və Fragment lifecycle, onClick hadisələri və OkHttp vasitəsilə şəbəkə sorğuları toplanır.

iOS və Android üçün Sentry SDK UI hadisələrinin breadcrumbs-nı avtomatik toplayır: touches, naviqasiya, lifecycle. Tərtibatçı addBreadcrumb() vasitəsilə növü, kateqoriyası və səviyyəsi göstərilməklə xüsusi breadcrumbs əlavə edə bilər. Sentry distributed tracing-i dəstəkləyir: logger breadcrumbs-ı klientdə trace ID vasitəsilə backend sorğuları ilə əlaqələndirir.

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 və ADB vasitəsilə uzaqdan giriş

Logcat — Android Debug Bridge (ADB) vasitəsilə əlçatan olan standart Android loqlama sistemidir. Logcat səviyyələr (V, D, I, W, E, F) və teqlər üzrə bölünmüş bütün sistem və tətbiq mesajlarını toplayır. Logcat-a uzaqdan giriş ADB vasitəsilə USB və ya Wi-Fi üzərindən işləyir, lakin yalnız sazlama rejimində olan cihazlar üçün — USB qoşulması olmayan cihazlarda istehsalat tətbiqləri əlçatan deyil.

Android-də istehsalatda uzaqdan loqlama üçün alternativlərdən istifadə olunur: Logcat özlüyündə loqları serverə göndərə bilmir. Onun rolu lokal diaqnostikadır. Lakin Timber, LogcatLive kimi qablaşdırmalar mövcuddur ki, onlar mesajları Firebase və ya Sentry-ə yönləndirir, tanış Log.d / Log.e API-ni qoruyur. Timber tətbiq kodunu dəyişmədən handler-ləri dəyişməyə imkan verir — debug ağacı Logcat-ə yazır, release ağacı batçinq və sıxılma ilə serverə göndərir.

Batçinq və trafik optimallaşdırması

Batçinq — trafikə və batareyaya qənaət etmək üçün bir neçə loqun bir HTTP sorğusunda qruplaşdırılmasıdır. 50 ayrıca POST sorğusu yerinə, SDK bir JSON massivi göndərir. Tipik strategiyalar: cədvəl üzrə göndərmə (hər 30 saniyədən bir), say üzrə (hər 50 hadisədən bir) və ya hadisə üzrə (yalnız kritik səhv olduqda).

Milyonlarla istifadəçisi olan tətbiqlər üçün loqların həcmi gündə terabaytlara çata bilər. Batçinq sorğuların sayını 10–50 dəfə azaldır və server yükünü aşağı salır. Sentry nəqliyyat səviyyəsində gzip sıxılmasından istifadə edir ki, bu da məlumat həcmini əlavə olaraq 60–70% azaldır.

// Android-də batçinqin sadə tətbiqi
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)
    }
}

Sıxılma və deduplikasiya

gzip — loqların HTTP ötürülməsi üçün standart sıxılma metodudur. Sentry və Crashlytics SDK-ları göndərmədən əvvəl sorğu gövdəsini avtomatik sıxır. Deduplikasiya — klient tərəfində təkrarlanan mesajların silinməsi: eyni hadisə saniyədə 100 dəfə tutulursa, SDK onu count = 100 sahəsi ilə bir dəfə göndərir.

Uzaqdan loqlamanın tipik səhvləri

Ən çox rast gəlinən səhv — həssas məlumatların loqlanmasıdır. Remote logging SDK məlumatları serverə ötürür və əgər tərtibatçı təsadüfən istifadəçinin parolunu, tokenini və ya email-ini loqlayırsa, bu məlumatlar bulud infrastrukturuna düşür. Həmişə SDK səviyyəsində PII (Şəxsiyyəti Müəyyən Edən Məlumat) filtrasiyasından istifadə edin: Sentry-də göndərmədən əvvəl məlumatları təmizləmək üçün daxili beforeSend-hook var.

İkinci geniş yayılmış problem — həddindən artıq loqlamadır. Əgər barmağın hər hərəkəti serverə göndərilirsə, məlumat həcmi eksponensial olaraq artır, server xərcləri də artır. Loqlar üçün büdcə müəyyən edin: istehsalatda istifadəçi başına dəqiqədə 1–5 hadisədən çox olmamalıdır. Debug loqlarını yalnız konkret cihazlar üçün yandırılan flag ilə göndərin.

Üçüncü səhv — oflayn ssenarinin nəzərə alınmamasıdır. Şəbəkə olmadıqda SDK loqları itirir və yenidən qoşulduqda onları bərpa etmirsə, remote logging qeyri-sabit əlaqəsi olan istifadəçilər üçün faydasızdır. Bütün SDK-lar (Firebase, Sentry) loqları avtomatik olaraq lokal faylda keşləyir və şəbəkə yarandıqda göndərir, lakin bu parametr yoxlanılmalıdır.