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 از پیش تعریف شده است و processors موردنیاز استقرار و سایر تنظیمات خط لوله را حفظ می‌کند. تعریف یک صادرکننده بدون ارجاع به آن از خط لولهٔ مربوطه، داده‌ای از آن عبور نمی‌دهد.

endpoint همان نشانی پایهٔ بک‌اند تله‌متری می‌ماند. صادرکنندهٔ OTLP HTTP مسیر سیگنال، مانند /v1/traces، را اضافه می‌کند، مگر اینکه endpoint مخصوص همان سیگنال آن را جایگزین کند. proxy_url واسطه را مشخص می‌کند. برای بک‌اند آزمایشی غیرحساس که عمومی است و مسیر پروکسی عمومی را مجاز می‌کند، نشانی‌ای از فهرست پروکسی HTTP می‌تواند آن URL را پر کند؛ دسترسی به host و port واقعی بک‌اند را تأیید کنید.

مستندات فعلی بالادست این مؤلفه را otlp_http می‌نامد و otlphttp را نام مستعار منسوخ توصیف می‌کند. توزیع‌های قدیمی‌تر می‌توانند از نام قدیمی مؤلفه استفاده کنند؛ هم تعریف صادرکننده و هم ارجاع خط لوله را با توزیع نصب‌شده هماهنگ نگه دارید.

این پیکربندی کلاینت HTTP است. صادرکنندهٔ OTLP gRPC انتقال دیگری دارد و محیط پروکسی خود برنامه به‌طور خودکار وارد کانتینر یا فرایند سرویس Collector نمی‌شود. به همین ترتیب، پیکربندی گیرنده به ترافیک ورودی مربوط است، نه به این اتصال بک‌اند.

بازبینی TLS بک‌اند و احراز هویت سرویس موردنیاز را حفظ کنید. پاسخ 407 پروکسی و رد شدن توسط بک‌اند به حساب‌ها و مراحل متفاوت اشاره دارند.

مقالات مرتبط