في الماضي، عندما تحدثنا عن الواجهة الخلفية، كنا نشير عادةً إلى تطبيق واحد كبير به قاعدة بيانات واحدة كبيرة، وكان التسجيل كافيًا للمراقبة. الآن، بفضل تقنيات مثل   ، أصبحت   هي المعيار. أصبحت التطبيقات أكثر عددًا وتوزيعًا، ولم يعد التسجيل التقليدي كافيًا   وتشخيص المشكلات في تطبيقاتنا. Kubernetes الخدمات المصغرة لتصحيح الأخطاء  الحل الأمثل لتنظيم المراقبة هو OpenTelemetry — وهي مجموعة أدوات حديثة يمكن استخدامها لاستكشاف الأخطاء وإصلاحها وتحليل أداء الأنظمة الموزعة.  هذه المقالة مخصصة لمحترفي تكنولوجيا المعلومات الذين يسعون إلى توسيع معرفتهم بتحسين الواجهة الخلفية. فيما يلي، سنوضح بالتفصيل ماهية OpenTelemetry ومفاهيمها الرئيسية والمشكلات التي تساعد في حلها. إذا كنت مهتمًا بكيفية قدرة OpenTelemetry على تغيير نهجك في مراقبة أنظمة الواجهة الخلفية وتصحيح أخطائها، وتعزيز موثوقيتها وكفاءتها، فاقرأ المزيد.  نبذة مختصرة عن OpenTelemetry  واجهت شركات التكنولوجيا الكبرى لأول مرة تحدي التسجيل والتتبع الموزع في أواخر العقد الأول من القرن الحادي والعشرين. في عام 2010، نشرت جوجل ورقة بحثية،  ، والتي وضعت الأساس لأداة التتبع الخاصة بتويتر، Zipkin، والتي تم إصدارها في عام 2012.   Dapper، بنية أساسية واسعة النطاق لتتبع الأنظمة الموزعة  في عام 2014، ظهر نظام Kubernetes، مما أدى إلى تبسيط تطوير الخدمات المصغرة وغيرها من الأنظمة الموزعة عبر السحابة بشكل كبير. وقد أدى هذا إلى مواجهة العديد من الشركات لمشاكل في التسجيل والتتبع الموزع في الخدمات المصغرة. ولتوحيد التتبع الموزع، تم إنشاء معيار OpenTracing، الذي تبناه CNCF، ومشروع OpenCensus التابع لشركة Google.  في عام 2019، أعلن مشروعا OpenTracing وOpenCensus عن اندماجهما تحت اسم OpenTelemetry. تجمع هذه المنصة بين أفضل الممارسات المتراكمة على مدار سنوات عديدة، مما يسمح بالتكامل السلس للتتبع والتسجيل والقياسات في أي نظام، بغض النظر عن تعقيدها.  اليوم، لم يعد OpenTelemetry مجرد مشروع؛ بل أصبح معيارًا صناعيًا لجمع ونقل بيانات القياس عن بعد. وقد تم تطويره ودعمه من قبل مجتمع من المتخصصين والشركات الرائدة في السوق مثل Google وMicrosoft. ويستمر المشروع في التطور، حيث اكتسب قدرات جديدة لتبسيط عملية التكامل والاستخدام.    ماذا يوجد بالداخل؟  OpenTelemetry عبارة عن مجموعة شاملة من الممارسات والأدوات التي تحدد الإشارات التي يمكن للتطبيق توليدها للتفاعل مع العالم الخارجي، وكيف يمكن جمع هذه الإشارات وتصورها لمراقبة حالة التطبيقات والنظام ككل. الأنواع الثلاثة الرئيسية للإشارات هي     . التتبع والتسجيل وجمع المقاييس  **دعونا نلقي نظرة فاحصة على كل مكون: \   السياقات  يقدم OpenTelemetry مفهوم سياقات التشغيل. يتضمن السياق بشكل أساسي سمات مثل   (معرف للعملية الحالية) و`   (معرف لطلب فرعي، مع وجود   فريد لكل إعادة محاولة لطلب فرعي). `trace_id` `span_id` `span_id`  بالإضافة إلى ذلك، يمكن أن يحتوي السياق على معلومات ثابتة، مثل اسم العقدة التي تم نشر التطبيق عليها أو اسم البيئة (prod/qa). يتم إرفاق هذه الحقول، المعروفة باسم الموارد في مصطلحات OpenTelemetry، بكل سجل أو مقياس أو تتبع لتسهيل إمكانية البحث. يمكن أن تتضمن السياقات أيضًا بيانات ديناميكية، مثل معرف نقطة النهاية الحالية (   )، والتي يمكن إرفاقها بشكل انتقائي بمجموعات من السجلات أو المقاييس أو التتبعات. `http_path: "GET /user/:id/info"`  يمكن تمرير سياقات OpenTelemetry بين تطبيقات مختلفة باستخدام بروتوكولات انتشار السياق. تتكون هذه البروتوكولات من مجموعات رأسية تُضاف إلى كل طلب HTTP أو gRPC أو رؤوس الرسائل للطوابير. يسمح هذا للتطبيقات الموجودة في اتجاه مجرى النهر بإعادة بناء سياق العملية من هذه الرؤوس.   وفيما يلي بعض الأمثلة على انتشار السياق:    هذه مجموعة من الرؤوس (   ) تم تطويرها في الأصل لنظام تتبع Zipkin. تم تكييفها في OpenTracing واستخدامها بواسطة العديد من الأدوات والمكتبات. تحمل B3-Propagation معرف   /   وعلمًا يشير إلى ما إذا كان أخذ العينات ضروريًا. B3-Propagation x-b3-* trace_id span_id  تم تطوير هذا المعيار بواسطة مجموعة عمل W3C، وهو يوحد بين مختلف أساليب نشر السياق في معيار واحد وهو المعيار الافتراضي في OpenTelemetry. ومن الأمثلة الجيدة لتطبيق هذه المعايير تتبع تنفيذ طلب يمر عبر خدمات دقيقة تم تنفيذها باستخدام تقنيات مختلفة دون المساس بدقة المراقبة   . والتصحيح   التتبع     التتبع هو عملية تسجيل وتصور الجدول الزمني لمسار الطلب من خلال خدمات دقيقة متعددة.  في التصور، يُطلق على كل شريط اسم "span" وله   فريد. يُشار إلى النطاق الجذري باسم   وله   ، والذي يعمل كمعرف للطلب بأكمله. "span_id" "trace" "trace_id"   يسمح لك هذا النوع من التصور بما يلي:  قم بتحليل وقت تنفيذ الطلبات عبر الأنظمة وقواعد البيانات المختلفة لتحديد الاختناقات التي تحتاج إلى تحسين.  اكتشاف التبعيات الدورية بين الخدمات.  البحث عن الطلبات المكررة. باستخدام بيانات التتبع، يمكنك أيضًا إنشاء تحليلات إضافية، مثل إنشاء خريطة للخدمات المصغرة أو توزيع الوقت عبر أنظمة مختلفة أثناء معالجة العمليات. حتى إذا لم تستخدم بيانات التتبع لتصور الجداول الزمنية، فإن OpenTelemetry لا يزال ينشئ   و   للاستخدام في إشارات أخرى. trace_id span_id   السجلات  على الرغم من بساطته الظاهرة، يظل التسجيل أحد أقوى الأدوات لتشخيص المشكلات. يعمل OpenTelemetry على تحسين التسجيل التقليدي من خلال إضافة معلومات سياقية. على وجه التحديد، إذا كان هناك تتبع نشط، تتم إضافة سمات `trace_id` و`span_id` تلقائيًا إلى السجلات، وربطها بخط زمني للتتبع. علاوة على ذلك، يمكن أن تتضمن سمات السجل معلومات ثابتة من سياق OpenTelemetry، مثل معرف العقدة، بالإضافة إلى معلومات ديناميكية، مثل معرف نقطة نهاية HTTP الحالية (`http_path: "GET /user/:id"`).  باستخدام `trace_id`، يمكنك العثور على سجلات من جميع الخدمات المصغرة المرتبطة بالطلب الحالي، بينما يسمح لك `span_id` بالتمييز بين الطلبات الفرعية. على سبيل المثال، في حالة إعادة المحاولة، ستحتوي السجلات من محاولات مختلفة على `span_id` مختلفة. يتيح استخدام هذه المعرفات تحليلًا سريعًا لسلوك النظام بأكمله في الوقت الفعلي، مما يسرع من تشخيص المشكلة ويعزز الاستقرار والموثوقية.   المقاييس  توفر مجموعة المقاييس بيانات كمية عن أداء النظام، مثل زمن الوصول ومعدلات الخطأ واستخدام الموارد والمزيد. تتيح لك مراقبة المقاييس في الوقت الفعلي الاستجابة السريعة لتغيرات الأداء ومنع الأعطال واستنفاد الموارد وضمان توافر التطبيق وموثوقيته للمستخدمين.  يجعل التكامل مع أنظمة التخزين والتصور المترية مثل Prometheus وGrafana من الأسهل تصور هذه البيانات، مما يبسط عملية المراقبة بشكل كبير.   جامعو القياسات المترية  تتوافق أدوات جمع المقاييس OpenTelemetry مع معايير Prometheus وOpenMetrics، مما يتيح الانتقال بسهولة إلى حلول OpenTelemetry دون تغييرات كبيرة. تتيح مجموعة أدوات OpenTelemetry SDK تصدير أمثلة trace_id مع المقاييس، مما يجعل من الممكن ربط المقاييس بأمثلة السجل والتتبعات.  ارتباط الإشارة   تعمل السجلات والمقاييس والتتبع معًا على إنشاء عرض شامل لحالة النظام:  توفر السجلات معلومات حول أحداث النظام، مما يسمح بالتعرف السريع على الأخطاء وحلها.  تعكس المقاييس مؤشرات الأداء النوعية والكمية للنظام، مثل أوقات الاستجابة أو معدلات الخطأ.  يكمل التتبع هذا العرض من خلال إظهار مسار تنفيذ الطلب عبر مكونات النظام المختلفة، مما يساعد على فهم العلاقات المتبادلة بينها. يعد الارتباط الواضح بين السجلات والتتبعات والمقاييس سمة مميزة لـ OpenTelemetry. على سبيل المثال، يسمح Grafana للمستخدمين برؤية التتبع المقابل ومقاييس الطلب عند عرض سجل، مما يعزز بشكل كبير من قابلية استخدام المنصة وكفاءتها.   بالإضافة إلى المكونات الأساسية الثلاثة، يتضمن OpenTelemetry مفاهيم أخذ العينات والأمتعة وإدارة سياق التشغيل.   أخذ العينات  في الأنظمة عالية التحميل، يصبح حجم السجلات والتتبعات هائلاً، مما يتطلب موارد كبيرة للبنية الأساسية وتخزين البيانات. لمعالجة هذه المشكلة، تتضمن معايير OpenTelemetry أخذ عينات من الإشارات - القدرة على تصدير جزء فقط من التتبعات والسجلات. على سبيل المثال، يمكنك تصدير إشارات مفصلة من نسبة من الطلبات أو الطلبات طويلة الأمد أو طلبات الأخطاء. يسمح هذا النهج بأخذ عينات كافية لبناء الإحصائيات مع توفير موارد كبيرة.  ومع ذلك، إذا قرر كل نظام بشكل مستقل الطلبات التي يجب مراقبتها بالتفصيل، فسننتهي إلى عرض مجزأ لكل طلب. قد تقوم بعض الأنظمة بتصدير بيانات مفصلة بينما قد تقوم أنظمة أخرى بتصدير جزئي فقط أو لا تقوم بالتصدير على الإطلاق.  لحل هذه المشكلة، ترسل آليات انتشار السياق في OpenTelemetry علم أخذ العينات مع `trace_id`/`span_id`. وهذا يضمن أنه إذا قررت الخدمة الأولية التي تتلقى طلب المستخدم أن يتم مراقبة الطلب بالتفصيل، فإن جميع الأنظمة الأخرى ستتبع نفس النهج. وإلا، فيجب على جميع الأنظمة تصدير الإشارات جزئيًا أو عدم تصديرها للحفاظ على الموارد. يُطلق على هذا النهج "أخذ العينات الأولية" - وهو قرار يتم اتخاذه في بداية معالجة الطلب، إما بشكل عشوائي أو بناءً على بعض سمات الإدخال.  بالإضافة إلى ذلك، يدعم OpenTelemetry "Tail Sampling"، حيث تقوم جميع التطبيقات دائمًا بتصدير جميع الإشارات بالتفصيل، ولكن يوجد مخزن مؤقت وسيط. بعد جمع كل البيانات، يقرر هذا المخزن المؤقت ما إذا كان سيحتفظ بالبيانات الكاملة أو يحتفظ بعينة جزئية فقط. تسمح هذه الطريقة بعينة أكثر تمثيلاً لكل فئة طلب (ناجحة/طويلة/خطأ) ولكنها تتطلب إعداد بنية أساسية إضافية.   أمتعة  تسمح آلية الأمتعة بنقل أزواج قيمة مفتاحية عشوائية مع   /   ، مما يؤدي إلى المرور تلقائيًا بين جميع الخدمات المصغرة أثناء معالجة الطلب. وهذا مفيد لنقل المعلومات الإضافية المطلوبة طوال مسار الطلب—مثل معلومات المستخدم أو إعدادات بيئة وقت التشغيل. trace_id span_id     مثال على رأس لنقل الأمتعة وفقًا لمعيار W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5   فيما يلي بعض الأمثلة على استخدام الأمتعة:  يمكن   مثل   أو   أو   عبر جميع الخدمات المصغرة. يمكن للتطبيقات تسجيل هذه المعلومات تلقائيًا، مما يسمح بإجراء عمليات بحث في السجل حسب سياق المستخدم للطلب الأصلي. تمرير معلومات سياق العمل userId productId deviceId  إعدادات   لمجموعات تطوير البرامج (SDK) أو البنية الأساسية. معلمات التكوين المحددة    هي الأعلام التي تساعد موازنات التحميل على اتخاذ قرارات التوجيه. أثناء الاختبار، قد يلزم توجيه بعض الطلبات إلى واجهات خلفية وهمية. نظرًا لأن الأمتعة يتم نقلها تلقائيًا عبر جميع الخدمات، فلا توجد حاجة لإنشاء بروتوكولات إضافية - فقط قم بإعداد قاعدة على موازن التحميل. أعلام التوجيه  لاحظ أنه على الرغم من أن تأثير Baggage على الأداء ضئيل، إلا أن الاستخدام المفرط قد يؤدي إلى زيادة كبيرة في تحميل الشبكة والخدمة. اختر بعناية البيانات التي تحتاجها حقًا لتمريرها عبر Baggage لتجنب مشكلات الأداء.   تنفيذ البنية التحتية  يتضمن تنفيذ OpenTelemetry على مستوى البنية الأساسية دمج واجهات OpenTelemetry الخلفية في بنية التطبيق وتكوين البنية الأساسية لتجميع البيانات.   تتكون العملية من أربع مراحل:    في المرحلة الأولى، يتم دمج SDKs OpenTelemetry مباشرة في التطبيقات لجمع المقاييس والسجلات والتتبعات، مما يضمن تدفقًا مستمرًا للبيانات حول أداء كل مكون من مكونات النظام. تكامل التطبيقات  يتم   البيانات المجمعة من التطبيقات عبر المصدرين إلى أنظمة خارجية لمزيد من المعالجة، مثل أنظمة التسجيل أو المراقبة أو التتبع أو التحليلات، اعتمادًا على احتياجاتك. توجيه    قد تتضمن هذه المرحلة تطبيع البيانات، وإثرائها بمعلومات إضافية، ودمج البيانات من مصادر مختلفة لإنشاء عرض موحد لحالة النظام. التجميع والتخزين  أخيرًا، يتم عرض البيانات المعالجة على هيئة لوحات معلومات في أنظمة مثل Grafana (للقياسات والتتبعات) أو Kibana (للسجلات). يتيح هذا للفرق تقييم صحة النظام بسرعة وتحديد المشكلات والاتجاهات وإعداد التنبيهات بناءً على   المولدة. الإشارات  تنفيذ التطبيق  للتكامل مع تطبيق ما، تحتاج إلى توصيل مجموعة أدوات OpenTelemetry SDK المناسبة للغة البرمجة المستخدمة أو استخدام المكتبات والأطر التي تدعم OpenTelemetry بشكل مباشر. غالبًا ما تنفذ OpenTelemetry واجهات مستخدمة على نطاق واسع من المكتبات المعروفة، مما يسمح بالاستبدال الفوري. على سبيل المثال، تُستخدم مكتبة Micrometer بشكل شائع لجمع المقاييس في نظام Java البيئي. توفر مجموعة أدوات OpenTelemetry SDK تنفيذاتها لواجهات Micrometer، مما يتيح تصدير المقاييس دون تغيير كود التطبيق الرئيسي. علاوة على ذلك، تقدم OpenTelemetry تنفيذات لواجهات OpenTracing وOpenCensus الأقدم، مما يسهل الانتقال السلس إلى OpenTelemetry.  خاتمة  في أنظمة تكنولوجيا المعلومات، يمكن أن يصبح OpenTelemetry مفتاحًا لمستقبل واجهات خلفية موثوقة وفعالة. تعمل هذه الأداة على تبسيط تصحيح الأخطاء والمراقبة كما تفتح فرصًا لفهم أداء التطبيق وتحسينه على مستوى جديد. انضم إلى مجتمع OpenTelemetry للمساعدة في تشكيل مستقبل حيث يكون تطوير الواجهة الخلفية أبسط وأكثر فعالية!

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Even

Google

Microsoft

Real

reflect

Trace

Read My Stories

تم إنتاج هذا الصوت باللغة الأصلية للقصة!

ما هو OpenTelemetry وكيف يمكنه تحسين جودة الواجهة الخلفية لديك؟

About Author

تعليقات

شنق العلامات

تم تقديم هذه المقالة في

Related Stories

How can AR, IoT, Blockchain and Chatbots redefine Customer Experience

Top Web Development Companies in 2018

Top 10 IoT Application Development Companies

The shortage of women in tech

How can AR, IoT, Blockchain and Chatbots redefine Customer Experience

Top Web Development Companies in 2018

Top 10 IoT Application Development Companies

The shortage of women in tech

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps