إرسال OpenTelemetry إلى ClickStack باستخدام Odigos

يُعد Odigos مستوى تحكم لأدوات الرصد في Kubernetes والآلات الافتراضية، ويقوم بإضافة أدوات الرصد إلى التطبيقات من النواة باستخدام eBPF. ونظرًا لأن عملية الجمع تعمل داخل النواة، يبقى الحمل الإضافي على التطبيق منخفضًا مع الحفاظ على مستوى عالٍ من الرؤية. وتحصل على traces وmetrics وlogs وprofiles من OpenTelemetry بجودة مناسبة لبيئات production، من دون نشر agents جديدة ضمن application code أو انتظار ترقيات المكتبات عبر كل service.

هذه الطبقة من eBPF هي ما يجعل بيانات القياس عن بُعد العميقة والمتسقة ممكنة على نطاق واسع. ويمكن لـ Odigos تشغيل أدوات رصد أعمق أو إيقافها تلقائيًا عند الحاجة للمساعدة في Debug المشكلات أو استكشافها وإصلاحها:

• سياق على مستوى الشيفرة — attributes مرتبطة بالدوال وسلوك runtime
• حركة مرور HTTP — الطلبات والاستجابات عبر خدماتك
• أنظمة المراسلة — payloads والرسائل من Kafka وbrokers المشابهة
• الأخطاء بالتفصيل — stack traces عند حدوث الإخفاقات
• أدوات رصد مخصصة — وسّع نطاق التغطية حيث تتوقف auto-instrumentation من دون الحاجة إلى تغييرات في الشيفرة أو إعادة التشغيل

في الخلفية، ينشئ Odigos ويدير pipeline كاملة لـ OpenTelemetry لعنقودك: collectors تتوسع مع الحمل، وتوجيه إلى backends التي تختارها، ومنطق pipeline تتحكم فيه عبر واجهة المستخدم. حدّد sampling لإدارة الحجم، وإخفاء PII لمنع تصدير البيانات الحساسة، وقواعد OTTL من أجل filter أو transform أو enrich لبيانات القياس عن بُعد قبل أن تغادر العنقود.

غالبًا ما يستغرق نشر OpenTelemetry عبر عدد كبير من الخدمات وقتًا طويلًا، ولا يوفّر سوى رؤية سطحية داخل التطبيقات. يتولى Odigos إضافة أدوات الرصد باستخدام eBPF للحصول على بيانات القياس عن بُعد أعمق، كما يدير عمليات المجمّع على Kubernetes؛ بينما يوفّر ClickStack تخزينًا مستندًا إلى ClickHouse وواجهة HyperDX للاستعلام عن بيانات القياس عن بُعد على نطاق واسع.

• أن يكون ClickStack مثبّتًا ويمكن الوصول إليه من عنقود Kubernetes لديك. راجع Getting started with open source ClickStack أو Getting started with managed ClickStack.
• نقطة نهاية OTLP HTTP الخاصة بـ ClickStack لديك (المنفذ 4318) وقيمة المصادقة التي سيمرّرها Odigos في ترويسة Authorization. عند استخدام ClickStack مفتوح المصدر، تكون هذه هي مفتاح API للاستيعاب من Team Settings → API Keys في HyperDX UI. وعند استخدام Managed ClickStack، يكون هذا هو OTLP_AUTH_TOKEN الذي تضبطه عند تشغيل ClickStack collector المستقل الخاص بك.
• عنقود Kubernetes (عُقد Linux بنواة 4.18 أو أحدث من أجل أدوات الرصد باستخدام eBPF)
• Helm وkubectl وبيانات اعتماد العنقود للتثبيت في مساحة الأسماء odigos-system
• رمز Odigos Enterprise المحلي — تواصل مع فريق Odigos للحصول على إمكانية الوصول

export ODIGOS_ONPREM_TOKEN="<your-enterprise-token>"

helm repo add odigos https://odigos-io.github.io/odigos/
helm repo update

helm upgrade --install odigos odigos/odigos \
  --namespace odigos-system \
  --create-namespace \
  --set onPremToken=$ODIGOS_ONPREM_TOKEN

kubectl get pods -n odigos-system

