الآن بعد أن أصبحت لديك فكرة عن ماهية التتبُّع الموزع، دعنا نتعمق في كيفية عمله. على عكس التطبيقات المتجانسة، تعمل بيئات الخدمات المصغرة على واجهات خلفية موزعة، ما يجعل من الصعب تتبع رحلة الطلب بأكملها. لحسن الحظ، يمكن للتتبع الموزع متابعة إجراءات المستخدم في كل خطوة على الطريق ومراقبة كيفية تأثيره في تطبيقك من الواجهة الأمامية إلى النهاية الخلفية. 

يبدأ التتبُّع الموزع من خلال تجهيز بنية الخدمة المصغرة الخاصة بك. يمكنك استخدام أدوات مفتوحة المصدر مثل OpenTelemetry لبدء عملية جمع الأجهزة والقياس عن بُعد. 

بعد ذلك، يحتاج المطورون إلى تنفيذ التعليمات البرمجية في خدماتك لتتبُّع بيانات التتبُّع ووضع علامة على المعرفات الفريدة لكل معاملة. يمر سياق التتبُّع المشفر من خادم إلى آخر عبر بيئة التطبيق بأكملها. توفر المعرِّفات التي تُلحق نفسها برحلة المعاملة رؤية واضحة لتجربة العميل. 

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

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

أخيرًا، ستحتاج إلى دمج أداة التتبُّع الموزع الخاصة بك مع منصة مراقبة للحصول على مراقبة شاملة لتطبيقك. سيساعدك تضمين نظام أساسي مثل ®Instana على استخراج البيانات ومعالجتها لتتمكن من اتخاذ الخطوات التالية الصحيحة في حل أي خطأ في التطبيق. 

تعوق البنى الحديثة المعقدة قدرة التطبيقات الأحادية القديمة على التكيف مع الأدوات التي تستضيفها. ومع وضع هذا التحدي في الاعتبار، أصبح التتبُّع الموزع ضروريًا في تحقيق قابلية الملاحظة في البيئات السحابية الأصلية.

فيما يلي بعض الفوائد الرئيسية للتتبع الموزع:

• استكشاف المشكلات وإصلاحها بشكل أسرع: تقليل متوسط الوقت المستغرق للحل (MTTR) ومتوسط الوقت المستغرق للاكتشاف (MTTD) بشكل كبير. يمكن للمهندسين مراجعة عمليات التتبُّع الموزع للعثور على السبب الأساسي وموقع أخطاء التطبيق.

• تعزيز تعاون الفريق: في بيئة الخدمات المصغرة النموذجية، تقوم فِرَق متخصصة بالتعامل مع التقنيات المختلفة وتطويرها. ََيمكن أن يؤدي هذا الموقف إلى حدوث ارتباك بين الفِرَق إذا كانوا لا يعرفون مكان حدوث الخطأ ومن المسؤول عن حله. يمكن أن يساعد ارتباط التتبُّع الفِرَق الهندسية على تصور البيانات حتى يتمكنوا من تنبيه المطور الصحيح لإصلاح المشكلة. 

• التكامل والتنفيذ المرن: يمكن للمطورين تنفيذ التتبُّع الموزع في أي بيئة سحابية أصلية تقريبًا. والأدوات متوافقة مع مجموعة واسعة من لغات البرمجة والتطبيقات. 

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

• التجهيز اليدوي: تتطلب بعض منصات التتبُّع الموزع من المطورين تعديل التعليمات البرمجية الخاصة بهم لبدء تتبُّع طلبات المستخدمين. تستغرق عملية التجهيز اليدوي الكثير من الوقت، وتجعل تطبيقك أكثر عرضة للأخطاء، ويمكن أن تؤدي إلى فقدان بعض بيانات التتبُّع.

• عدم وجود تحليل للواجهة الأمامية: عند شراء أداة تتبع موزع، من المهم التأكد من حصولك على تغطية شاملة. دون هذه القدرة، ستكون لديك فقط نظرة ثاقبة للواجهة الخلفية دون تجربة الواجهة الأمامية للمستخدم النهائي. ويمكن لهذا القيد أن يزيد من صعوبة تصحيح أخطاء تطبيقك. 

• أخذ العينات: تستخدم بعض أدوات التتبُّع الموزع عملية أخذ عينات عشوائية، والتي تختار عمليات تتبُّع بشكل عشوائي لتحليلها. ولأن اختيار عمليات التتبُّع يتم عشوائيًا، ولا توجد طريقة لمعرفة عمليات التتبُّع التي ستواجه مشكلات، فقد يؤدي ذلك إلى عدم انتباه الفِرَق للأخطاء الرئيسية الموجودة. 

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

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

