Skip to main content
عادةً ما يعني ترحيل منصة observability أكثر من مجرد تغيير مكان تخزين البيانات. فقد تكون وكلاء Datadog وSDKs منشورة بالفعل عبر آلاف التطبيقات والمضيفين والآلات الافتراضية وكبسولات Kubernetes. وإعادة تجهيز كل ذلك بـ instrumentation جديدة قبل أن تتمكن حتى من تقييم backend آخر تجعل الترحيل مشروعًا كبيرًا قبل أن يقدّم أي قيمة فعلية. إن مستقبِل Datadog المضمَّن في توزيعة ClickStack من مجمّع OpenTelemetry ‏(OTel) يزيل هذه الكلفة الأولية. وتواصل وكلاء Datadog وSDKs الحالية لديك العمل من دون أي تغيير. وبدلًا من إرسال بيانات القياس عن بُعد إلى Datadog، توجّهها إلى المستقبِل، الذي يترجم حمولات الأصلية الخاصة بـ Datadog للسجلات وtrace وMetric إلى نموذج بيانات OpenTelemetry، ثم يمرّرها عبر مسار المجمّع القياسي إلى ClickStack. ولأن المستقبِل يعمل داخل مسار المجمّع عادي، يمكنك استخدامه من أجل:
  • تقييم ClickStack إلى جانب Datadog من دون المساس بشيفرة التطبيق، باستخدام الوكلاء الحاليين لديك لإرسال بيانات القياس عن بُعد نفسها إلى كلتا المنصتين.
  • تسهيل عملية الترحيل، بالانتقال إلى ClickStack مع الإبقاء على طبقة collection الحالية لديك كما هي، واعتماد instrumentation في OpenTelemetry تدريجيًا.
  • تشغيل كلتا الحزمتين بالتوازي على المدى الطويل، واستخدام كل منصة فيما تجيده على أفضل وجه.

لماذا تُشغِّل ClickStack إلى جانب Datadog

بالنسبة إلى معظم الفرق، يكون الدافع لنقل بيانات الأوبزرفابيليتي خارج Datadog هو التكلفة. إذ تزداد أحجام السجلات والتتبعات مع توسّع التطبيقات وإضافة المزيد من الخدمات إليها، فتجد الفرق نفسها أمام خيارين: إما زيادة الإنفاق أو الاحتفاظ بقدر أقل من بيانات القياس عن بُعد التي تُنتجها. ثم إن ضوابط التكلفة هذه تحدّ مما يمكنكم رؤيته أثناء التحقيق: فالتتبعات المأخوذة بالعيّنة، والسجلات غير المفهرسة، والمقاييس المجمّعة، وفترات الاحتفاظ القصيرة، كلها تقلّل من السياق المتاح عندما تكونون في أمسّ الحاجة إليه. بُني ClickStack على ClickHouse، الذي يمكن أن يكون، في أعباء عمل السجلات والتتبّع الكبيرة، أكثر كفاءة من Datadog من حيث التكلفة بأكثر من 100 مرة. وهذا الفارق في اقتصاديات التخزين هو ما يجعل تشغيل ClickStack إلى جانب Datadog أمرًا مجديًا:
  • فترات احتفاظ أطول. اضبط مدة الاحتفاظ بما يناسب احتياجاتك التشغيلية بدلًا من ميزانيتك، واحتفظ بالأحداث التي قد تحتاج إليها بعد أسابيع أو حتى أشهر.
  • بيانات كاملة الدقة. خزّن كل سجل وكل تتبّع من دون أخذ عينات، بحيث تُجرى التحقيقات على بيانات كاملة بدلًا من مجموعة فرعية.
  • من دون حدود لمعدل API. استعلم عن بيانات القياس عن بُعد لديك كما لو كانت قاعدة بيانات، بدلًا من الوصول إليها عبر واجهة برمجة تطبيقات خاضعة للقياس، ومن دون تقييد للمعدل على مستوى كل استعلام أو كل نقطة نهاية.
  • وصول كامل إلى SQL. حلّل السجلات والمقاييس والتتبعات باستخدام SQL، واربطها ببيانات الأعمال أو بيانات البنية التحتية الموجودة أصلًا في ClickHouse.
  • أعباء العمل المعتمدة على الوكلاء. أتح بيانات القياس عن بُعد لديك لوكلاء الذكاء الاصطناعي عبر ClickStack MCP server، وشغّل عددًا غير محدود من الاستعلامات التحليلية مباشرةً على ClickHouse.
