مختبر يعيد بناء رحلة الطلب بين الخدمات: مشاريع تخرج هندسة البرمجيات

تبدأ هذه الحالة من تذكرة دعم تقول إن عملية رفع ملف علقت، بينما كل خدمة تؤكد أن سجلها يبدو طبيعياً. لا يظهر السبب إلا حين نجمع آثار الطلب ونكتشف أن خدمة التحويل أرسلت span بلا رابط إلى طلبها الأصلي. في مشاريع تخرج هندسة البرمجيات يمكن تحويل هذا العطل إلى fixture يعاد تشغيله، ثم مقارنة الأثر قبل إصلاح تمرير السياق وبعده. معيار W3C Trace Context يحدد ترويسات سياق التتبع، وتشرح وثائق OpenTelemetry انتشار السياق بين العمليات. الغرض هنا تفسير ما انقطع، لا الادعاء بأن السجل يكشف السبب التجاري تلقائياً.

مثال عملي صغير

لنفترض أن الطلب T يبدأ بمقطع root في gateway، ثم ينتقل إلى profile، ثم إلى database. سجلت البيانات أربعة spans: root مدته 180 ms، وprofile مدته 120 ms، وdatabase مدته 70 ms، ومقطع audit مدته 15 ms لا يحتوي parentSpanId. يتوقع السيناريو أن يكون audit ابناً من profile. يعرض المختبر ثلاثة مقاطع متصلة وفرعاً يتيماً، ويشير إلى أن زمن root لا يساوي جمع مدد الأبناء بالضرورة لأن المقاطع قد تتداخل. لا يمثل المثال نتيجة نظام حقيقي، بل fixture يمكن للطالب أن يعدل فيه معرفاً واحداً ليرى أثره.

عند تصحيح parentSpanId للمقطع الأخير، يجب أن يتصل الفرع من دون أن يتغير traceId أو مدة المقاطع. إذا غيرت traceId بدلاً من ذلك، يفترض أن يبقى السجل ضمن مجموعة منفصلة أو يظهر كتعارض، لا أن يلتحق بالرسم خطأً. اعرض تفسيراً نصياً مثل «مقطع بلا أب مطابق» مع اسم الحقل والقيمة، وامنح المستخدم طريقة تنزيل التقرير المنظم. هذا يجعل المشروع مفيداً في المناقشة: يستطيع الطالب شرح السبب والنتيجة بدلاً من عرض رسوم جميلة لا توضح ما الذي تم التحقق منه.

ابدأ بعطل قابل للتكرار: البوابة ترى طلباً، وخدمة الملفات تسجل span ابن، ثم محول الصور ينتج span جديداً بمعرف trace مختلف. خزّن النسخة المكسورة كما هي، وعلّم العلاقة المتوقعة في ملف الحقيقة ground truth قبل أي تعديل. بعد ذلك أصلح propagation وأعد التشغيل. يعرض الفرق عدد الأجزاء التي عادت إلى الشجرة؛ لا تستخدم وقت الاستجابة وحده دليلاً على إصلاح الارتباط.

خطوات إعادة البناء

يبدأ سير العمل بتحميل trace واحد، وفحص الحقول، وتجميع المقاطع حسب traceId. بعد ذلك يبني خريطة spanId إلى سجل، ويربط كل عنصر بأبيه إن وجد. إذا لم يعثر على الأب، يسجل orphan reference بدلاً من صناعة عقدة وهمية. ثم يحسب المدة المتداخلة لكل خدمة ويرسم مخططاً زمنياً بسيطاً. معيار W3C يشرح حقول traceparent الأساسية وقواعد تنسيقها، لكنه لا يفرض على هذا المشروع شكل واجهة؛ لذا وثق قراراتك الخاصة ولا تنسبها للمواصفة. أضف خيار إظهار JSON الخام بجانب الرسم كي يسهل تتبع أي خطأ.

نفذ التحليل بمراحل قابلة للاختبار: parsing، validation، grouping، linking، presentation. إذا فشل parsing، لا تعرض رسماً جزئياً كأنه كامل. وإذا نجح parsing مع تحذير يتيم، يمكن عرض المتاح مع شارة واضحة. لا تجعل المولد يستخدم توقيتاً عشوائياً في كل تشغيل، وإلا فلن يستطيع الطالب مقارنة تغيير الخوارزمية. ثبّت seed للسيناريو أو خزّن fixtures صريحة. وفي واجهة السجل الكبير، أضف تصفية حسب الخدمة والحالة بدلاً من تحميل عناصر غير محدودة في DOM دفعة واحدة.

صمم نموذج الأحداث والعلاقات

لكل span سجل traceId وspanId وparentSpanId وservice وoperation وstartTime وduration وstatus. اجعل parentSpanId اختيارياً لأن الجذر لا يملك أباً، لكن لا تساو بين الجذر وبين سجل فقد رابطه: يمكن استنتاج الجذر إذا كان معروفاً من بيانات السيناريو، أما يتيم غير متوقع فيجب أن يظل تحذيراً. عند الاستيراد، تحقق من أن معرفات المقاطع فريدة ضمن trace، وأن المدة غير سالبة، وأن القيم قابلة للقراءة. لا تحذف الحدث السيئ؛ اعرضه في قائمة أخطاء الإدخال حتى يعرف الطالب لماذا استبعد من الرسم.

