دليل تنفيذ Datadog · OpenTelemetry
إرسال بيانات OpenTelemetry إلى Datadog: اختاروا مسار الاستقبال، ثم اضبطوا حوكمته
يستقبل Datadog تتبعات OpenTelemetry ومقاييسه وسجلاته عبر Datadog Agent (مع OpenTelemetry Collector المدمج فيه، أو باستقبال OTLP مباشرة)، أو عبر OpenTelemetry Collector تشغّلونه بأنفسكم، أو مباشرة عبر OTLP حيث لا يمكن تشغيل أيٍّ منهما. والمسار الذي تختارونه يحدد ميزات Datadog التي تحصلون عليها، ومكان الإخفاء وأخذ العيّنات. يقارن هذا الدليل بين المسارات وفق وثائق Datadog الحالية، ويعرض مسار البوابة المحوكم الذي تستخدمه إنتركي في البيئات التي تضم خدمات بعدة لغات برمجة.
نُشر في 11 دقيقة قراءة
الخلاصة في أربع نقاط
- المسار الذي يوصي به Datadog: الـ Datadog Agent مع Datadog Distribution of OpenTelemetry (DDOT) Collector.
- Collector خاص بكم: للفرق التي تريد إدارة المسار بنفسها، بما في ذلك أخذ العيّنات بعد اكتمال التتبّع (Tail-based Sampling) وتحويل البيانات. ولإعدادات الـ Collector الجديدة يوصي Datadog الآن بـ OTLP HTTP exporter الخاص به مع
span_metricsconnector؛ ويبقى Datadog Exporter وDatadog Connector الأقدم مدعومين. - الـ Agent مستقبِلًا لبيانات OTLP: ترسل التطبيقات بيانات OTLP إلى الـ Agent على المنفذ 4317 (gRPC) أو 4318 (HTTP)؛ واستقبال السجلات عبر OTLP معطّل افتراضيًا.
- شيفرة التطبيقات لا تتغير بين المسارات: الخدمات المقاسة بـ OpenTelemetry ترسل بيانات OTLP نفسها أيًّا كان المسار الذي يستقبلها.
مسارات الاستقبال التي يوثّقها Datadog
| المسار | لمن يقول Datadog إنه مناسب | أين تجري المعالجة | ما تتحققون منه قبل الاختيار |
|---|---|---|---|
| Datadog Agent مع DDOT Collector (توصية Datadog) | الفرق التي تريد حياد OpenTelemetry مع قدرات Datadog مثل Fleet Automation وUniversal Service Monitoring | داخل الـ Agent على كل خادم أو عقدة؛ وفي Kubernetes يوثّق Datadog أيضًا DDOT gateway، وهي خدمة Collector مركزية منفصلة لأخذ العيّنات بعد اكتمال التتبّع وللمعالجة المركزية | التوفّر لإصدار الـ Agent والمنصة لديكم؛ والمكوّنات المضمّنة في DDOT مقابل المعالِجات التي تحتاجها قواعدكم |
| OpenTelemetry Collector خاص بكم | الفرق التي تدير الـ Collector بنفسها؛ إعدادات مرنة، منها أخذ العيّنات بعد اكتمال التتبّع وتحويل البيانات | في طبقة Collector تشغّلونها، مثل بوابة في Kubernetes | يحتاج إلى توزيعة Collector Contrib، بالإصدار v0.154.0 أو أحدث وقت مراجعتنا؛ ولا يدعم بيئات التشغيل دون خوادم أو القائمة على المهام مثل ECS Fargate وEKS Fargate وAWS Lambda |
| Datadog Agent يستقبل OTLP | توجيه التطبيقات إلى الـ Agent بدل Collector | على كل خادم أو عقدة، داخل الـ Agent | التتبعات والمقاييس تحتاج إلى Agent بالإصدار 7.32.0 أو أحدث، والسجلات إلى 7.48.0 أو أحدث؛ واستقبال سجلات OTLP معطّل افتراضيًا "لتجنّب فواتير سجلات غير متوقعة"، ويجب تفعيله عن قصد |
| الاستقبال المباشر عبر OTLP | البيئات التي لا يمكن فيها تشغيل Agent أو Collector: بيئات دون خوادم، والمنصات المُدارة، والإعدادات شديدة التقييد في الموارد | في Datadog، باستثناء ما تقوم به حزمة SDK في كل تطبيق | لا Collector ولا Agent داخل شبكتكم، فلا إخفاء مركزيًا ولا أخذ عيّنات بعد اكتمال التتبّع قبل أن تغادر البيانات بيئتكم؛ ولا ينطبق إلا ما يتاح على مستوى SDK، مثل أخذ العيّنات عند البداية (Head Sampling) |
الميزات تعتمد على المسار. يذكر Datadog أن الميزات المتاحة لكم تعتمد على هذه الاختيارات، وينشر جدولًا لتوافق الميزات. فراجعوه مقابل الميزات التي لا غنى لكم عنها، مثل عروض APM معيّنة أو مقاييس وقت التشغيل، قبل اعتماد المعيار.
كيف نختار بينها
ابدؤوا بثلاثة أسئلة:
- هل يعمل Datadog Agent في كل مكان أصلًا، وهل Datadog هو الوجهة الوحيدة؟ إن كان الجواب نعم، فابدؤوا بالـ Agent: DDOT إن أردتم مسارات Collector تُدار مع الـ Agent، أو الاستقبال المباشر لـ OTLP لأبسط تغيير.
- هل تحتاجون إلى إرسال البيانات نفسها إلى أكثر من وجهة، أو الاحتفاظ بالتتبعات الكاملة للأخطاء والطلبات البطيئة (أخذ العيّنات بعد اكتمال التتبّع)، أو إعادة كتابة الخصائص مركزيًا؟ إن كان الجواب نعم، فأنتم بحاجة إلى طبقة بوابة: Collector خاص بكم، أو DDOT gateway من Datadog في Kubernetes، بشرط أن تغطي مكوّناتها المضمّنة ما تحتاجونه، ومنها أدوات التصدير لأي وجهة غير Datadog.
- هل يجب إخفاء البيانات الشخصية داخل شبكتكم بالطريقة نفسها لكل لغات البرمجة؟ الإخفاء يحتاج إلى طبقة معالجة تتحكمون فيها داخل شبكتكم، مثل بوابة Collector خاصة بكم. وإن كنتم تنوون استخدام DDOT بدلًا منها، على كل عقدة أو بوابةً مركزية، فتأكدوا أنها تتضمن المعالِجات التي تحتاجها قواعد الإخفاء لديكم. أما الاستقبال المباشر وحده فلا يستطيع ذلك.
ويمكن الجمع بين المسارات: الـ Agent على كل عقدة لبيانات الخوادم والحاويات، وبوابة Collector لبيانات التطبيقات من كل اللغات.
المسار المرجعي لبيئة متعددة اللغات
في التصميم المرجعي لدى إنتركي، ترسل خدمات .NET 8 وJava (Spring Boot) وPython (FastAPI وFlask) بيانات OTLP عبر HTTP إلى بوابة Collector من ثلاث نسخ على الأقل، تتوسع بحسب حمل المعالج. وترسل البوابة التتبعات والمقاييس والسجلات إلى موقع Datadog المرتبط بحسابكم عبر HTTPS.
-
OTLP/HTTP :4318
خدمة Python خدمة .NET 8 خدمة Java -
بوابة Collector (3 نسخ أو أكثر، توسّع تلقائي)
حدّ الذاكرة اكتشاف المورد ترشيح فحوص السلامة إخفاء البيانات الشخصية (أخذ العيّنات بعد اكتمال التتبّع) التجميع في دفعات -
موقع Datadog
HTTPS
الترتيب مهم: حماية، ثم إثراء، ثم ترشيح، ثم إخفاء، ثم أخذ عيّنات، ثم تجميع.
داخل الـ Collector، الترتيب مهم:
| المرحلة | لماذا هي هنا |
|---|---|
| حدّ الذاكرة (Memory Limiter، أولًا دائمًا) | يرفض البيانات حين يقترب الـ Collector من حدّ ذاكرته، بدل أن يتعطل |
| اكتشاف المورد (Resource Detection) | يضيف بيانات الخادم والسحابة والحاوية |
| ترشيح فحوص السلامة | يحذف الـ Spans الناتجة عن فحوص الجاهزية والحيوية (Liveness/Readiness) قبل أن تكلّف شيئًا |
| إخفاء البيانات الشخصية | يحذف الخصائص ونصوص السجلات أو يجزّئها أو يُخفيها وفق سياستكم |
| أخذ العيّنات بعد اكتمال التتبّع (اختياري) | يحتفظ بالتتبعات الكاملة بحسب النتيجة، مثل الأخطاء والطلبات البطيئة |
| التجميع في دفعات (Batch، أخيرًا قبل التصدير) | يجمع البيانات لتقليل الاستدعاءات؛ وتشترط وثائق Datadog Exporter وجود معالج تجميع خارج بيئات التطوير، وتذكر حدودًا لحجم الاستقبال، وتُرفض الدفعات الكبيرة جدًا برمز HTTP 413 |
اقرأ المزيد
اختيار أداة التصدير في 2026. بُني التصميم المرجعي لدى إنتركي على Datadog Exporter وDatadog Connector. ولإعدادات الـ Collector الجديدة يوصي Datadog الآن بـ OTLP HTTP exporter الخاص به مع span_metrics connector، ويذكر أن إعدادات Exporter وConnector القائمة تبقى مدعومة ولا تحتاج إلى ترحيل. فالبوابات الجديدة ينبغي أن تتبع توصية Datadog الحالية، والقائمة التي تعمل جيدًا يمكن أن تبقى كما هي.
مقاييس خدمة دقيقة مع أخذ عيّنات من التتبعات
أخذ العيّنات يُبقي تخزين التتبعات في حدود معقولة من التكلفة، لكن مقاييس الطلبات والأخطاء وزمن الاستجابة يجب أن تعكس كل الحركة، لا العيّنة وحدها. والحل تقسيم العمل إلى مسارين:
- المسار A يستقبل كل الـ Spans، ويحسب مقاييس الطلبات والأخطاء وزمن الاستجابة من كل الحركة.
- المسار B يطبّق أخذ العيّنات، ولا يرسل إلى التخزين إلا التتبعات المحتفظ بها.
ومثال الـ Collector الذي ينشره Datadog نفسه يتبع المبدأ ذاته، إذ يفصل معالجة التتبعات عن أخذ العيّنات "حتى تُحسب مقاييس الـ Spans على كل التتبعات".
اقرأ المزيد
لأخذ العيّنات بعد اكتمال التتبّع كلفة. يجب أن تصل كل Spans التتبّع الواحد إلى نسخة الـ Collector نفسها، لذلك توجّه طبقة أولى من Collectors موازنة الحمل الـ Spans بحسب معرّف التتبّع إلى طبقة ثانية لأخذ العيّنات. ويشير مشروع OpenTelemetry إلى أن مكوّنات أخذ العيّنات بعد اكتمال التتبّع يجب أن تحتفظ بالحالة (Stateful)، وقد تحتاج إلى قدرة حوسبة كبيرة.
سياسة ابتدائية لأخذ العيّنات بحسب البيئة:
| البيئة | أخذ العيّنات عند البداية (في التطبيق) | أخذ العيّنات بعد اكتمال التتبّع (في الـ Collector) | السبب |
|---|---|---|---|
| التطوير / الاختبار | 100% | معطّل | رؤية كاملة أثناء التصحيح |
| UAT / التجهيز | 100% | الأخطاء + البطيئة + 25% أساسًا | اختبار أداء واقعي |
| الإنتاج، حجم عادي | 100% | الأخطاء + البطيئة + 10–20% أساسًا | الاحتفاظ بكل إخفاق؛ وتكلفة يمكن توقّعها |
| الإنتاج، حجم مرتفع جدًا | 25–50% | الأخطاء + البطيئة + 5–10% مما تبقى | تقليص على مرحلتين ليناسب الحجم |
أما السجلات والمقاييس فلها ضبط منفصل: احذفوا سجلات مستوى التصحيح (Debug) في الـ Collector، واستخدموا فهارس السجلات ومرشّحات الاستبعاد في Datadog لتحديد ما يُفهرَس ولأي مدة. والسجلات المستبعدة تُزال من الفهارس، لكنها تبقى قادرة على تغذية Live Tail وتوليد المقاييس والأرشفة. وجانب الفوترة مشروح في ما الذي يحدد فاتورة سجلات Datadog.
تفاصيل في البوابة تسبب أعطالًا في الإنتاج
- يجب أن يطابق موقع Datadog حسابكم. اضبطوا معامل الموقع (site) على الموقع الظاهر في رابط Datadog الذي تسجّلون الدخول منه. فالموقع الخاطئ يعيد الرمز 403 حتى مع مفتاح API صالح. ومواقع Datadog مستقلة بعضها عن بعض، ولا يمكن مشاركة البيانات بينها.
- قد يحصر gRPC الحركة في نسخة واحدة. يُبقي gRPC الاتصالات مفتوحة طويلًا، فقد ترسل خدمة Kubernetes من نوع ClusterIP العادية حركة عميل واحد إلى نسخة Collector واحدة. فضّلوا OTLP عبر HTTP من التطبيقات، أو استخدموا خدمة Headless مع موازنة الحمل من جهة العميل.
- الاتصال الصادر عبر خادم وسيط. إن كان الـ Collector يستقبل البيانات لكن الإرسال يفشل، فغالبًا ما يكون اتصال HTTPS الصادر إلى نقطة استقبال Datadog لموقعكم محجوبًا. اسمحوا به، واضبطوا
HTTPS_PROXYعلى الـ Collector حيث يمر الاتصال الصادر عبر خادم وسيط. - ثبّتوا الإصدارات. شغّلوا في الإنتاج صورة Collector وإصدار Java agent محددين، لا "latest".
- أبعدوا مفتاح API عن ملفات الإعدادات. احقنوه من أداة إدارة الأسرار لديكم أو من Kubernetes Secret.
- مصدر واحد لمقاييس الخادم في كل عقدة. تشغيل مقاييس الخادم في الـ Collector وفي Datadog Agent معًا يحتسبها مرتين.
التحقق من المسار، مرحلةً مرحلة
كل فحص يعزل مرحلة واحدة، فيدلّ الإخفاق على سببه.
-
الـ Collector سليم:
نقطة فحص السلامة تستجيب، والسجلات لا تُظهر أخطاء "refused" أو "denied".
-
مفتاح API والموقع صالحان:
نقطة التحقق من المفاتيح في Datadog لموقعكم تعيد أنه صالح.
-
الـ Collector يستقبل OTLP:
Span تجريبي واحد يُرسل إلى الـ Collector يعيد HTTP 200، ويظهر في Datadog APM باسم خدمة الاختبار.
-
يتحمّل الضغط:
اختبار حمل قصير بأداة توليد بيانات الرصد من OpenTelemetry ينتج تتبعات ومقاييس وسجلات بمعدل معروف.
-
البيانات تمر وتخرج:
مقاييس الـ Collector نفسه تُظهر ارتفاع الـ Spans المستقبَلة والمرسَلة معًا (انظروا الجدول أدناه).
-
المسارات كما ضُبطت:
صفحات التصحيح المدمجة في الـ Collector تعرض المسارات المتوقعة والـ Spans الحديثة.
-
جانب التطبيق موصول:
الخدمة تصل إلى الـ Collector، ومتغيرات
OTEL_مضبوطة فعلًا داخل الحاوية. -
Datadog يعيد البيانات:
استعلام من مسار CI لديكم يجد المقياس المخصّص المتوقع للخدمة والبيئة.
| مقياس الـ Collector | علامة السلامة |
|---|---|
| الـ Spans المستقبَلة | في ازدياد |
| الـ Spans المرفوضة | صفر؛ وغير الصفر يعني غالبًا أن حدّ الذاكرة بدأ يرفض البيانات |
| الـ Spans المرسَلة | في ازدياد، وقريبة من المستقبَلة، مطروحًا منها ما أُخذت منه العيّنات أو رُشّح |
| الإرسالات الفاشلة | صفر؛ وغير الصفر يشير إلى المفتاح أو الموقع أو الشبكة أو الخادم الوسيط |
| حجم طابور التصدير | منخفض ومستقر؛ والنمو المستمر يعني أن الاتصال الصادر إلى Datadog محجوب أو بطيء جدًا |
أرسلوا مقاييس الـ Collector هذه إلى Datadog أيضًا، وضعوا تنبيهًا على الإرسالات الفاشلة، حتى يكون المسار الذي يراقب خدماتكم مراقَبًا هو الآخر.
معالجة الأعطال
| العَرَض | السبب المرجّح | العلاج |
|---|---|---|
| لا شيء في Datadog، وسجلات الـ Collector تُظهر 403 | مفتاح API خاطئ أو موقع خاطئ | تحققوا من المفتاح، واضبطوا الموقع المطابق لرابط دخولكم إلى Datadog |
| الـ Collector يستقبل البيانات لكن الإرسالات الفاشلة تزداد | اتصال HTTPS الصادر محجوب بجدار ناري أو خادم وسيط | اسمحوا بالاتصال الصادر إلى نقطة استقبال Datadog لموقعكم، واضبطوا HTTPS_PROXY على الـ Collector |
| تظهر خدمات دون env أو version | خصائص المورد مفقودة | اضبطوا OTEL_RESOURCE_ATTRIBUTES بمفتاح (أو مفتاحي) البيئة وservice.version |
| تتبعات مجزأة إلى أجزاء منفصلة لكل خدمة | عدم تطابق في نقل السياق | استخدموا ناقلي السياق tracecontext وbaggage في كل خدمة |
| Spans يدوية مفقودة في .NET | ActivitySource غير مسجّل | سجّلوا اسم المصدر في إعدادات التتبّع |
| السجلات غير مربوطة بالتتبعات | السجلات تُرسل خارج OTLP دون معرّفات التتبّع | صدّروا السجلات عبر OTLP، أو أضيفوا trace_id وspan_id إلى صيغة السجل |
| أعداد الطلبات في APM تبدو منخفضة جدًا | المقاييس محسوبة بعد أخذ العيّنات | احسبوا المقاييس من كل الـ Spans قبل أخذ العيّنات |
| الـ Spans المرفوضة في ازدياد | ضغط على ذاكرة الـ Collector | أضيفوا نسخًا، أو ارفعوا حدّ الذاكرة، أو قلّلوا حجم الدفعات |
| مقاييس خوادم مكررة | الـ Collector والـ Agent يجمعان مقاييس الخادم معًا | اختاروا مصدرًا واحدًا لمقاييس الخادم في كل عقدة |
ما يغطيه مشروع نقل بيانات OpenTelemetry إلى Datadog
إنتركي شريك رسمي لـ Datadog، وتنفّذ منصة Datadog وتشغّلها من الرياض. وفي مشروع المسار نعمل مع فرقكم وفق قائمة التحقق هذه، ولكل بند مالك محدد من جهتكم:
| # | المهمة | المالك المعتاد |
|---|---|---|
| 1 | اعتماد معيار الوسوم (service وenv وversion وteam) | فريق المعمارية |
| 2 | حفظ مفتاح Datadog API في أداة إدارة الأسرار، وتأكيد موقع Datadog | فريق المنصة |
| 3 | نشر مسار الاستقبال المختار أعلاه (Agent مع DDOT، أو بوابة Collector، أو كليهما) | فريق المنصة |
| 4 | اجتياز فحوص التحقق من 1 إلى 6 | فريق المنصة |
| 5 | تجربة خدمة Python واحدة | فريق التطبيق |
| 6 | تجربة خدمة .NET واحدة | فريق التطبيق |
| 7 | تجربة خدمة Java واحدة | فريق التطبيق |
| 8 | التحقق من تتبّع موزّع واحد يمرّ بأكثر من لغة، من أوله إلى آخره | فريق المعمارية |
| 9 | مراجعة قواعد إخفاء البيانات الشخصية مع فريق الأمن ومسؤول حماية البيانات | فريق الأمن |
| 10 | الاتفاق على سياسة أخذ العيّنات لكل بيئة، وقياس حجم الاستقبال | فريق المنصة والمالية |
| 11 | بناء لوحة متابعة وتنبيهات لسلامة المسار | فريق SRE |
| 12 | إضافة Spans ومقاييس أعمال لأهم ثلاث رحلات عملاء | فرق التطبيقات |
هل OpenTelemetry جديد عليكم؟ ابدؤوا بـ OpenTelemetry: ما الذي يوحّده وكيف تعتمدونه.
أسئلة يطرحها العملاء
هل نحتاج إلى Datadog Agent إن كنا نشغّل Collector خاصًا بنا؟
لا. يوثّق Datadog أن الـ Collector يستطيع إرسال التتبعات والسجلات والمقاييس إلى Datadog دون الـ Agent. لكن بعض قدرات Datadog مرتبطة بالـ Agent وDDOT، فراجعوا جدول توافق الميزات لما تحتاجونه.
نستخدم Datadog Exporter حاليًا. هل يلزمنا الترحيل؟
يذكر Datadog أن Datadog Exporter وDatadog Connector يبقيان مدعومين، وأن الإعدادات القائمة لا تحتاج إلى ترحيل. ولإعدادات الـ Collector الجديدة يوصي بـ OTLP HTTP exporter مع span_metrics connector.
هل يرفع تفعيل سجلات OTLP فاتورتنا؟
قد يرفعها. ولهذا يأتي استقبال السجلات عبر OTLP معطّلًا افتراضيًا في الـ Agent. فقرّروا ما يُفهرَس من السجلات ولأي مدة قبل تفعيله: ما الذي يحدد فاتورة سجلات Datadog.
روابط ذات صلةما الذي يحدد فاتورة سجلات Datadog
هل يمكن إرسال بيانات الرصد نفسها إلى Datadog وإلى وجهة أخرى؟
نعم، إن كنتم تشغّلون Collector خاصًا بكم: فمسار واحد يستطيع التصدير إلى عدة وجهات، مثل Datadog وبحيرة بيانات داخلية، دون تغيير شيفرة التطبيقات.
هل يوجد موقع لـ Datadog في السعودية؟
لا، حتى نوفمبر 2026. مواقع Datadog في الولايات المتحدة وألمانيا واليابان وأستراليا والمملكة المتحدة. أما الإخفاء داخل شبكتكم قبل التصدير فمشروح في إبعاد البيانات الشخصية عن السجلات والتتبعات، والمسألة الأوسع لمكان البيانات في إقامة بيانات الرصد في المملكة.
روابط ذات صلةإبعاد البيانات الشخصية عن السجلات والتتبعاتإقامة بيانات الرصد في المملكة
التالي
أدلة ذات صلة
الخطوة التالية
راجعوا تصميم نقل بيانات OpenTelemetry إلى Datadog
أخبرونا بمسار الاستقبال الذي تستخدمونه أو تنظرون فيه، ولغات البرمجة والمنصات المعنية، وما الذي لا يعمل. يردّ عليكم أحد المختصين في فريق الرياض في أيام العمل السعودية، بالعربية أو الإنجليزية.
أو مباشرةً
+966-11-2180999 [email protected]أبراج التعاونية، البرج الشمالي، الطابق السابع، طريق الملك فهد، العليا، ص.ب. ٥٦٨٣٥، الرياض ١١٥٦٤، المملكة العربية السعودية