وتكون بيانات القياس عن بُعد كاملة الدقة ذات قيمة خاصة في التحقيقات المعتمدة على الوكلاء. فلا يمكن للوكيل أن يستدل على حدث جرى التخلّص منه قبل بدء التحقيق، كما أنه يحتاج إلى سجلّ تاريخي كافٍ لمقارنة الحادث الحالي بالإخفاقات السابقة، والتغيّرات السلوكية، والأنماط الممتدة على فترات أطول.

كيف يعمل مستقبِل Datadog

في عملية نشر OpenTelemetry نموذجية، تُرسَل بيانات القياس عن بُعد إلى مجمّع OpenTelemetry قبل أن تصل إلى النظام الخلفي. يستقبل المجمّع البيانات من المجمّعات العاملة في وضع agent ومن OpenTelemetry SDKs التي تُستخدَم لتهيئة التطبيقات، ويطبّق أي عمليات تصفية أو تحويل، ويجمع الأحداث في دفعات، ثم يصدّرها إلى الوجهة المستهدفة. يضيف مستقبِل Datadog مُدخلاً آخر إلى هذه المعمارية. فهو يوفّر نقطة نهاية تفهم البروتوكولات التي تستخدمها عوامل Datadog وSDKs الخاصة بها، ويحوّل حمولات Datadog الواردة إلى نموذج بيانات OpenTelemetry. ومن هناك تمر عبر مسار المجمّع المعتاد مثلها مثل أي بيانات قياس عن بُعد أخرى. تُعاد ببساطة تهيئة عوامل Datadog الحالية لإرسال السجلات وآثار التتبّع إلى المستقبِل الذي يعمل على مجمّع ClickStack. وتحتفظ التطبيقات بـ Datadog SDKs الحالية، كما تبقى العوامل المنشورة بالفعل عبر بنيتك التحتية في مكانها. ولأن مسار المجمّع يمكنه استخدام أكثر من مُصدِّر واحد، يمكن إرسال بيانات القياس عن بُعد نفسها إلى Datadog وClickStack في الوقت نفسه. وهذا ما يجعل التقييم جنبًا إلى جنب والتشغيل المتوازي على المدى الطويل ممكنين: إذ تقارن بين المنصتين باستخدام بيانات متطابقة، ثم تقرر ما إذا كنت ستُجري الترحيل.

ما الذي يتعامل معه المستقبِل

يحوّل المستقبِل حمولات Datadog إلى تمثيلها الصحيح في OpenTelemetry، بحيث يتمكن ClickStack من تفسير البيانات وربطها والاستعلام عنها من دون أي منطق خاص بـ Datadog:
  • سجلات السجل. تُحوَّل الطوابع الزمنية في Datadog من المللي ثانية إلى النانوثانية، وتُستخدم لملء حقول الطابع الزمني ووقت الرصد وbody ودرجة الخطورة في OpenTelemetry، بحيث لا تعود السجلات تظهر عند حقبة Unix.
  • سمات المورد ودرجة الخطورة. تُطابَق حالات Datadog مثل info وwarn وerror مع SeverityNumber وSeverityText المقابلين في OpenTelemetry. كما تُرقَّى أسماء المضيفين، وأسماء الخدمات، والبيئات، والوسوم المعروفة الخاصة بالحاويات والسحابة وKubernetes إلى سمات مورد قياسية.
  • الربط بين التتبّع والسجلات. تملأ الحقول dd.trace_id وdd.span_id معرّفات التتبّع وspan في OpenTelemetry، ويعيد المستقبِل بناء معرّفات التتبّع الكاملة ذات 128 بت من التمثيل المجزأ الخاص بـ Datadog. وهذا السلوك مفعّل افتراضيًا، ويتيح للسجلات ووحدات span الواردة من Datadog أن ترتبط بالخدمات التي جرى instrument لها باستخدام OpenTelemetry.
  • سجلات JSON المهيكلة. ينفّذ الخيار decode_json_message، المفعّل افتراضيًا، معالجة JSON التي تحدث عادةً في backend الخاص بـ Datadog، مع استخراج body والطابع الزمني ودرجة الخطورة ومعرّفات التتبّع وحقول المورد وبقية السمات.
  • التوافق مع agents الحالية. يضغط Datadog Agent 7.59 والإصدارات الأحدث حمولات HTTP باستخدام Zstandard افتراضيًا. ويدعم المستقبِل Zstandard إلى جانب gzip، لذلك يمكن للـ agents الحالية الاتصال من دون رفض حمولاتها.
