التتبع: ما هو، مبادئه وجمع البيانات

ما هو التتبع في المراقبة

التتبع هو طريقة للمراقبة الموزعة حيث يتم تتبع كل طلب وارد عبر جميع الخدمات ومكونات النظام. على عكس المقاييس التي تظهر قيمًا مجمعة (متوسط وقت الاستجابة، عدد الأخطاء)، يحافظ التتبع على السياق الكامل لطلب محدد واحد.

يتم تسجيل كل خطوة معالجة — استدعاء قاعدة بيانات، طلب HTTP إلى خدمة مصغرة أخرى، تنفيذ مهمة خلفية — كوحدة منفصلة بطابع زمني وحالة وسمات. وفقًا لـ Google Dapper (المنشور الأصلي عام 2010)، يسمح التتبع بتحديد موقع التأخيرات في الأنظمة الموزعة بدقة تصل إلى استدعاء واحد.

التتبع مهم بشكل خاص لتطبيقات الهواتف المحمولة حيث يتكون الخادم الخلفي من عشرات الخدمات المصغرة. قد يمر إجراء المستخدم — مثل تسجيل الدخول إلى حساب — عبر بوابة API وخدمة المصادقة وقاعدة البيانات وخدمة الإشعارات. بدون التتبع، يكاد يكون من المستحيل تحديد أي مكون يبطئ الاستجابة.

Spans وtraces: هيكل البيانات الأساسي

الوحدة الأساسية للتتبع هي span. يمثل كل span عملية منطقية واحدة: طلب HTTP، استعلام SQL، استدعاء gRPC، تسلسل JSON. يحتوي span على معرف فريد، معرف أصل، اسم العملية، وقت البدء، المدة، الحالة ومجموعة من السمات.

التسلسل الهرمي لـ spans في trace

يتم تجميع جميع spans المتعلقة بطلب جذر واحد في trace. يمثل span الجذر نقطة الدخول — طلب HTTP من العميل المحمول إلى API. تشكل spans الفرعية شجرة، حيث يشير كل span إلى أصله عبر حقل parent_span_id.

مدة trace تساوي مجموع مدد المقاطع الزمنية الفريدة لجميع spans. إذا تم تنفيذ spanين فرعيين بالتوازي، فلا يتم جمع وقتهما — هذا أمر بالغ الأهمية لتحليل التأخيرات الناتجة عن استدعاءات الخدمات المصغرة المتوازية بشكل صحيح.

سمات وأحداث span

يمكن أن يحتوي كل span على سمات — أزواج مفتاح-قيمة مع معلومات وصفية: URL الطلب، معرف المستخدم، إصدار API، اسم المضيف. تُستخدم السمات لتصفية وتجميع التتبعات. بالإضافة إلى السمات، تدعم spans الأحداث — طوابع زمنية مع أوصاف نصية، مثل "خطأ في ذاكرة التخزين المؤقت" أو "إعادة محاولة الاتصال".

كيف يعمل التتبع الموزع

التتبع الموزع يحل مشكلة ربط spans التي يتم إنشاؤها في عمليات مختلفة وعلى أجهزة مختلفة. تعتمد الآلية على نقل السياق: عندما يستدعي الخدمة A الخدمة B، يتم إضافة رأس يحتوي على معرف trace الحالي ومعرف span الأصل إلى الطلب الصادر.

بروتوكولات نقل السياق القياسية هي W3C Trace Context (رؤوس traceparent وtracestate) وZipkin B3 (رؤوس X-B3-TraceId، X-B3-SpanId). تم اعتماد W3C Trace Context كمعيار من قبل اتحاد W3C في عام 2021 وهو مدعوم من قبل جميع مزودي القياسات عن بعد الرئيسيين.

عند استلام الطلب، يستخرج الخدمة B trace_id من الرأس وينشئ span فرعي بهذا trace_id. وهكذا، بعد اكتمال الطلب، يتم دمج جميع spans من الخدمات المختلفة في trace واحد في جانب المجمع. يتطلب ذلك أن تكون كل خدمة مجهزة بنفس مكتبة التتبع.

نقل السياق في الخدمات المصغرة

في تطوير التطبيقات المحمولة، يغطي نقل السياق ليس فقط الخادم الخلفي ولكن أيضًا التفاعل بين العميل والخادم. يمكن للتطبيق المحمول إرسال trace_id في رأس كل طلب API، مما يسمح بربط إجراء العميل بمعالجة الخادم. يدعم SDK OpenTelemetry لنظامي iOS وAndroid الإنشاء التلقائي ونقل سياق التتبع عبر عملاء HTTP.

import io.opentelemetry.api.trace.Span
import io.opentelemetry.api.trace.Tracer
import io.opentelemetry.context.Context

class TracingInterceptor : Interceptor {
    private val tracer: Tracer = OpenTelemetry.getTracer("mobile-app")

    override fun intercept(chain: Interceptor.Chain): Response {
        val span = tracer.spanBuilder("HTTP POST /api/login")
            .setParent(Context.current())
            .startSpan()

        return chain.proceed(chain.request())
            .also { span.end() }
    }
}

يقوم المعترض Kotlin المعروض بإنشاء span لكل طلب HTTP إلى الخادم. يتم نقل السياق الأصل من الكود المستدعي عبر Context.current()، مما يسمح بربط تتبع العميل بتتبع الخادم.

