ٹریسنگ: یہ کیا ہے، اصول اور ڈیٹا اکٹھا کرنا

مانیٹرنگ میں ٹریسنگ کیا ہے

ٹریسنگ تقسیم شدہ مشاہدے کا ایک طریقہ ہے جہاں ہر آنے والی درخواست کو نظام کی تمام خدمات اور اجزاء کے ذریعے ٹریک کیا جاتا ہے۔ میٹرکس کے برعکس، جو مجموعی قدریں دکھاتے ہیں (اوسط جوابی وقت، خرابیوں کی تعداد)، ٹریسنگ ایک مخصوص درخواست کا مکمل سیاق و سباق محفوظ رکھتا ہے۔

پروسیسنگ کا ہر مرحلہ — ڈیٹا بیس کال، کسی دوسری مائیکرو سروس کو HTTP درخواست، پس منظر کے کام کا نفاذ — ایک ٹائم اسٹیمپ، حالت اور خصوصیات کے ساتھ ایک علیحدہ اکائی کے طور پر ریکارڈ کیا جاتا ہے۔ Google Dapper (2010 کی اصل اشاعت) کے مطابق، ٹریسنگ تقسیم شدہ نظاموں میں ایک کال کی درستگی کے ساتھ تاخیر کا پتہ لگانے کی اجازت دیتا ہے۔

ٹریسنگ خاص طور پر موبائل ایپلی کیشنز کے لیے اہم ہے جہاں بیک اینڈ درجنوں مائیکرو سروسز پر مشتمل ہوتا ہے۔ ایک صارف کا عمل — جیسے اکاؤنٹ میں لاگ ان کرنا — API Gateway، تصدیقی سروس، ڈیٹا بیس اور Push سروس سے گزر سکتا ہے۔ ٹریسنگ کے بغیر، یہ تعین کرنا کہ کون سا جزو جواب کو سست کر رہا ہے تقریباً ناممکن ہے۔

Spans اور traces: بنیادی ڈیٹا ڈھانچہ

ٹریسنگ کی بنیادی اکائی span ہے۔ ہر span ایک منطقی آپریشن کی نمائندگی کرتا ہے: ایک HTTP درخواست، SQL سوال، gRPC کال، JSON سیریلائزیشن۔ ایک span میں ایک منفرد شناخت کنندہ، والدین شناخت کنندہ، آپریشن کا نام، شروع کا وقت، مدت، حالت اور خصوصیات کا ایک مجموعہ ہوتا ہے۔

ایک trace میں spans کا درجہ بندی

ایک ہی بنیادی درخواست سے متعلق تمام spans ایک trace میں گروپ ہوتے ہیں۔ بنیادی span داخلے کے مقام کی نمائندگی کرتا ہے — موبائل کلائنٹ سے API کو HTTP درخواست۔ ذیلی spans ایک درخت بناتے ہیں، جہاں ہر span parent_span_id فیلڈ کے ذریعے اپنے والدین کا حوالہ دیتا ہے۔

ایک trace کی مدت تمام spans کے منفرد وقتی حصوں کی مدت کے مجموعے کے برابر ہوتی ہے۔ اگر دو ذیلی spans متوازی طور پر انجام پاتے ہیں، تو ان کا وقت جمع نہیں کیا جاتا — یہ متوازی مائیکرو سروس کالوں کی وجہ سے ہونے والی تاخیر کے صحیح تجزیہ کے لیے اہم ہے۔

Span خصوصیات اور واقعات

ہر span میں خصوصیات ہو سکتی ہیں — میٹا معلومات کے ساتھ کلید-قدر جوڑے: درخواست کا URL، صارف ID، API ورژن، میزبان کا نام۔ خصوصیات کا استعمال traces کو فلٹر اور گروپ کرنے کے لیے کیا جاتا ہے۔ خصوصیات کے علاوہ، spans واقعات کو سپورٹ کرتے ہیں — ٹیکسٹ وضاحت کے ساتھ ٹائم اسٹیمپ، جیسے "کیش مس" یا "کنیکشن دوبارہ کوشش"۔

تقسیم شدہ ٹریسنگ کیسے کام کرتا ہے

تقسیم شدہ ٹریسنگ مختلف عملوں اور مختلف مشینوں پر بنائے گئے spans کو جوڑنے کا مسئلہ حل کرتا ہے۔ میکانزم سیاق و سباق کی منتقلی پر مبنی ہے: جب سروس A سروس B کو کال کرتی ہے، تو باہر جانے والی درخواست میں موجودہ trace ID اور والدین span ID پر مشتمل ایک ہیڈر شامل کیا جاتا ہے۔

