Collector သည် application များထံမှ တယ်လီမက်ထရီကို လက်ခံပြီး သတ်မှတ်ထားသော backend သို့ သီးခြား အပြင်ထွက် ချိတ်ဆက်မှု ပြုလုပ်သည်။ proxy ကို ထို အပြင်ထွက် 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]

ဤအပိုင်းကို လက်ရှိ configuration ထဲသို့ ပေါင်းစည်းပါ။ otlp လက်ခံကိရိယာကို ရှိပြီးသား သတ်မှတ်ထားပြီးဟု ယူဆပြီး deployment လိုအပ်သော processors နှင့် အခြား pipeline သတ်မှတ်ချက်များကို ထိန်းသိမ်းထားသည်။ သက်ဆိုင်ရာ pipeline မှ ရည်ညွှန်းခြင်းမရှိဘဲ ထုတ်ပို့ကိရိယာကို သတ်မှတ်ခြင်းသည် ၎င်းမှတစ်ဆင့် ဒေတာ မပို့ပါ။

endpoint သည် တယ်လီမက်ထရီ backend ၏ အခြေခံ URL အဖြစ် ဆက်ရှိသည်။ OTLP HTTP ထုတ်ပို့ကိရိယာသည် signal လမ်းကြောင်းကို ထည့်သည်၊ ဥပမာ /v1/traces၊ signal အတွက် သီးသန့် endpoint က အစားထိုးမထားလျှင်။ proxy_url သည် ကြားခံကို ဖော်ပြသည်။ အရေးကြီးမှုမရှိသော၊ အများသိသော စမ်းသပ် backend အတွက်၊ အများသုံး proxy လမ်းကြောင်းကို ခွင့်ပြုပါက HTTP proxy စာရင်းမှ လိပ်စာဖြင့် ထို URL ကို ဖြည့်နိုင်သည်။ backend ၏ အမှန်တကယ် host နှင့် port သို့ ရောက်ရှိမှုကို အတည်ပြုပါ။

လက်ရှိ upstream စာရွက်စာတမ်းများက ဤအစိတ်အပိုင်းကို otlp_http ဟု ခေါ်ပြီး otlphttp ကို ခေတ်မမီတော့သော အမည်တူအဖြစ် ဖော်ပြသည်။ ရှေးကျသော distribution များတွင် ယခင်အစိတ်အပိုင်းအမည်ကို သုံးနိုင်သည်။ ထုတ်ပို့ကိရိယာ သတ်မှတ်ချက်နှင့် pipeline ရည်ညွှန်းချက် နှစ်ခုလုံးကို တပ်ဆင်ထားသော distribution နှင့် ကိုက်ညီအောင် ထားပါ။

ဤသည် HTTP client configuration ဖြစ်သည်။ OTLP gRPC ထုတ်ပို့ကိရိယာတွင် အခြား သယ်ယူမှုရှိပြီး application ၏ ကိုယ်ပိုင် proxy ပတ်ဝန်းကျင်သည် Collector ၏ container သို့မဟုတ် service process ထဲသို့ အလိုအလျောက် မဝင်ပါ။ အလားတူပင် လက်ခံကိရိယာကို သတ်မှတ်ခြင်းသည် အဝင်လမ်းကြောင်း သွားလာမှုနှင့် သက်ဆိုင်ပြီး ဤ backend ချိတ်ဆက်မှုနှင့် မသက်ဆိုင်ပါ။

backend ၏ TLS စစ်ဆေးမှုနှင့် လိုအပ်သော service အထောက်အထား စစ်ဆေးမှုကို ထိန်းသိမ်းပါ။ proxy ၏ 407 နှင့် backend ၏ ငြင်းပယ်မှုသည် မတူညီသော အကောင့်များနှင့် အဆင့်များကို ညွှန်ပြသည်။

ဆက်စပ်ဆောင်းပါးများ