دليل الرصد · OpenTelemetry
OpenTelemetry: ما الذي يوحّده، وما الذي يتركه لمنصة الرصد، وكيف تعتمدونه
OpenTelemetry (ويُختصر OTel) إطار مفتوح المصدر يحدد كيف تُنتج التطبيقات التتبعات (Traces) والمقاييس (Metrics) والسجلات (Logs) وكيف ترسلها: مجموعة واحدة من واجهات API، وصيغة بيانات واحدة، وبروتوكول واحد، أيًّا كانت لغة البرمجة التي كُتبت بها الخدمة. وهو لا يخزّن البيانات ولا يرسم لوحات المتابعة ولا يطلق التنبيهات؛ فهذا عمل منصة الرصد، مثل Datadog. يشرح هذا الدليل ما يغطيه OpenTelemetry، وأين يتوقف، وكيف تعتمده منشأة لديها خدمات بعدة لغات برمجة دون أن تُنجز عمل القياس مرتين.
نُشر في 9 دقائق قراءة
الخلاصة في أربع نقاط
- ما هو: معيار مفتوح تشرف عليه مؤسسة Cloud Native Computing Foundation (CNCF)، التي نقلته إلى مرحلة "التخرّج" (Graduated) في 11 مايو 2026. ويوفّر واجهات API، وحزم SDK لكل لغة، وقياسًا تلقائيًا، واصطلاحات تسمية، وبروتوكول نقل (OTLP)، وأداة Collector.
- ما الذي يوحّده: طريقة توليد بيانات الرصد، وتسميتها، ونقلها.
- ما الذي يتركه لمنصتكم: التخزين، والبحث، ولوحات المتابعة، والتنبيهات، والتحليل.
- لماذا تعتمده المنشآت: القياس الذي يُكتب مرة واحدة يبقى صالحًا إذا تغيّرت منصة التحليل، ومسار واحد يستطيع تطبيق الإخفاء وأخذ العيّنات والتوجيه على كل لغات البرمجة بالطريقة نفسها.
المشكلة التي يحلّها OpenTelemetry
في بيئة بنتها فرق مختلفة على مدى سنوات، كثيرًا ما تُكتب الخدمات بعدة لغات وتُراقَب بطرق مختلفة: خدمة تستخدم أداة من مزوّد، وأخرى تكتب سجلاتها في ملفات، وثالثة بلا مراقبة أصلًا. وحين يقع عطل يمسّ العملاء، يضيع وقت المهندسين في جمع الأدلة من أدوات لا تتشارك المعرّفات ولا التسميات.
يستبدل OpenTelemetry هذه العادات المتفرقة بمعيار واحد. فكل خدمة، بأي لغة كانت، تنتج الأنواع نفسها من البيانات بالأسماء نفسها، وترسلها عبر البروتوكول نفسه. وهذا ما يجعل تتبّع الطلب ممكنًا من خدمة إتمام الطلب المكتوبة بـ Python إلى خدمة المدفوعات المكتوبة بـ Java والعودة، في عرض واحد.
اقرأ المزيد
ومن الطرق المفيدة لشرحه لغير المهندسين تشبيه حاوية الشحن:
| الشحن | البرمجيات |
|---|---|
| بضائع من كل نوع | بيانات الرصد: التتبعات (رحلة الطلب)، والمقاييس (أرقام عبر الزمن)، والسجلات (قيود الأحداث) |
| الحاوية القياسية | صيغة بيانات OpenTelemetry وبروتوكوله (OTLP) |
| المصانع التي تعبّئ الحاويات | تطبيقات .NET وJava وPython تعبّئ بيانات الرصد بحزم OpenTelemetry SDK |
| الموانئ وساحات الفرز | OpenTelemetry Collector، الذي يستقبل البيانات ويفحصها وينقّيها ويوجّهها |
| المستودع في الوجهة | منصة الرصد، مثل Datadog، التي تخزّن وتحلّل وتنبّه |
ولأن كل تطبيق يعبّئ بياناته بالطريقة نفسها، يمكن تغيير الوجهة، أو إضافة وجهة ثانية، دون المساس بشيفرة التطبيقات.
مكوّنات OpenTelemetry
OpenTelemetry مجموعة من الأجزاء، ويتعامل كل فريق في منشأتكم مع جزء مختلف منها.
| الجزء | وظيفته | من يتعامل معه |
|---|---|---|
| API | الواجهات التي تستدعيها الشيفرة لإنشاء الـ Spans والمقاييس وقيود السجلات | مطوّرو التطبيقات |
| SDK (واحدة لكل لغة) | تنفّذ الـ API: المعالجة، وأخذ العيّنات، والتصدير | المطوّرون وفريق المنصة |
| القياس التلقائي | يلتقط أطر العمل والمكتبات الشائعة، مثل طلبات HTTP الواردة واستدعاءات قواعد البيانات، دون تغيير الشيفرة | فريق المنصة |
| الاصطلاحات الدلالية (Semantic Conventions) | أسماء خصائص قياسية، مثل service.name وhttp.route، حتى تعني بيانات الفرق المختلفة الشيء نفسه | الجميع |
| OTLP | بروتوكول النقل، عبر gRPC (المنفذ 4317) أو HTTP (المنفذ 4318) | فريق المنصة وفريقا الشبكات والأمن |
| Collector | خدمة تشغّلونها لاستقبال بيانات الرصد ومعالجتها وتمريرها | فريق المنصة أو فريق SRE |
كيف ترتبط الإشارات الثلاث. يحمل كل طلب سياق تتبّع ينتقل من خدمة إلى أخرى (ترويسة W3C traceparent). وتشترك الـ Spans التي تُنشأ على الطريق في معرّف تتبّع واحد، ويمكن أن تحمل قيود السجلات المكتوبة أثناء الطلب معرّفي التتبّع والـ Span نفسيهما. وهذا السياق المشترك هو ما يتيح للمنصة الانتقال من طلب بطيء إلى سجلاته ومقاييس الخدمات التي مرّ بها.
ما الذي لا يقوم به OpenTelemetry
يتوقف OpenTelemetry عمدًا عند الجمع والنقل. وكل ما بعد ذلك من عمل المنصة التي ترسلون إليها البيانات.
| القدرة | OpenTelemetry | منصة الرصد لديكم (مثل Datadog) |
|---|---|---|
| مكتبات القياس لـ .NET وJava وPython ولغات أخرى | نعم | — |
| صيغة بيانات وبروتوكول قياسيان (OTLP) | نعم | تستقبلهما |
| مسار محايد تجاه المزوّدين (الـ Collector) | نعم | تستقبل منه |
| التخزين طويل المدى والاستعلام السريع | — | نعم |
| خرائط الخدمات، وعرض التتبعات الموزّعة، ومراقبة أداء التطبيقات | — | نعم |
| إدارة السجلات مربوطة بالتتبعات | — | نعم |
| التنبيهات، وأهداف مستوى الخدمة، واكتشاف الشذوذ | — | نعم |
| لوحات متابعة للمهندسين والتنفيذيين | — | نعم |
ولهذا التقسيم أثر في الميزانية: اعتماد OpenTelemetry لا يُغني عن منصة، واختيار منصة لا يعني بالضرورة ربط شيفرتكم بها.
ثلاثة قرارات قبل أن يبدأ أحدٌ قياس أي خدمة
يصعب تغيير هذه القرارات الثلاثة بعد أن تعتمد عليها عشرات الخدمات، فاحسموها مركزيًا بدل تركها لكل فريق.
1. معيار للتسمية والوسوم. قرّروا مرة واحدة كيف تُسمّى الخدمات والبيئات، لأن هذه الخصائص تصبح المرشّحات التي يستخدمها الجميع. ومن المعايير العملية:
| الخاصية | إلزامية | القاعدة |
|---|---|---|
service.name | نعم | أحرف صغيرة، مفصولة بشرطات، وفريدة على مستوى المنشأة: domain-component، مثل payments-gateway |
deployment.environment.name | نعم | إحدى القيم: dev أو test أو uat أو staging أو prod |
service.version | نعم | رقم إصدار دلالي أو معرّف إيداع Git (Commit SHA) يضيفه مسار CI/CD، ولا يُكتب يدويًا في الشيفرة أبدًا |
service.namespace | يُوصى بها | مجال العمل أو خط المنتج، مثل retail |
team | يُوصى بها | الفريق المالك، وتُستخدم للتوجيه وتحديد المسؤولية، مثل checkout |
اقرأ المزيد
يقرأ Datadog الخاصية service.name على أنها وسم service، وservice.version على أنها version، وdeployment.environment.name على أنها env. ويدعم Datadog الخاصية deployment.environment.name بدءًا من Agent بالإصدار 7.58.0 وDatadog Exporter بالإصدار v0.110.0؛ أما الإصدارات الأقدم فتقرأ المفتاح السابق deployment.environment. وما دام الجيلان يعملان معًا، فإن ضبط المفتاحين على القيمة نفسها يمنع ظهور خدمات دون بيئة.
2. مكان معالجة بيانات الرصد. يمكن أن ترسل التطبيقات بياناتها إلى بوابة Collector مركزية تشغّلونها، أو إلى أداة (Agent) على كل خادم، أو مباشرة إلى المنصة. وهذا الاختيار يحدد أين يجري الإخفاء وأخذ العيّنات، وعدد المكوّنات التي يشغّلها فريقكم. وإن كانت الوجهة Datadog، فخيارات Datadog نفسه وطريقة المفاضلة بينها مقارَنة في إرسال بيانات OpenTelemetry إلى Datadog.
3. من يملك السياسات. هناك ثلاث سياسات تمسّ كل الفرق: ما البيانات الشخصية التي يجب ألا تغادر شبكتكم أبدًا، وكم من بيانات التتبّع يُحتفظ به، وما ميزانية الاستقبال. حدّدوا مالكًا لكل منها قبل تشغيل أول خدمة؛ وعادةً يكون فريق الأمن أو مسؤول حماية البيانات للإخفاء، وفريق المنصة لأخذ العيّنات، وفريق المنصة مع المالية للتكلفة.
روابط ذات صلةإرسال بيانات OpenTelemetry إلى Datadog
خطة اعتماد من أربع مراحل
يُعتمد OpenTelemetry خدمةً بعد خدمة، لا بتحويل واحد شامل. وتنتهي كل مرحلة أدناه بشيء يمكنكم التحقق منه.
- التأسيس. نشر بوابة الـ Collector، والاتفاق على معيار الوسوم، وقياس خدمة تجريبية واحدة لكل لغة. تكتمل حين: تصل بيانات كل خدمة تجريبية إلى المنصة بخدمة وبيئة وإصدار صحيحة، ويمكن تتبّع طلب واحد من أوله إلى آخره عبر لغتين.
- التوسّع. تطبيق القياس التلقائي على بقية الخدمات، وربط السجلات بالتتبعات، وبناء لوحة متابعة لكل خدمة. تكتمل حين: تعبر التتبعات الشاملة كل لغات البرمجة في البيئة.
- الحوكمة. وضع قواعد إخفاء البيانات الشخصية، وسياسات أخذ العيّنات، وأهداف مستوى الخدمة، ولوحات التكلفة. تكتمل حين: تُراجَع قواعد الإخفاء مع فريق الأمن ومسؤول حماية البيانات، ويكون حجم الاستقبال مقيسًا ويمكن توقّعه.
- التحسين. إضافة Spans ومقاييس مخصّصة لخطوات الأعمال المهمة، مثل الطلبات والمدفوعات والتسجيل. تكتمل حين: تجيب بيانات الرصد عن أسئلة الأعمال ("أي إصدار أبطأ إتمام الطلب؟")، لا عن الأسئلة التقنية وحدها.
وتعتمد مدة كل مرحلة على عدد الخدمات ولغات البرمجة ووتيرة الإصدارات؛ ونقدّرها بعد تقييم بيئتكم.
القياس التلقائي أولًا، والـ Spans اليدوية حيث تكون الأعمال
القياس التلقائي يجعل الخدمات تنتج تتبعات مفيدة بقليل من الشيفرة أو دونها: لا شيفرة إطلاقًا في Python وJava، وبضعة أسطر من إعدادات بدء التشغيل في .NET إن استخدمتم طريقة الحزم. أما سياق الأعمال، مثل وسيلة الدفع التي أخفقت أو حجم سلة المشتريات، فيحتاج إلى بضعة أسطر من الشيفرة.
| اللغة | كيف يُفعَّل القياس التلقائي | ما يجب الانتباه إليه |
|---|---|---|
| Python (FastAPI وFlask وrequests) | ثبّتوا توزيعة OpenTelemetry وشغّلوا التطبيق عبر أداة التشغيل opentelemetry-instrument؛ دون تغيير في الشيفرة | مع الخوادم التي تعمل بنموذج التفرّع المسبق (Pre-fork) مثل Gunicorn، ابدؤوا القياس بعد التفرّع أو استخدموا عمّال Uvicorn |
| .NET 8 (ASP.NET Core) | أضيفوا امتداد الاستضافة من OpenTelemetry، وOTLP exporter، وحزم القياس لـ ASP.NET Core وHttpClient ومقاييس وقت التشغيل، وسجّلوها في شيفرة بدء التطبيق. وهناك أيضًا خيار دون شيفرة يُثبَّت عبر سكربت | أبقوا كل حزم OpenTelemetry.* على الإصدار الفرعي نفسه |
| Java (Spring Boot) | أرفقوا OpenTelemetry Java agent عند بدء تشغيل JVM | ثبّتوا إصدار الـ agent في مسار البناء، ولا تستخدموا "latest" إلا في أول تجربة |
وتلتزم الثلاث بمتغيرات البيئة القياسية نفسها (OTEL_SERVICE_NAME وOTEL_RESOURCE_ATTRIBUTES وOTEL_EXPORTER_OTLP_ENDPOINT وغيرها)، فيمكن ضبط هوية كل خدمة ووجهتها مرة واحدة في قوالب النشر، مثل ملفات Kubernetes أو قيم Helm.
أين تستحق الـ Spans اليدوية الجهد: في رحلات العملاء القليلة التي تحمل الأعمال؛ ونحن نبدأ بأهم ثلاث منها. أضيفوا Spans لخطوات مثل "حساب الإجمالي" أو "تفويض الدفع"، وأرفقوا خصائص أعمال مثل مبلغ الطلب وعملته، ولا تضعوا بيانات شخصية خامًا في تلك الخصائص أبدًا.
نقاط الإخفاق الشائعة، وعلاجها
| العَرَض | السبب المرجّح | العلاج |
|---|---|---|
| تظهر خدمات دون بيئة أو إصدار | خصائص المورد (Resource Attributes) غير مضبوطة | اضبطوا OTEL_RESOURCE_ATTRIBUTES بمفتاح (أو مفتاحي) البيئة وservice.version |
| يظهر الطلب الواحد في صورة تتبعات منفصلة لكل خدمة | عدم تطابق في نقل السياق | استخدموا ناقلي السياق W3C tracecontext وbaggage في كل خدمة |
| السجلات غير مربوطة بالتتبعات | السجلات تغادر التطبيق خارج OpenTelemetry، دون معرّفات التتبّع | صدّروا السجلات عبر OTLP، أو أضيفوا trace_id وspan_id إلى صيغة السجل |
| الـ Collector يرفض البيانات تحت الضغط | ضغط على ذاكرة الـ Collector | أضيفوا نسخًا، أو ارفعوا حد الذاكرة، أو قلّلوا حجم الدفعات |
| مقاييس الخوادم تُحتسب مرتين | مكوّنان يجمعان مقاييس الخادم على العقدة نفسها | اختاروا مصدرًا واحدًا لمقاييس الخادم في كل عقدة |
هل OpenTelemetry الخيار المناسب لكم؟
يناسب غالبًا حين: تكون الخدمات مكتوبة بأكثر من لغة أو تملكها عدة فرق؛ أو تريدون الإبقاء على خيار تغيير منصة التحليل أو إضافة منصة أخرى؛ أو يجب إخفاء البيانات الشخصية بطريقة متسقة قبل أن تغادر بيانات الرصد شبكتكم.
تحقّقوا قبل الالتزام: الميزات التي تحصلون عليها من المنصة قد تعتمد على طريقة القياس. فـ Datadog مثلًا يذكر أن الميزات المتاحة تعتمد على إعداد OpenTelemetry الذي تختارونه، وأن استخدام OpenTelemetry API مع حزمة SDK الخاصة بـ Datadog يتيح ميزات Datadog أكثر مما تتيحه OpenTelemetry SDK وحدها. فراجعوا جدول توافق الميزات لدى المنصة مقابل الميزات التي لا غنى لكم عنها قبل اعتماد المعيار.
النضج: تخرّج المشروع في CNCF في مايو 2026، لكن المكوّنات وحزم SDK للغات المختلفة تتقدم بسرعات متفاوتة. وينشر المشروع حالة كل مكوّن؛ فراجعوها للغات التي تستخدمونها.
كيف تعمل إنتركي مع OpenTelemetry
إنتركي شريك رسمي لـ Datadog، وتقيّم منصة Datadog وتنفّذها وتشغّلها للمنشآت في السعودية، بفريق تنفيذ في الرياض. ويغطي التصميم المرجعي لدينا لـ OpenTelemetry خدمات .NET 8 وJava (Spring Boot) وPython (FastAPI وFlask) التي ترسل التتبعات والمقاييس والسجلات عبر Collector تُدار حوكمته مركزيًا إلى Datadog.
وفي أي مشروع OpenTelemetry نعمل مع فرقكم وفق قائمة تحقق ثابتة:
- معيار وسوم معتمد (الخدمة، والبيئة، والإصدار، والفريق)؛
- بوابة الـ Collector، مع حفظ مفتاح Datadog API في أداة إدارة الأسرار لديكم؛
- خدمة تجريبية واحدة لكل لغة، وتتبّع واحد يمرّ بأكثر من لغة، مُتحقَّق منه من أوله إلى آخره؛
- قواعد إخفاء البيانات الشخصية، تُراجَع مع فريق الأمن ومسؤول حماية البيانات لديكم؛
- سياسة لأخذ العيّنات لكل بيئة، مع قياس حجم الاستقبال؛
- لوحة متابعة وتنبيهات لسلامة المسار؛
- Spans ومقاييس أعمال لأهم ثلاث رحلات عملاء لديكم.
والتفاصيل التقنية في جانب Datadog، ومنها مسارات الاستقبال التي يوثّقها Datadog وطريقة التحقق من المسار مرحلةً مرحلة، موجودة في إرسال بيانات OpenTelemetry إلى Datadog.
روابط ذات صلةإرسال بيانات OpenTelemetry إلى Datadog
مسرد المصطلحات
- التتبّع (Trace):
- الرحلة الكاملة لطلب واحد عبر الخدمات، مثل سجل تتبّع الطرد.
- Span:
- خطوة واحدة في تلك الرحلة، مثل استدعاء خدمة واحد أو استعلام قاعدة بيانات واحد.
- المقياس (Metric):
- رقم يُقاس عبر الزمن، مثل عدد الطلبات في الثانية.
- السجل (Log):
- قيد لحدث مع وقت حدوثه.
- OTLP:
- بروتوكول OpenTelemetry، الصيغة القياسية لإرسال بيانات الرصد.
- Collector:
- الخدمة التي تستقبل بيانات الرصد وتنقّيها وتأخذ منها العيّنات وتمرّرها.
- خصائص المورد (Resource Attributes):
- وسوم تصف مصدر البيانات: الخدمة، والإصدار، والبيئة، والخادم.
- نقل السياق (Context Propagation):
- تمرير معرّف التتبّع بين الخدمات حتى يبقى الطلب الواحد تتبّعًا واحدًا.
- أخذ العيّنات (Sampling):
- الاحتفاظ بمجموعة ممثّلة من التتبعات للتحكم في الحجم والتكلفة.
أسئلة يطرحها العملاء
هل OpenTelemetry مجاني؟
المشروع مفتوح المصدر وتشرف عليه CNCF. أما التكاليف فهي الوقت الهندسي اللازم للقياس وتشغيل المسار، والمنصة التي تخزّن البيانات وتحلّلها.
هل يحلّ OpenTelemetry محل Datadog؟
لا. OpenTelemetry ليس منصة رصد تخزّن البيانات وتحلّلها: هو ينتج بيانات الرصد وينقلها. أما Datadog فيستقبل بيانات OpenTelemetry ويوفّر التخزين والتحليل ولوحات المتابعة والتنبيهات.
هل يلزمنا تغيير شيفرة التطبيقات؟
ليس للبدء. القياس التلقائي يلتقط أطر العمل الشائعة دون المساس بمنطق الأعمال: لا شيفرة إطلاقًا في Python وJava، وبضعة أسطر من إعدادات بدء التشغيل في .NET (أو لا شيء مع خيارها دون شيفرة). أما سياق الأعمال، مثل قيم الطلبات أو نتائج المدفوعات، فيحتاج إلى إضافات يدوية صغيرة.
نشغّل Datadog Agent حاليًا. هل يلزمنا إزالته؟
لا. المسار الذي يوصي به Datadog يجمع بين الـ Agent الخاص به وOpenTelemetry Collector مدمج فيه، ويستطيع الـ Agent أيضًا استقبال بيانات OTLP مباشرة. والخيارات مقارَنة في إرسال بيانات OpenTelemetry إلى Datadog.
هل يساعد OpenTelemetry على إبقاء البيانات الشخصية داخل شبكتنا؟
يمنحكم مكانًا لفرض ذلك. فالـ Collector يعمل داخل بنيتكم التحتية، فيمكن تطبيق قواعد الإخفاء قبل تصدير بيانات الرصد. أما تصميم هذه القواعد واختبارها فمشروح في إبعاد البيانات الشخصية عن السجلات والتتبعات.
روابط ذات صلةإبعاد البيانات الشخصية عن السجلات والتتبعات
هل يوجد موقع لـ Datadog في السعودية؟
لا، حتى نوفمبر 2026: مواقع Datadog المنشورة في الولايات المتحدة وألمانيا واليابان وأستراليا والمملكة المتحدة. وما يعنيه ذلك لبياناتكم مشروح في إقامة بيانات الرصد في المملكة.
روابط ذات صلةإقامة بيانات الرصد في المملكة
التالي
أدلة ذات صلة
الخطوة التالية
خطّطوا لاعتماد OpenTelemetry
أخبرونا بلغات البرمجة والمنصات التي تعمل عليها خدماتكم، وعددها التقريبي، وإلى أين تذهب بيانات الرصد اليوم. يردّ عليكم أحد المختصين في فريق الرياض في أيام العمل السعودية، بالعربية أو الإنجليزية.
أو مباشرةً
+966-11-2180999 [email protected]أبراج التعاونية، البرج الشمالي، الطابق السابع، طريق الملك فهد، العليا، ص.ب. ٥٦٨٣٥، الرياض ١١٥٦٤، المملكة العربية السعودية