أحد العيوب الرئيسية للتسجيل وحده هو أنه لا يمكنه توفير نظرة شاملة تمامًا على أداء التطبيق دون عمليات تتبُّع. 

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

عادةً ما تدعم أدوات التتبُّع الموزع القياس وجمع البيانات والعرض المصور للبيانات في رسوم بيانية على شكل شعلة. والطريقة الأكثر شيوعًا لإعداد حلول التتبُّع الموزع هي استخدام الأدوات مفتوحة المصدر. 

إليك بعضًا من أشهر الخيارات مفتوحة المصدر المتاحة في السوق:

• إطار OpenTelemetry: يقدِّم OpenTelemetry مجموعة من أدوات تطوير البرامج (SDKs)، وبرامج جمع البيانات، وواجهات برمجة التطبيقات المستقلة عن البائعين وأدوات القياس. وهو مزيج من OpenCensus وOpenTracing. يُعَد إطار مراقبة الأداء الشهير هذا للبيئات السحابية أحد أكثر أدوات التتبُّع الموزع شيوعًا. ولا يتضمن OTel أدوات للتحليل أو العرض المصور للبيانات، ولكن يمكنك إرسال بيانات القياس عن بُعد إلى تطبيقات خارجية لإجراء هذا البحث.

• إطار OpenCensus: تم إنشاء OpenCensus بواسطة Google استنادًا إلى نظام التتبُّع الداخلي الخاص بها. في نهاية المطاف أصبح مفتوح المصدر وأصبح متاحًا في مكتبات متعددة اللغات. يستطيع هذا الإطار جمع البيانات ونقلها إلى المنصات الخلفية للمساعدة على تصحيح الأخطاء، ولكن للأسف، لا توجد به واجهة برمجة تطبيقات لتضمين البرنامج في التعليمات البرمجية. هذا القيد هو أحد الأسباب الرئيسية لدمج OpenCensus وOpenTracing معًا بواسطة مؤسسة Cloud Native Computing Foundation لإنشاء OpenTelemetry. 

• إطار OpenTracing: هو واجهة برمجة تطبيقات لا تعتمد على البائعين وتساعد المطورين على إعداد التعليمات البرمجية للتتبع الموزع. يتوفر هذا المشروع مفتوح المصدر بتسع لغات مختلفة، بما في ذلك Java وPython وRuby. 

• Zipkin: هو مشروع آخر مفتوح المصدر أنشأته شركة Twitter. يساعد نظام التتبُّع الموزع هذا محترفي عمليات التطوير على جمع بيانات التطبيق المهمة واستكشاف مشكلات زمن الانتقال وإصلاحها في بنيات الخدمة المختلفة. ويمكنك إرسال البيانات إلى Zipkin باستخدام Apache أو Kafka أو HTTP.

• Jaeger: هو أحدث مشروع مفتوح المصدر في هذه القائمة، وقد أنشأته شركة Uber ويتكامل بسهولة مع OpenTracing. تتميز هذه الأداة بأنها مرنة للغاية، ما يجعلها خيارًا رائعًا لتتبع الطلبات من خلال بيئة الخدمات المصغرة. يساعد كل من Zipkin وJaeger على تصور الإحصائيات ولكن لديهما قيود فيما يتعلق بأخذ عينات من البيانات.

على الرغم من أن استخدام OpenCensus وOpenTracing كان شائعًا في الماضي، إلا أننا ننصح باستخدام OpenTelemetry أو Zipkin أو Jaeger. استخدم هذه الأدوات مع أداة لإدارة أداء التطبيقات أو أداة للمراقبة مثل Instana للحصول على رؤية واضحة وكاملة لما يحدث داخل تطبيقك. 

لفهم التفاعل بين الرسائل التي يتم تمريرها بين تطبيقك ومكوناته، تحتاج إلى التتبُّع. مع Instana AutoTrace، لن يفوتك أي سياق أو اتصال؛ بسبب قدراتنا على التقاط جميع الطلبات وربط عمليات التتبُّع من واجهات برمجة التطبيقات مفتوحة المصدر. يُسهم Instana في تسهيل هذا الأمر من خلال الرسم البياني الديناميكي المتوفر به.

نقوم بتحسين كل عملية تتبُّع بين التطبيق والخدمة وبنية النظام لنمنحك تغطية كاملة للنظام. لتجربة Instana مع التتبُّع الموزع، سجِّل للحصول على فترة تجريبية مجانية لمدة أسبوعين لتجربة ميزاتنا.