الهدف الأساسي من الـ Distributed Tracing هو توفير رؤية واضحة لرحلة الطلب (Request) عشان لو فيه مشاكل أو بطء في الأداء نقدر نحدد مصدرها. بنقدر نعرف فين بالتحديد الـ bottleneck أو الخدمة اللي فيها مشكلة.
في التطبيقات الكبيرة وخصوصًا اللي بتتعامل مع المايكروسيرفسز (Microservices)، بيبقى عندنا الـ System مُقسم لمجموعة خدمات (Services) صغيرة بتشتغل مع بعض عشان تنفذ المهام.
ولما بيجي طلب (Request)، بيعدي من خلال كذا خدمة، وأحياناً ممكن يعدي على سيرفرات مختلفة. هنا بيجي دور الـ Distributed Tracing، اللي هو عملية تتبع الطلب عبر النظام كله عشان نعرف مشواره من أول ما وصل لحد ما خلص.
والهدف الأساسي من الـ Distributed Tracing هو توفير رؤية واضحة لرحلة الطلب (Request) عشان لو فيه مشاكل أو بطء في الأداء نقدر نحدد مصدرها. بنقدر نعرف فين بالتحديد الـ bottleneck أو الخدمة اللي فيها مشكلة. الفكرة ببساطة إننا بنخلي النظام زي خريطة واضحة للـ flow بتاع الطلبات عشان نقدر نفهم كل خطوة.
وعشان نفهم اكتر رحلة الـ Request Flow ونتعرف ازاي الـ Distributed Tracing بيتم محتاجين نتعرف اصلا على الـ TraceID.
TraceID
وقت ما بتعمل Order من تطبيق توصيل للأكل الطلب بتاعك بيمر ب Services كتير من اول تحديد المطاعم المتاحة لحساب وقت التوصل و إرسال الطلبات لعامل التوصيل و خدمة تتبع الطلب إلخ…
فالـ Trace Id بيكون " مُعرف التتبع " بيكون مع الطلب و هو رايح لكل Service من دي عشان يميز الـ Order دا عن غيره و نعرف نتتبع مساره من أول خدمة لاخر خدمة.
ودا لأن كل Service بتعامل الـ Order كـ Request جديد وممكن متكونش عارفة حاجة عن الـ Service اللي قبلها او اللي بعدها.
💡
الـ TraceID هو حاجة أساسية جداً في عملية التتبع دي. ده عبارة عن Identifier (معرف) بيبقى مميز لكل طلب، بيتولد مع أول خطوة بيعملها الطلب في النظام. الهدف منه إنه يخلي كل خطوة أو خدمة تشتغل مع الطلب ده تقدر تتعرف عليه.
وقت الـ Monitoring نقدر نستخدم الـ TraceID عشان نحصل علي ال Logs او الـ Errors المرتبطة بالطلب دا من كل الخدمات في نظامنا في مكان واحد.