هذه التغييرات مضمنة في توزيعة ClickStack collector ومُعدّة تلقائيًا، وهي متاحة أيضًا في مشروع OpenTelemetry Collector Contrib.

تمكين مستقبِل Datadog

يتضمن توزيع ClickStack لمجمّع OpenTelemetry مستقبِل Datadog، وهو يستمع على المنفذ 8126. ويكون هذا المستقبِل معطّلًا افتراضيًا، ويُفعَّل باستخدام متغير البيئة ENABLE_DATADOG_RECEIVER. بمجرد تمكينه، وجّه Datadog agent إلى هذا المستقبِل واجرِ مصادقته باستخدام مفتاح إدخال إلى ClickStack. ويعتمد مصدر هذا المفتاح على طريقة النشر لديك: مع Managed ClickStack تشغّل جامعًا مستقلًا وتضبط المفتاح بنفسك عند بدء التشغيل، بينما مع Open Source ClickStack يُنشأ المفتاح تلقائيًا لك وتنسخه من واجهة ClickStack ‏(HyperDX). حدّد طريقة النشر الخاصة بك أدناه.
باستخدام Managed ClickStack، يمكنك نشر ClickStack collector مستقل يقوم باستيعاب البيانات إلى خدمة ClickHouse Cloud الخاصة بك. ويمكنك تأمين الـ collector عند بدء التشغيل باستخدام رمز مصادقة تختاره، ثم إعادة استخدام هذا الرمز نفسه بوصفه مفتاح API لـ Datadog agent.
1

انشر collector مع تفعيل receiver

ClickStack OpenTelemetry collector مقابل OpenTelemetry collector القياسييكون Datadog receiver مضمّنًا ومُهيّأً مسبقًا في توزيع ClickStack الخاص بـ OpenTelemetry collector. وإذا كنت تفضّل استخدام توزيع OpenTelemetry Collector Contrib القياسي، فستحتاج إلى تهيئة الـ receiver بنفسك. وتُرسل جميع تغييراتنا وتحسيناتنا على الـ receiver إلى upstream، لذا فهي متاحة هناك أيضًا. وللاطلاع على خيارات التهيئة، راجع ملف README الخاص بـ Datadog receiver.
شغّل ClickStack collector المستقل مع توجيهه إلى خدمة ClickHouse Cloud الخاصة بك. فعّل Datadog receiver باستخدام ENABLE_DATADOG_RECEIVER=true، وافتح المنفذ 8126، وأمّن الاستيعاب عبر تعيين OTLP_AUTH_TOKEN من اختيارك:
أصبح الـ receiver متاحًا الآن على http://localhost:8126، والرمز الموجود في OTLP_AUTH_TOKEN هو المفتاح الذي تمرّره إلى Datadog agent. ولمزيد من التفاصيل حول تأمين الـ collector، بما في ذلك ما يعادله في Helm، راجع “تأمين الـ collector”.
2

هيّئ Datadog agent

