هابر يشرح القياس التلقائي في APM: أين تضيع 4 ثوانٍ من زمن الطلب

يستغرق تنفيذ الطلب 4 ثوانٍ. في التطبيق الأحادي (monolith) كان المطوّر سيشغّل أداة التحليل (profiler) ويعثر على الدالة الثقيلة خلال أمسية واحدة. أما في نظام يمر فيه الطلب عبر API Gateway وعدة خدمات مصغرة وطابور رسائل وقاعدة بيانات وAPI خارجي، فإن profiler على جهاز واحد لا يعرض سوى جزء من الصورة. نشر موقع هابر تحليلًا لكيفية إجابة APM عن سؤال «أين ذهب الوقت» بالاعتماد على التتبع الموزّع والقياس التلقائي.

Trace وspan: كيف تتشكل الصورة

في distributed tracing يُمثَّل كل طلب في صورة trace، أي مسار كامل عبر جميع المكوّنات. ويُقسَّم الـ trace إلى span: فكل استدعاء منفصل في الواجهة الأمامية أو الخلفية أو ناقل الرسائل يحصل على مقطع زمني خاص به. لكل span معرّف ومرجع إلى span الأب ووقت بدء ومدة. ومن هذه الروابط تتكوّن شجرة الاستدعاءات.

ولكي تظهر span من خدمات مختلفة في شجرة واحدة، يجب أن ينتقل السياق مع الطلب. وعادةً يتم ذلك اليوم عبر الترويسة traceparent من معيار W3C Trace Context. تحتوي هذه الترويسة على معرّف التتبع (16 بايت) ومعرّف span الحالي (8 بايت) وعلامات، مثل علامة أخذ العينات (sampling). تستقبل الخدمة الترويسة، وتنشئ span فرعية، ثم تمرّر السياق إلى الخدمة التالية.

كيف يعمل القياس التلقائي

في الطريقة اليدوية يلفّ المطوّر الاستدعاءات بكود التتبع في كل خدمة. وفي الفرق التي تضم عشرات الخدمات يتحول ذلك سريعًا إلى دَين تقني. يُلغي القياس التلقائي هذا العمل: يرتبط الوكيل ببيئة التشغيل (runtime) ويضيف بنفسه نقاط القياس حول المكتبات المعروفة.

تختلف الآليات حسب المنصة:

• Java: يعدّل الوكيل عبر -javaagent وjava.lang.instrument الـ bytecode أثناء تحميل الفئات، وغالبًا بالاعتماد على ASM أو Byte Buddy.
• .NET: يُستخدم Profiling API في بيئة CLR.
• Python وNode.js: تُستبدل الدوال في المكتبات الشائعة (monkey-patching وخطافات تحميل الوحدات).
• Go واللغات المترجمة: يكثر استخدام eBPF أو الأغلفة اليدوية، لأن بيئة التشغيل فيها أقل مرونة.

يعرف الوكيل نقاطًا نموذجية: خوادم HTTP وعملاءه، ومشغّلات قواعد البيانات، وعملاء الطوابير. ولا يحتاج إلى فهم منطق الأعمال ليقيس طلبًا وارِدًا أو استعلام SQL أو نشر رسالة. ومن هذه القياسات تنشأ span التي تنتقل إلى المجمّع (collector) ثم إلى مخزن APM.

أين يبلغ هذا النهج حدّه

يرى القياس التلقائي ما وُصف له مسبقًا فقط. فإذا ذهب الوقت في خوارزمية خاصة داخل دالة، أو في قفل على مورد مشترك، أو في مجموعة خيوط (thread pool)، فلن تُظهر الخطافات القياسية سوى span طويلة واحدة دون تفسير. وهنا تفيد span إضافية حول المقاطع الحرجة، إضافة إلى تحليل الخيوط (thread profiling).

وثمة موضوع مستقل هو الكلفة الإضافية. فالوكيل يضيف عملًا على كل استدعاء، ولذلك يُجمع التتبع في الغالب تقريبًا مع أخذ العينات. يحسم Head-based مصير التتبع في بداية الطلب، وكلفته منخفضة. أما Tail-based فيحسمه بعد الانتهاء، ولذلك يحتفظ بالطلبات البطيئة والخاطئة، لكنه يتطلب تخزينًا مؤقتًا في المجمّع.

التطبيق العملي: من أين نبدأ

إذا كان في النظام أكثر من ثلاث أو أربع خدمات، وكانت الحوادث تُحلَّل يدويًا عبر السجلات، فينبغي البدء بحد أدنى من الخطوات:

• تفعيل القياس التلقائي على مسار حرج واحد، مثل إتمام الطلب، وليس على البنية التحتية كلها دفعة واحدة.
• التحقق من انتقال traceparent من البداية إلى النهاية عبر البوابة والطوابير والمعالجات غير المتزامنة، فهي الأماكن التي تنقطع فيها التتبعات في أغلب الأحيان.
• إضافة span يدويًا حول المقاطع التي يعرضها الوكيل التلقائي كـ«صندوق أسود».
• ضبط أخذ العينات بحيث تُحفظ الطلبات البطيئة دائمًا (مثلًا ما يتجاوز p95).
• مطابقة النتيجة مع المقاييس والسجلات عبر trace ID المشترك، ليستغرق الانتقال بين الإشارات ثوانيَ معدودة.

يحوّل هذا النهج عبارة «النظام بطيء» إلى معطيات محددة: 3,1 ثانية ذهبت إلى API خارجي، و0,6 إلى استعلام قاعدة البيانات، والباقي إلى الطابور. ومن هنا تبدأ عملية التحسين، لا من التخمينات.