output {
  elasticsearch {
    id => "remote_cluster"
    hosts => ["https://es.example:9200"]
    proxy => "${ES_PROXY:}"
  }
}

დაამატეთ ეს არსებულ pipeline-ში. hosts რჩება კლასტერის HTTP საბოლოო წერტილად, ხოლო Logstash პროცესის ES_PROXY-ს შეუძლია მოგვაწოდოს დამტკიცებული URI, როგორიცაა http://proxy.example:8080.

Elasticsearch გამოსავლის მითითება მოითხოვს პროქსი URI-ს და ცარიელ სტრიქონს ცალსახად იღებს როგორც დაუყენებელს. გამოსახულების ცარიელი ნაგულისხმევი მნიშვნელობა ამ ეგზემპლარს საშუალებას აძლევს, არ ჰქონდეს მკაფიო პროქსი იქ, სადაც არ არის საჭირო.

შეინარჩუნეთ კლასტერის ავთენტიფიკაცია, ინდექსისა და TLS-ის პარამეტრები. საჯაროდ ხელმისაწვდომ კლასტერს შეუძლია HTTP კანდიდატის გამოყენება HTTP პროქსიების სიიდან მხოლოდ იმ მარშრუტზე, რომელიც უშვებს საჯარო შუამავლებს და სადაც პროქსის სერტიფიკატები არ არის კონფიგურირებული; დაადასტურეთ წვდომა კლასტერის რეალურ ჰოსტსა და პორტზე. სხვა გამოსავალს შეუძლია აირჩიოს სხვა პროქსი JVM-ში ყოველი Java HTTP კლიენტის შეცვლის გარეშე.

გარემოს ცვლადების ჩანაცვლება ხდება მაშინ, როცა Logstash pipeline-ს ტვირთავს. დააყენეთ ცვლადი რეალური სერვისის ან კონტეინერის გაშვებისას, და არა მოგვიანებით, უკავშირო ტერმინალში.

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