يمكن تخزين الملفات الخام كما وردت، مع نسخة normalized مستقلة لبناء العرض. هذا الفصل يسمح بمقارنة نتيجة التحويل بمصدرها، ويمنع تعديل المثال الأصلي أثناء التجربة. عندما تتوفر ساعات من أجهزة مختلفة، قد يبدو مقطع الابن سابقاً للأب بسبب فرق الساعة، لا بسبب ترتيب التنفيذ الفعلي. لذلك اعرض أوقات الجدار كقرينة تقريبية، واستعمل علاقات الأبوة لتكوين الشجرة. لا تستنتج السببية من قرب الطوابع الزمنية وحده، ولا ترتب الأحداث ترتيباً نهائياً إذا كان وقتها مفقوداً.

اختبارات القبول وحالات الفشل

اختبار القبول الأول أثر صغير معروف البنية: جذر وثلاثة أبناء، ويجب أن ينتج الرسم أربع عقد وثلاث حواف. اختبر أيضاً trace IDs مختلفة، وspan ID مكرراً، وأباً مفقوداً، ومدة سالبة، ووقتاً بصيغة غير مفهومة. أضف حالة لا تحتوي spans، وأخرى فيها حلقة أبوة مصطنعة حتى لا يدخل العارض في دوران لا نهائي. عند كل فشل، يجب أن يظهر سبب مفهوم، وأن تبقى الصفحة قابلة للاستخدام مع ملف آخر. قارن شجرة التحليل المتوقعة مع الناتج في اختبارات آلية صغيرة.

خط الأساس للمقارنة هو عارض نصي يفرز السجلات حسب الوقت ولا يحاول الربط. قس عدد علاقات الأبوة التي استعادها المختبر، وعدد orphan references التي اكتشفها، ووقت التحليل على fixtures ثابتة الأحجام. لا تدع نتيجة واحدة تثبت التفوق؛ كرر الاختبار عند أحجام مختلفة واذكر الجهاز والبيئة. معيار التتبع لا يضمن أن كل خدمة أرسلت السياق، لذلك يجب ألا تخفي الواجهة المفقود. إذا فقد وسيط ترويسة أو لم تنتج خدمة span، فالعارض يستطيع الإشارة إلى فجوة محتملة لكنه لا يعرف وحده أي مكون سببها.

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

حدد السؤال قبل بناء العارض

النطاق المقترح هو رحلة طلب HTTP تمر عبر بوابة، وخدمة ملفات، وخدمة تخزين، ثم تعود باستجابة. يسجل كل مكون span له trace ID وspan ID ووقت بدء ومدة واسم العملية، وقد يحمل parent span ID يشير إلى الجزء السابق. يعرّف معيار W3C Trace Context ترويسات HTTP لنقل سياق التتبع بين الخدمات؛ وشرح OpenTelemetry لانتشار السياق يوضح أن السياق هو ما يتيح ربط العمل عبر حدود الخدمة. المختبر لا يحتاج شبكة فعلية في البداية؛ يمكن تمثيل كل خدمة بمولد أحداث.

اكتب سؤال الاستخدام بدقة: هل نريد اكتشاف مقطع بلا أب؟ هل نريد معرفة إن كانت أزمنة المقاطع متداخلة على نحو غير معقول؟ هل نريد فصل طلبين لهما trace IDs مختلفة؟ هذه أسئلة مختلفة وتحتاج قواعد مختلفة. ابدأ بسجل JSON موحد موثق، واحتفظ بالوقت الأصلي والمنطقة الزمنية ووحدة المدة. إذا قبل النظام قيم milliseconds وnanoseconds من غير تعريف، فالمقارنة البصرية ستخدع الطالب. وثق أيضاً ما إذا كان معرف trace حساساً أو عشوائياً في النموذج، ولا تضع بيانات مستخدمين في أمثلة العرض.

حدود المشروع وتسليمه

نسخة التخرج المناسبة تتضمن مولد fixtures، مخطط JSON، محرك ربط، عارض timeline، وتقريراً قابلاً للتصدير. يمكن ربط العمل بمسار مشاريع التخرج ومراجعته ضمن المشاريع البرمجية. قدم مخططاً يوضح حدود النظام، واختبارات لكل حالة، وشرحاً للتوقيت ومعرفات السياق. إن أضفت SDK فعلياً، استخدم بيانات اختبار محلية ولا تسجل headers كاملة إن احتوت أسراراً أو معلومات تعريفية. لا تخلط trace ID بمفتاح مصادقة.

المختبر ليس منصة رصد إنتاجية، ولا يعالج وحده أخذ العينات أو الاحتفاظ طويل الأمد أو الخصوصية أو معنى كل span في مجال العمل. كما أن الساعات غير المتزامنة قد تجعل الترتيب الزمني مضللاً. اعرض هذه القيود في التقرير والواجهة، ولا تصف نتيجة المختبر بأنها تشخيص مؤكد. قوة المشروع أنه يجعل فقد السياق قابلاً للملاحظة والتكرار، ويتيح للفريق اختبار نموذج بياناته قبل توصيله ببنية رصد أكبر. يجب أن يستطيع المشرف تشغيل سيناريو مرفق والحصول على التحذيرات نفسها على جهاز آخر.