OpenTelemetry Collector: OTLP HTTP ექსპორტიორის პროქსის დაყენება

გამოიყენეთ OTLP HTTP ექსპორტიორის proxy_url პარამეტრი და მიაბით ეს ექსპორტიორი იმ მილსადენს, რომელიც რეალურად აგზავნის ტელემეტრიას.

Collector იღებს ტელემეტრიას აპლიკაციებისგან და შემდეგ ხსნის ცალკე გამავალ კავშირს კონფიგურირებულ backend-თან. პროქსი მოათავსეთ სწორედ ამ გამავალ 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 რჩება ტელემეტრიის backend-ის საბაზისო URL-ად. OTLP HTTP ექსპორტიორი ამატებს სიგნალის გზას, მაგალითად /v1/traces, თუ მას არ ჩაანაცვლებს სიგნალისთვის სპეციფიკური endpoint. proxy_url განსაზღვრავს შუამავალს. არასენსიტიური, საჯარო და საჯარო პროქსის მარშრუტის დამშვებელი სატესტო backend-ისთვის ამ URL-ის შესავსებად შეიძლება გამოვიყენოთ მისამართი HTTP პროქსების სიიდან; დაადასტურეთ წვდომა backend-ის რეალურ host-სა და port-ზე.

მიმდინარე upstream დოკუმენტაცია ამ კომპონენტს otlp_http-ს უწოდებს, ხოლო otlphttp-ს მოძველებულ ფსევდონიმად აღწერს. ძველ დისტრიბუციებს შეუძლიათ ძველი კომპონენტის სახელის გამოყენება; ექსპორტიორის განსაზღვრება და მილსადენის მითითება დაათანხმეთ დაყენებულ დისტრიბუციას.

ეს HTTP კლიენტის კონფიგურაციაა. OTLP gRPC ექსპორტიორს სხვა ტრანსპორტი აქვს და აპლიკაციის საკუთარი პროქსი გარემო ავტომატურად არ შედის Collector-ის კონტეინერში ან სერვისის პროცესში. ანალოგიურად, მიმღების კონფიგურაცია შემომავალ ტრაფიკს ეხება და არა ამ backend კავშირს.

შეინარჩუნეთ backend-ის TLS შემოწმება და საჭირო სერვისის ავთენტიფიკაცია. პროქსის 407 და backend-ის უარი სხვადასხვა ანგარიშსა და ეტაპზე მიუთითებს.

დაკავშირებული სტატიები