kubectl port-forward svc/ui -n odigos-system 3000:3000

إذا كنت تُصدِّر مباشرةً إلى ClickHouse باستخدام وجهة ClickHouse الأصلية في Odigos (بدلاً من OTLP HTTP إلى ClickStack)، ففعِّل مُطبِّع سجلّات HyperDX (HYPERDX_LOG_NORMALIZER: true). فهو يحلّل محتوى سجلّات JSON ويُوحِّد السمات لتحسين الاستعلام عنها في واجهة ClickStack.

عندما يمكن الوصول إلى ClickHouse مباشرةً من الـ cluster لديك، يمكنك استخدام وجهة ClickHouse الأصلية في Odigos بدلًا من OTLP HTTP. اضبط endpoint الخاصة بـ ClickHouse واسم قاعدة البيانات وخيارات المخطط في واجهة المستخدم أو باستخدام ملف manifest — راجع Odigos ClickHouse destination.

• مخطط الإنتاج: عيّن CLICKHOUSE_CREATE_SCHEME إلى false وطبّق تعليمات DDL الخاصة بك.
• TLS / المصادقة: استخدم CLICKHOUSE_TLS_ENABLED وCLICKHOUSE_USERNAME وKubernetes Secret لكلمة المرور.

OTLP HTTP (ClickStack)

apiVersion: odigos.io/v1alpha1
kind: Destination
metadata:
  name: clickstack
  namespace: odigos-system
spec:
  type: otlphttp
  destinationName: otlphttp
  signals:
    - TRACES
    - METRICS
    - LOGS
  data:
    OTLP_HTTP_ENDPOINT: 'http://clickstack.example.com:4318'
    # API ingestion key for open source ClickStack, or OTLP_AUTH_TOKEN for Managed ClickStack
    OTLP_HTTP_HEADERS: 'Authorization:<YOUR_AUTHORIZATION_VALUE>'

ClickHouse (direct)

apiVersion: odigos.io/v1alpha1
kind: Destination
metadata:
  name: clickhouse
  namespace: odigos-system
spec:
  type: clickhouse
  destinationName: clickhouse
  signals:
    - TRACES
    - METRICS
    - LOGS
  data:
    CLICKHOUSE_ENDPOINT: 'http://clickstack.example.com:8123'
    CLICKHOUSE_DATABASE_NAME: 'otel'
    CLICKHOUSE_CREATE_SCHEME: 'true'

طبّق ملف manifest:

kubectl apply -f destination.yaml

يقوم Odigos VM Agent بإضافة إمكانات جمع بيانات الرصد إلى عمليات Linux وخدمات systemd و/أو حاويات docker باستخدام eBPF. ويُصدِّر بيانات القياس عن بُعد إلى الوجهات نفسها التي يستخدمها Odigos القائم على العنقود، بما في ذلك ClickStack عبر OTLP HTTP.

يُعد VM Agent جزءًا من Odigos Pro. راجع نظرة عامة على VM Agent للاطلاع على الإعداد والمصادر وتهيئة الوجهة.

Odigos Central هي طبقة تحكم مركزية لإدارة instrumentation والوجهات وتهيئة مسارات المعالجة عبر عدة Kubernetes clusters من واجهة المستخدم واحدة، بدلًا من تهيئة كل cluster على حدة.

يتوفر Odigos Central في Odigos Enterprise. راجع Central overview للتعرّف على إدارة العناقيد المتعددة وSSO وقواعد sampling الموحّدة.

• استكشف التتبعات عبر الخدمات التي جرى تزويدها بأدوات الرصد في ClickStack
• أنشئ لوحات معلومات لمقاييس Odigos المُصدَّرة
• اضبط مخطط ClickHouse وTTL بما يناسب سياسات الاحتفاظ وأنماط الاستعلامات لديك

• تثبيت Odigos Enterprise
• وجهة ClickHouse في Odigos
• نظرة عامة على VM Agent في Odigos
• نظرة عامة على Odigos Central
• توقّف عن التخمين في بيئة الإنتاج: تتبّع كامل التفاصيل على نطاق واسع باستخدام ClickHouse وOdigos
• بدء الاستخدام مع ClickStack مفتوح المصدر