يستقبل Collector البيانات القياسية من التطبيقات، ثم ينشئ اتصالًا صادرًا منفصلًا بالواجهة الخلفية المهيأة لديه. ضع الوسيط على مُصدِّر HTTP الصادر ذلك:

exporters:
  otlp_http/proxied:
    endpoint: https://telemetry.example:4318
    proxy_url: http://proxy.example:8080

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlp_http/proxied]

ادمج هذا المقطع في التهيئة القائمة. يفترض أن مستقبل otlp معرَّف مسبقًا، ويحافظ على المعالجات المطلوبة في النشر وعلى بقية إعدادات المسار. تعريف مُصدِّر دون الإشارة إليه من المسار المعني لا يرسل أي بيانات عبره.

يبقى endpoint عنوان URL الأساسي للواجهة الخلفية. ويضيف مُصدِّر OTLP HTTP مسار الإشارة، مثل /v1/traces، ما لم يستبدله endpoint خاص بتلك الإشارة. ويحدد proxy_url الوسيط. أما الواجهة الخلفية التجريبية غير الحساسة، المكشوفة للعامة والتي تسمح بمسار عبر وسيط عام، فيمكن ملء ذلك العنوان بمدخل من قائمة وسطاء HTTP؛ تحقق من الوصول إلى المضيف والمنفذ الفعليين للواجهة الخلفية.

تُسمّي وثائق المنبع الحالية هذا المكوّن otlp_http، وتصف otlphttp بأنه اسم مستعار مهجور. ويمكن للتوزيعات الأقدم استخدام اسم المكوّن القديم؛ حافظ على اتساق تعريف المُصدِّر وإشارة المسار مع التوزيعة المثبَّتة.

هذه تهيئة عميل HTTP. فمُصدِّر OTLP gRPC يستخدم نقلًا آخر، كما أن بيئة الوسيط الخاصة بالتطبيق لا تدخل تلقائيًا إلى حاوية Collector أو عملية الخدمة. وبالمثل، فإن تهيئة المستقبل تعالج حركة المرور الواردة لا اتصال الواجهة الخلفية هذا.

احتفظ بتحقق TLS الخاص بالواجهة الخلفية وبمصادقة الخدمة المطلوبة. فالاستجابة 407 من الوسيط ورفض الواجهة الخلفية يشيران إلى حسابين ومرحلتين مختلفتين.

مقالات ذات صلة