معیاری سیاق و سباق کی منتقلی کے پروٹوکول W3C Trace Context (traceparent اور tracestate ہیڈر) اور Zipkin B3 (X-B3-TraceId، X-B3-SpanId ہیڈر) ہیں۔ W3C Trace Context کو 2021 میں W3C کنسورشیم نے بطور معیار اپنایا تھا اور تمام بڑے ٹیلی میٹری فراہم کنندگان اس کی حمایت کرتے ہیں۔

درخواست موصول ہونے پر، سروس B ہیڈر سے trace_id نکالتا ہے اور اس trace_id کے ساتھ ایک ذیلی span بناتا ہے۔ اس طرح، درخواست مکمل ہونے کے بعد، مختلف خدمات کے تمام spans کلیکٹر کی طرف ایک ہی trace میں یکجا ہو جاتے ہیں۔ اس کے لیے ضروری ہے کہ ہر سروس کو ایک ہی ٹریسنگ لائبریری سے تیار کیا گیا ہو۔

مائیکرو سروسز میں سیاق و سباق کی منتقلی

موبائل ڈویلپمنٹ میں، سیاق و سباق کی منتقلی نہ صرف بیک اینڈ بلکہ کلائنٹ-سرور تعامل کو بھی شامل کرتی ہے۔ ایک موبائل ایپلی کیشن ہر API درخواست کے ہیڈر میں trace_id بھیج سکتی ہے، جس سے کلائنٹ کے عمل کو سرور طرف کی پروسیسنگ سے منسلک کیا جا سکتا ہے۔ iOS اور Android کے لیے OpenTelemetry SDK HTTP کلائنٹس کے ذریعے خودکار trace سیاق و سباق کی تخلیق اور منتقلی کو سپورٹ کرتا ہے۔

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 انٹرسیپٹر سرور پر ہر HTTP درخواست کے لیے ایک span بناتا ہے۔ والدین کا سیاق و سباق Context.current() کے ذریعے کال کرنے والے کوڈ سے منتقل ہوتا ہے، جس سے کلائنٹ طرف کی ٹریسنگ کو سرور طرف کی ٹریسنگ سے منسلک کیا جا سکتا ہے۔

OpenTelemetry کے ذریعے ٹریسنگ کا نفاذ

OpenTelemetry trace ڈیٹا اکٹھا کرنے کا حقیقی معیار ہے۔ یہ spans بنانے کے لیے ایک متحد API، مقبول لائبریریوں کا خودکار تیاری، اور مختلف بیک اینڈز (Jaeger، Zipkin، Grafana Tempo، Datadog، New Relic) کو ڈیٹا برآمد کرنے کے لیے ایک لچکدار میکانزم فراہم کرتا ہے۔

خودکار تیاری

OpenTelemetry مقبول فریم ورکس (Spring Boot، Ktor، Flask، Express، gRPC) کے لیے خودکار span تخلیق کو سپورٹ کرتا ہے۔ ڈویلپر کو صرف پروجیکٹ میں ایک انحصار شامل کرنے کی ضرورت ہے، اور لائبریری خود بخود آنے والی اور جانے والی درخواستوں کو روک لیتی ہے۔ Java کے لیے خودکار تیاری ایک javaagent استعمال کرتا ہے جو سورس کوڈ کو تبدیل کیے بغیر بائٹ کوڈ میں فوری تبدیلی کرتا ہے۔

موبائل پلیٹ فارمز کے لیے، OpenTelemetry Swift SDK اور Kotlin SDK فراہم کرتا ہے۔ یہ نیٹ ورک درخواستوں (URLSession، OkHttp)، ڈیٹا بیس آپریشنز (CoreData، Room) اور پس منظر کے کاموں کے لیے خودکار طور پر spans بناتے ہیں۔ ڈویلپر کاروباری منطق کے لیے حسب ضرورت spans شامل کر سکتا ہے۔

ڈیٹا برآمد

جمع کردہ spans OTLP (OpenTelemetry Protocol) کے ذریعے کلیکٹر کو بھیجے جاتے ہیں۔ کلیکٹر ڈیٹا کو بفر، فلٹر اور ایک یا زیادہ ذخیرہ نظاموں کو بھیج سکتا ہے۔ OpenTelemetry دستاویزات کے مطابق، gRPC برآمد استعمال کرتے وقت span کی تخلیق سے ڈیش بورڈ میں ڈسپلے ہونے تک عام تاخیر 2-5 سیکنڈ ہے۔

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 خصوصیت بعد میں مخصوص صارف کے ذریعے traces کو فلٹر کرنے کی اجازت دیتی ہے۔