حدّث configuration file الخاصة بالـ agent في /opt/datadog-agent/etc/datadog.yaml لإرسال السجلات والتتبعات والمقاييس إلى الـ receiver. استخدم قيمة OTLP_AUTH_TOKEN بوصفها مفتاح API، ووجّه كل destination إلى endpoint الخاصة بالـ receiver:
يقوم هذا الإعداد بما يلي:
  • يرسل المقاييس والتتبعات والسجلات إلى الـ receiver بدلًا من Datadog.
  • يعطّل v3 metrics intake، لأن ClickStack يدعم Datadog v2 metrics endpoint.
  • يوقف التحديثات عن بُعد والتهيئة عن بُعد، لأنهما يعتمدان على Datadog backend.
3

أعد تشغيل agent

أعد تشغيل Datadog agent لالتقاط الإعدادات الجديدة. على MacOS:
تتدفق بيانات telemetry من الـ agent الآن إلى ClickStack، حيث يمكنك استكشافها في HyperDX.

مثال عملي

يستخدم المثال التالي تطبيقًا تجريبيًا لعرض المسار الكامل من تطبيق جرى تزويده بأدوات الرصد، مرورًا بـ Datadog agent، وصولًا إلى ClickStack.
1

استنساخ التطبيق النموذجي وتشغيله

يستخدم هذا المثال تطبيق Hacker News التجريبي، والمزوّد بأدوات Datadog على الفرع datadog-instrumentation. استنسخ هذا الفرع:
اتبع التعليمات في README لتشغيل التطبيق.
2

تشغيل ClickStack مع تفعيل مستقبِل Datadog

شغّل صورة all-in-one مع تفعيل مستقبِل Datadog. هنا نربط receiver بمنفذ المضيف 18126 حتى لا يتعارض مع Datadog agent المحلي، الذي يستخدم أيضًا 8126:
يصبح receiver متاحًا على http://127.0.0.1:18126.
3

تثبيت Datadog agent وتهيئته

ثبّت Datadog agent. على MacOS:
حدّث /opt/datadog-agent/etc/datadog.yaml بحيث يشير إلى receiver على المنفذ 18126، مع استخدام مفتاح إدخال ClickStack الخاص بك كمفتاح API، ثم أعد تشغيل agent:
راجع تفعيل مستقبِل Datadog للاطلاع على تهيئة agent الكاملة ولمعرفة مكان العثور على مفتاح الإدخال الخاص بك.
4

استكشف بيانات القياس عن بُعد في ClickStack

افتح واجهة HyperDX على http://localhost:8080 واستكشف traces وlogs وmetrics التي جُمعت من Datadog agent.

ما الذي يمكنك ترحيله اليوم

يُعد مستقبِل Datadog مكوّناً من فئة alpha في مجمّع OpenTelemetry Contrib، ومصنَّفاً على أنه Experimental ضمن توزيعة ClickStack collector، لذلك يتطلب تفعيل feature flag. لقد خضع مستقبِل Datadog لاختبارات مكثفة مع أعباء عمل السجلات والتتبعات، ويُوصى به لتقييم ClickStack باستخدام هذه الإشارات. تعمل المقاييس أيضاً، لكنها لا تزال تحتاج إلى مزيد من الاختبار والتطوير. ويدعم مستقبِل Datadog حالياً نقاط نهاية استقبال المقاييس v1 وv2 الخاصة بـ Datadog، ويجب تهيئة agents التي تستخدم إصدارات أحدث من protocol صراحةً لإرسال المقاييس عبر endpoint مدعوم. في الوقت الحالي، يوفّر مستقبِل Datadog طريقة سريعة لتقييم ClickStack عندما تكون تطبيقاتك تستخدم بالفعل Datadog SDKs أو عندما تعمل بنيتك التحتية بواسطة Datadog agents. شغّل كلا المسارين بالتوازي، وتحقّق من كيفية تمثيل بياناتك والاستعلام عنها في ClickStack، ثم قرّر ما إذا كنت ستتابع ترحيلاً على نطاق أوسع. وإذا أظهر التقييم فوائد واضحة، فإن معمارية النظام نفسها تدعم ترحيلاً تدريجياً، مع الإبقاء على instrumentation الحالية الخاصة بـ Datadog كما هي بينما تنتقل الخدمات إلى OpenTelemetry بمرور الوقت.
آخر تعديل في ٢٣ يوليو ٢٠٢٦