تنفيذ التتبع عبر OpenTelemetry

OpenTelemetry هو المعيار الفعلي لجمع بيانات التتبع. يوفر API موحدًا لتوليد spans، وأتمتة الأدوات للمكتبات الشائعة، وآلية مرنة لتصدير البيانات إلى أنظمة خلفية متنوعة: Jaeger، Zipkin، Grafana Tempo، Datadog، New Relic.

الأتمتة التلقائية

يدعم OpenTelemetry الإنشاء التلقائي لـ spans للأطر الشائعة: Spring Boot، Ktor، Flask، Express، gRPC. يحتاج المطور فقط إلى إضافة تبعية إلى المشروع، وتقوم المكتبة تلقائيًا باعتراض الطلبات الواردة والصادرة. تستخدم الأتمتة التلقائية لجافا javaagent الذي يعدل bytecode أثناء التشغيل دون تغيير الكود المصدري.

للمنصات المحمولة، يوفر OpenTelemetry Swift SDK وKotlin SDK. يقومان تلقائيًا بإنشاء spans لطلبات الشبكة (URLSession، OkHttp)، وعمليات قاعدة البيانات (CoreData، Room)، والمهام الخلفية. يمكن للمطور إضافة spans مخصصة لمنطق الأعمال.

تصدير البيانات

يتم إرسال spans المجمعة إلى مجمع عبر بروتوكول OTLP (OpenTelemetry Protocol). يمكن للمجمع تخزين وفلترة وإعادة توجيه البيانات إلى نظام تخزين واحد أو أكثر. وفقًا لوثائق OpenTelemetry، فإن زمن الانتقال النموذجي من توليد span إلى عرضه في لوحة المعلومات هو 2–5 ثوانٍ عند استخدام تصدير gRPC.

import OpenTelemetryApi
import OpenTelemetrySdk
import URLSessionInstrumentation

let instrumentation = URLSessionInstrumentation()
instrumentation.enable()

let tracer = OpenTelemetry.instance.tracerFactory
    .get("mobile-monitoring")

let span = tracer.spanBuilder("fetch-user-profile")
    .setAttribute(key: "user.id", value: userId)
    .startSpan()
span.end()

يقوم كود Swift بتفعيل الأتمتة التلقائية لطبقة الشبكة وإنشاء span مخصص لعملية استرداد ملف تعريف المستخدم. تسمح السمة user.id بتصفية التتبعات حسب مستخدم معين لاحقًا.

استراتيجيات أخذ عينات التتبعات

في الأنظمة عالية الحمل، من المستحيل تتبع كل طلب — فهذا يخلق حملًا غير مقبول على التخزين والشبكة. أخذ العينات يحل هذه المشكلة عن طريق حفظ جزء فقط من التتبعات. يؤثر اختيار الاستراتيجية بشكل مباشر على اكتمال البيانات وتكلفة البنية التحتية.

أخذ العينات من البداية (Head-based)

يتم اتخاذ قرار حفظ التتبع في لحظة إنشائه — في span الجذر. أبسط وأكثر الطرق شيوعًا: يتم حفظ نسبة مئوية ثابتة من الطلبات (مثل 5%)، ويتم تجاهل الباقي. العيب هو أنه لا يمكن ضمان التقاط الأخطاء النادرة. يدعم Probability sampler في OpenTelemetry إعداد الاحتمالية من 0.0 إلى 1.0.

أخذ العينات من النهاية (Tail-based)

يتم تأجيل القرار حتى اكتمال جميع spans التتبع. يقوم محلل بتقييم ما إذا كان التتبع يحتوي على أخطاء أو تجاوز وقت أو سمات مثيرة للاهتمام، وعندها فقط يتم حفظه. يتطلب هذا النهج تخزين جميع spans في المجمع، مما يزيد من استهلاك الذاكرة. وفقًا لـ Grafana Labs، فإن أخذ العينات من النهاية أكثر كفاءة بنسبة 40–60% من حيث "التكلفة لكل بيانات مفيدة" في الأنظمة ذات الأخطاء النادرة ولكن الحرجة.

الفرق بين التتبع والتسجيل

التسجيل يسجل أحداثًا فردية بمستويات الأهمية (info، warn، error) لكنه لا يربطها في سياق طلب واحد. التتبع، على العكس، ينشئ شجرة منظمة من العمليات التي تنتمي إلى طلب شامل واحد. في الممارسة العملية، هذان النهجان لا يتعارضان بل يكملان بعضهما البعض.

السجلات فعالة للتحليل التفصيلي لخطأ محدد: يرى المطور الرسالة الدقيقة وتتبع المكدس وقيم المتغيرات. يجيب التتبع على سؤال "لماذا يستغرق الطلب 5 ثوانٍ" — يُظهر أي خدمة مصغرة أو استدعاء استغرق أكبر قدر من الوقت. وفقًا لـ Honeycomb (2024)، تجد الفرق التي تستخدم التتبع مع التسجيل السبب الجذري للحوادث أسرع بمقدار 2.3 مرة.

النهج الحديث — المراقبة الشاملة — يجمع التتبع والمقاييس والسجلات في نظام واحد. يدعم OpenTelemetry الارتباط بين هذه الإشارات الثلاث: يمكن أن يحتوي كل span على روابط للسجلات ذات الصلة، ويمكن وضع علامات على المقاييس باستخدام trace_id للانتقال إلى تتبعات محددة.