Trace نمونہ لینے کی حکمت عملی

زیادہ بوجھ والے نظاموں میں، ہر درخواست کو ٹریس کرنا ناممکن ہے — یہ ذخیرہ اور نیٹ ورک پر ناقابل قبول بوجھ پیدا کرتا ہے۔ نمونہ لینا صرف traces کے ایک حصے کو محفوظ کرکے اس مسئلے کو حل کرتا ہے۔ حکمت عملی کا انتخاب براہ راست ڈیٹا کی مکملیت اور انفراسٹرکچر کی لاگت کو متاثر کرتا ہے۔

ہیڈ بیسڈ نمونہ لینا

trace کو محفوظ کرنے کا فیصلہ اس کی تخلیق کے وقت — بنیادی span میں — کیا جاتا ہے۔ سب سے آسان اور عام طریقہ: درخواستوں کا ایک مقررہ فیصد (مثلاً 5%) محفوظ کیا جاتا ہے، باقی ضائع کر دیا جاتا ہے۔ نقصان — اس بات کی ضمانت نہیں دی جا سکتی کہ نایاب خرابیاں پکڑی جائیں گی۔ OpenTelemetry میں Probability sampler 0.0 سے 1.0 تک امکان کی ترتیب کو سپورٹ کرتا ہے۔

ٹیل بیسڈ نمونہ لینا

فیصلہ trace کے تمام spans کے مکمل ہونے تک مؤخر کر دیا جاتا ہے۔ ایک تجزیہ کار اندازہ لگاتا ہے کہ آیا trace میں خرابیاں، وقت کی حد سے تجاوز یا دلچسپ خصوصیات ہیں، اور تب ہی اسے محفوظ کرتا ہے۔ اس طریقہ کے لیے کلیکٹر میں تمام spans کو بفر کرنے کی ضرورت ہوتی ہے، جس سے میموری کی کھپت بڑھ جاتی ہے۔ Grafana Labs کے مطابق، نایاب لیکن اہم خرابیوں والے نظاموں میں "فی مفید ڈیٹا لاگت" کے لحاظ سے ٹیل بیسڈ نمونہ لینا 40-60% زیادہ موثر ہے۔

ٹریسنگ اور لاگنگ کے درمیان فرق

لاگنگ اہمیت کی سطحوں (info، warn، error) کے ساتھ انفرادی واقعات کو ریکارڈ کرتی ہے لیکن انہیں ایک درخواست کے سیاق و سباق میں نہیں جوڑتی۔ ٹریسنگ، اس کے برعکس، ایک سرے سے سرے تک کی درخواست سے تعلق رکھنے والے آپریشنز کا ایک منظم درخت بناتی ہے۔ عملی طور پر، یہ دو طریقے ایک دوسرے کو خارج نہیں کرتے بلکہ ایک دوسرے کی تکمیل کرتے ہیں۔

لاگ ایک مخصوص خرابی کے تفصیلی تجزیہ کے لیے موثر ہیں: ڈویلپر درست پیغام، اسٹیک ٹریس اور متغیر کی قدریں دیکھتا ہے۔ ٹریسنگ سوال کا جواب دیتی ہے "درخواست 5 سیکنڈ کیوں لے رہی ہے" — یہ دکھاتی ہے کہ کس مائیکرو سروس یا کال نے سب سے زیادہ وقت لیا۔ Honeycomb (2024) کے مطابق، ٹریسنگ کو لاگنگ کے ساتھ استعمال کرنے والی ٹیمیں واقعات کی بنیادی وجہ 2.3 گنا تیزی سے تلاش کرتی ہیں۔

جدید طریقہ — مشاہدہ پذیری — ٹریسنگ، میٹرکس اور لاگ کو ایک ہی نظام میں یکجا کرتا ہے۔ OpenTelemetry ان تین سگنلز کے درمیان ارتباط کو سپورٹ کرتا ہے: ہر span متعلقہ لاگ کے لنکس پر مشتمل ہو سکتا ہے، اور میٹرکس کو مخصوص traces میں جانے کے لیے trace_id سے ٹیگ کیا جا سکتا ہے۔