Arka uç sunucularında yük dengeleme

Apigee Edge belgelerini görüntülüyorsunuz.
Apigee X belgelerine gidin. bilgi

Apigee Edge, birden fazla arka uç sunucu örneği genelinde yük dengeleme ve yük devri için dahili destek sağlayarak API'nizin kullanılabilirliğini artırır.

TargetServer yapılandırmaları, somut uç nokta URL'lerini TargetEndpoint yapılandırmalarından ayırır. Her TargetServer’a bir TargetEndpoint HTTPConnection’da ad ile başvurulur. Yapılandırmada somut bir URL tanımlamak yerine, TargetEndpoint bölümünde açıklandığı gibi bir veya daha fazla adlandırılmış TargetServer yapılandırabilirsiniz.

TargetServer tanımı bir ad, bir ana makine ve bir bağlantı noktasından ve TargetServer'ın etkin mi yoksa devre dışı mı olduğunu belirten ek bir öğeden oluşur.

Videolar

Hedef sunucuları kullanarak API yönlendirmesi ve yük dengeleme hakkında daha fazla bilgi edinmek için aşağıdaki videoları izleyin

Video	Açıklama
Hedef sunucuları kullanarak yük dengeleme	Hedef sunucular arasında yük dengeleme API'leri.
Hedef sunucuları kullanan ortama dayalı API yönlendirmesi	Ortama bağlı olarak bir API'yi farklı bir hedef sunucuya yönlendirin.
Hedef sunucuları kullanarak API yönlendirme ve yük dengeleme (Klasik Edge)	Ortama göre API'leri farklı bir hedef sunucuya yönlendirin ve Klasik Edge kullanıcı arayüzündeki hedef sunucular arasında API'nizin yük dengelemesini yapın.

Örnek TargetServer Yapılandırması

Aşağıdaki kod bir hedef sunucu tanımlar:

<TargetServer  name="target1">
  <Host>1.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >

TargetServer Yapılandırma Öğeleri

Aşağıdaki tabloda bir TargetServer oluşturmak ve yapılandırmak için kullanılan öğeler açıklanmıştır:

Ad	Açıklama	Varsayılan	Zorunlu mu?
name	TargetServer yapılandırmasının adı. Bu ad, ortam içinde benzersiz olmalıdır. TargetServer adı sadece alfa-sayısal karakterler içerebilir.	Yok	Evet
Host	Arka uç hizmetinin ana makine URL'si (protokol olmadan).	Yok	Evet
Port	Arka uç hizmetinin dinlediği bağlantı noktası	Yok	Evet
IsEnabled	TargetServer yapılandırmasının etkin mi yoksa devre dışı mı olduğunu belirten boole değeridir. Bu sayede, API proxy yapılandırmasını değiştirmeden TargetServers'ı rotasyon dışında bırakabilirsiniz. Yaygın bir kullanım, TargetServers'ı beklenen kapasite gereksinimlerine, bakım programlarına vb. göre otomatik olarak etkinleştiren veya devre dışı bırakan bir uygulama veya komut dosyası yazmaktır.	true	Evet

Kullanıcı arayüzünü kullanarak hedef sunucuları yönetme

Hedef sunucuları aşağıda açıklandığı gibi yönetin.

API'yi kullanarak hedef sunucuları yönetme

Hedef sunucuları oluşturmak, silmek, güncellemek, almak ve listelemek için Edge API'yi kullanabilirsiniz. Daha fazla bilgi için TargetServers'a bakın.

Hedef sunucu oluşturmak için aşağıdaki API çağrısını kullanın:

$ curl -H "Content-Type:text/xml" -X POST -d \
'<TargetServer name="target1">
   <Host>1.mybackendservice.com</Host>
   <Port>80</Port>
   <IsEnabled>true</IsEnabled>
 </TargetServer>' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Örnek Yanıt:

{
  "host" : "1.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target1",
  "port" : 80
}

İlk TargetServer'ı oluşturduktan sonra, ikinci bir TargetServer oluşturmak için aşağıdaki API çağrısını kullanın. İki TargetServer tanımlayarak, TargetEndpoint'in yük dengeleme için kullanabileceği iki URL sağlarsınız:

$ curl -H "Content-type:text/xml" -X POST -d \
'<TargetServer  name="target2">
  <Host>2.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Örnek Yanıt:

{
  "host" : "2.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target2",
  "port" : 80
}

Bir ortamdaki TargetServer'ların listesini almak için aşağıdaki API çağrısını kullanın:

$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Örnek yanıt:

[ "target2", "target1" ]

Şu anda test ortamında dağıtılan API proxy'leri tarafından kullanılabilen iki TargetServer vardır. Bu TargetServer'lar arasında trafik yükünü dengelemek için API proxy'sinin hedef uç noktasındaki HTTP bağlantısını TargetServer'ları kullanacak şekilde yapılandırırsınız.

Limits konusunda açıklandığı gibi ortam başına 500 TargetServer sınırı vardır.

Adlandırılmış TargetServers arasında yük dengelemesi yapmak için bir TargetEndpoint yapılandırma

Artık iki TargetServer'ınız olduğuna göre, TargetEndpoint HTTP bağlantı ayarını ada göre bu iki TargetServer'a referans verecek şekilde değiştirebilirsiniz:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Server name="target1" />
      <Server name="target2" />
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Yukarıdaki yapılandırma, mümkün olan en temel yük dengeleme yapılandırmasıdır. Yük dengeleyici; dönerli, ağırlıklı ve en az bağlantı olmak üzere üç yük dengeleme algoritmasını destekler. Grup Karşılaşması varsayılan algoritmadır. Yukarıdaki yapılandırmada herhangi bir algoritma belirtilmediğinden, API proxy'sinden arka uç sunucularına giden istekler, hedef1 ile hedef 2 arasında bire bir olmak üzere alternatif olacaktır.

<Path> öğesi, tüm hedef sunucular için TargetEndpoint URI'sının temel yolunu oluşturur. Yalnızca <LoadBalancer> kullanıldığında kullanılır. Aksi takdirde yoksayılır. Yukarıdaki örnekte, "target1"e ulaşan bir istek http://target1/test olacaktır. Diğer hedef sunucular için bu şekilde olacaktır.

Yük dengeleyici seçeneklerini ayarlama

Yük dengeleyici ve TargetServer düzeyinde yük dengeleme ve yük devretme seçeneklerini kullanarak kullanılabilirliği ayarlayabilirsiniz. Bu bölümde bu seçenekler açıklanmaktadır.

Algoritma

<LoadBalancer> tarafından kullanılan algoritmayı ayarlar. Kullanılabilir algoritmalar RoundRobin, Weighted ve LeastConnections'dir. Bu algoritmaların her biri aşağıda açıklanmıştır.

Çevrimsel sıralı

Varsayılan algoritma olan çevrimsel algoritma, her TargetServer'a, sunucuların hedef uç nokta HTTP bağlantısında listelendiği sırayla bir istek yönlendirir. Örneğin:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Ağırlıklı

Ağırlıklı yük dengeleme algoritması, TargetServer'larınız için orantısal trafik yüklerini yapılandırmanızı sağlar. Ağırlıklı LoadBalancer, isteği her TargetServer'ın ağırlığıyla doğru orantılı olarak TargetServer'larınıza dağıtır. Bu nedenle, ağırlıklı algoritmada her TargetServer için bir weight özelliği ayarlamanız gerekir. Örneğin:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Algorithm>Weighted</Algorithm>
      <Server name="target1">
        <Weight>1</Weight>
      </Server>
      <Server name="target2">
        <Weight>2</Weight>
      </Server>
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Bu örnekte, target1'e yönlendirilen her bir istek için iki istek target2'ye yönlendirilir.

En Az Bağlantı

En az bağlantı algoritmasını kullanacak şekilde yapılandırılan LoadBalancer'lar, giden istekleri en az açık HTTP bağlantısına sahip TargetServer'a yönlendirir. Örneğin:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>LeastConnections</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
  </HTTPTargetConnection>
  <Path>/test</Path>
</TargetEndpoint>

Maksimum hata sayısı

API proxy'sinden TargetServer'a giden ve isteğin başka bir TargetServer'a yönlendirilmesiyle sonuçlanan maksimum başarısız istek sayısı.

Yanıt hatası, Apigee'nin hedef sunucudan yanıt alamadığı anlamına gelir. Bu gerçekleştiğinde, hata sayacı bir artar.

Ancak Apigee bir hedeften yanıt aldığında, 500 gibi bir HTTP hatası olsa bile bu, hedef sunucudan bir yanıt olarak sayılır ve hata sayacı sıfırlanır. Kötü HTTP yanıtlarının (500 gibi), durumu kötü olan bir sunucuyu yük dengeleme rotasyonundan en kısa sürede çıkarmak için hata sayacını artırmasını sağlamak amacıyla yük dengeleyici yapılandırmanıza <ResponseCode> alt öğeleri olan <ServerUnhealthyResponse> öğesini ekleyebilirsiniz. Edge bu kodlara sahip yanıtları da hata olarak sayar.

Aşağıdaki örnekte, hedef sunucudan gelen bazı 5XX yanıtları da dahil olmak üzere target1, beş başarısız istekten sonra rotasyondan kaldırılacaktır.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
        <ServerUnhealthyResponse>
            <ResponseCode>500</ResponseCode>
            <ResponseCode>502</ResponseCode>
            <ResponseCode>503</ResponseCode>
        </ServerUnhealthyResponse>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Varsayılan MaxFailures değeri 0'dır. Bu, Edge'in her zaman her istek için hedefe bağlanmaya çalıştığı ve hedef sunucuyu rotasyondan hiçbir zaman kaldırmadığı anlamına gelir.

Bir HealthMonitor ile MaxFailures > 0 değerinin kullanılması en iyisidir. MaxFailures > 0 değerini yapılandırırsanız hedef, belirttiğiniz sayıda başarısız olduğunda TargetServer rotasyondan kaldırılır. Bir HealthMonitor cihazı kullanıldığında Apigee, hedef tekrar çalışır duruma geldikten sonra TargetServer'ı, HealthMonitor'ın yapılandırmasına göre otomatik olarak tekrar rotasyona alır. Daha fazla bilgi edinmek için Cihaz sağlığı izleme makalesine göz atın.

Alternatif olarak, MaxFailures > 0 değerini yapılandırırsanız ve bir HealthMonitor yapılandırmazsanız Apigee, hata tespit ettikten sonra TargetServer'ı rotasyona otomatik olarak tekrar eklemez. Bu durumda, Apigee'nin TargetServer'ı tekrar rotasyona sokmadan önce API proxy'sini yeniden dağıtmanız gerekir. Bkz. API proxy'si dağıtma.

Tekrar dene

Yeniden deneme etkinleştirilirse bir yanıt hatası (G/Ç hatası veya HTTP zaman aşımı) meydana geldiğinde veya alınan yanıt <ServerUnhealthyResponse> tarafından ayarlanan bir değerle eşleştiğinde istek yeniden denenir. <ServerUnhealthyResponse> ayarı hakkında daha fazla bilgi için yukarıdaki Maksimum hata sayısı bölümüne bakın.

<RetryEnabled> varsayılan olarak true değerine ayarlanmıştır. Yeniden denemeyi devre dışı bırakmak için false olarak ayarlayın. Örneğin:

<RetryEnabled>false</RetryEnabled>

IsFallback

Bir (yalnızca bir tane) TargetServer "yedek" sunucu olarak ayarlanabilir. Diğer tüm TargetServer'lar yük dengeleyici tarafından kullanılamaz olarak işaretlenene kadar yedek TargetServer, yük dengeleme rutinlerine dahil edilmez. Yük dengeleyici tüm TargetServer'ların kullanılamadığını belirlediğinde tüm trafik yedek sunucuya yönlendirilir. Örneğin:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <Server name="target3">
          <IsFallback>true</IsFallback>
        </Server>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Yukarıdaki yapılandırmada, 1 ve 2. hedefler kullanılamaz hale gelene kadar 1. ve 2. hedef arasında sıralı yük dengeleme uygulanır. 1. ve 2. hedef kullanılamadığında tüm trafik 3. hedefe yönlendirilir.

Path

Yol, TargetServer tarafından arka uç sunucusuna gönderilen tüm isteklere eklenecek bir URI parçası tanımlar.

Bu öğe, düz dize yolunu veya mesaj şablonunu kabul eder. Mesaj şablonu, çalışma zamanında değişken dizesi değiştirme işlemi gerçekleştirebilmenizi sağlar. Örneğin, aşağıdaki hedef uç nokta tanımında yol için {mypath} değeri kullanılır:

<HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
    </SSLInfo>
    <LoadBalancer>
      <Server name="testserver"/>
    </LoadBalancer>
    <Path>{mypath}</Path>
</HTTPTargetConnection>

TLS/SSL için hedef sunucu yapılandırma

Arka uç hizmetini tanımlamak için TargetServer kullanıyorsanız ve arka uç hizmeti, bağlantının HTTPS protokolünü kullanmasını gerektiriyorsa TargetServer tanımında TLS/SSL'yi etkinleştirmeniz gerekir. <Host> etiketi bağlantı protokolünü belirtmenize izin vermediğinden bu gereklidir. Aşağıda, Edge'in arka uç hizmetine HTTPS istekleri gönderdiği tek yönlü TLS/SSL'nin TargetServer tanımı gösterilmiştir:

<TargetServer name="target1">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo> 
</TargetServer>

Arka uç hizmeti iki yönlü veya karşılıklı TLS/SSL gerektiriyorsa TargetEndpoints ile aynı TLS/SSL yapılandırma ayarlarını kullanarak TargetServer'ı yapılandırırsınız:

<TargetServer  name="TargetServer 1">
    <IsEnabled>true</IsEnabled>
    <Host>www.example.com</Host>
    <Port>443</Port>
    <SSLInfo>
        <Ciphers/>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <Enabled>true</Enabled>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <KeyAlias>keystore-alias</KeyAlias>
        <KeyStore>keystore-name</KeyStore>
        <Protocols/>
        <TrustStore>truststore-name</TrustStore>
    </SSLInfo>
</TargetServer >

<Ciphers> ve <ClientAuthEnabled> gibi <SSLInfo> özellikleri hakkında bilgi edinmek için Private Cloud için bir API'ye TLS erişimini yapılandırma bölümünde bu özellikleri Sanal Ana Makine için ayarlama bilgilerine bakın.

Giden TLS/SSL'yi yapılandırma talimatlarının tamamı için Uçtan arka uca TLS'yi yapılandırma (Cloud ve Private Cloud) sayfasına göz atın.

TargetServer şeması

GitHub'da TargetServer ve diğer varlıklar için şemayı inceleyin.

Sağlık durumu izleme

Durum izleme, TargetServer yapılandırmalarında tanımlanan arka uç hizmeti URL'lerini etkin bir şekilde yoklayarak yük dengeleme yapılandırmalarını geliştirmenizi sağlar. Durum izleme etkinleştirildiğinde HealthMonitor, TargetServer'ın etkin olduğunu belirlediğinde başarısız olan TargetServer otomatik olarak tekrar rotasyona alınır.

Cihaz sağlığı izleme özelliği <MaxFailures> ile birlikte çalışır. Durum izleme etkinleştirilmediğinde <MaxFailures>, API proxy'sinden TargetServer'a giden ve isteğin başka bir TargetServer'a yönlendirilmesiyle sonuçlanan başarısız isteklerin sayısını belirtir. Hatalı TargetServer daha sonra, siz proxy'yi yeniden dağıtana kadar rotasyondan çıkarılır.

Durum izleme etkinleştirildiğinde, başarısız olan TargetServer otomatik olarak rotasyona alınır ve proxy yeniden dağıtımı yapılması gerekmez.

HealthMonitor, TCP veya HTTP üzerinden bir arka uç hizmeti çağıran basit bir istemci işlevi görür:

• TCP istemcisi, bir yuvanın açılabilmesini sağlar.
• HTTP istemcisini arka uç hizmetine geçerli bir HTTP isteği gönderecek şekilde yapılandırırsınız. HTTP GET, PUT, POST veya DELETE işlemlerini tanımlayabilirsiniz. HTTP izleme çağrısının yanıtı, <SuccessResponse> bloğundaki yapılandırılmış ayarlarla eşleşmelidir.

Başarılar ve başarısızlıklar

Durum izlemeyi etkinleştirdiğinizde Edge, hedef sunucunuza durum denetimleri göndermeye başlar. Durum denetimi, hedef sunucuya gönderilen ve hedef sunucunun iyi durumda olup olmadığını belirleyen bir istektir.

Bir durum denetimi iki olası sonuçtan birine sahip olabilir:

• Başarılı: Başarılı bir durum denetimi gerçekleştiğinde hedef sunucunun iyi durumda olduğu kabul edilir. Bu durum genellikle aşağıdakilerden biri veya daha fazlasının sonucudur:
  • Hedef sunucu, belirtilen bağlantı noktasına yeni bir bağlantıyı kabul eder, o bağlantı noktasından gelen isteğe yanıt verir ve belirtilen zaman aralığı içinde bağlantı noktasını kapatır. Hedef sunucudan alınan yanıtta "Connection: close" (Bağlantı: Kapat) ifadesi bulunuyor
  • Hedef sunucu, durum denetimi isteğine 200 (Tamam) veya kabul edilebilir olduğunu belirlediğiniz başka bir HTTP durum koduyla yanıt verir.
  • Hedef sunucu, durum denetimi isteğine beklenen ileti gövdesiyle eşleşen bir ileti gövdesiyle yanıt verir.

  Edge bir sunucunun iyi durumda olduğunu belirlediğinde, sunucuya istek göndermeye devam eder veya istek göndermeye devam eder.

• Hata: Hedef sunucu, denetim türüne bağlı olarak durum denetiminde farklı şekillerde başarısız olabilir. Hedef sunucu aşağıdaki işlemleri gerçekleştirdiğinde günlüğe bir hata kaydedilebilir:
  • Edge'den durum denetimi bağlantı noktasına olan bağlantıyı reddeder.
  • Durum denetimi isteğine belirtilen süre içinde yanıt vermez.
  • Beklenmeyen bir HTTP durum kodu döndürür.
  • Beklenen ileti gövdesiyle eşleşmeyen bir ileti gövdesiyle yanıt verir.

  Bir hedef sunucu durum denetiminde başarısız olursa Edge bu sunucunun hata sayısını artırır. Bu sunucunun hata sayısı önceden tanımlanmış bir eşiği (<MaxFailures>) karşılıyor veya aşıyorsa Edge bu sunucuya istek göndermeyi durdurur.

Sağlık Monitörünü Etkinleştirme

HealthMonitor oluşturmak için <HealthMonitor> öğesini, bir proxy için TargetEndpoint'in HTTPConnection yapılandırmasına eklersiniz. Bu işlemi kullanıcı arayüzünde yapamazsınız. Bunun yerine bir proxy yapılandırması oluşturup bunu Edge'e ZIP dosyası olarak yüklersiniz. Proxy yapılandırması, bir API proxy'sinin tüm özelliklerinin yapılandırılmış bir açıklamasıdır. Proxy yapılandırmaları, önceden tanımlanmış bir dizin yapısındaki XML dosyalarından oluşur. Daha fazla bilgi için API Proxy Yapılandırma Referansı bölümüne bakın.

Basit bir HealthMonitor, TCPMonitor veya HTTPMonitor ile birlikte bir IntervalInSec tanımlar. <MaxFailures> öğesi, API proxy'sinden TargetServer'a giden ve isteğin başka bir TargetServer'a yönlendirilmesiyle sonuçlanan maksimum başarısız istek sayısını belirtir. Varsayılan olarak <MaxFailures> değeri 0'dır. Bu, Edge'in hiçbir düzeltici işlem yapmadığı anlamına gelir. Durum izleyicisi yapılandırırken <TargetEndpoint> etiketinin <HTTPTargetConnection> etiketinde <MaxFailures> için sıfır dışında bir değer ayarladığınızdan emin olun.

TCPMonitor

Aşağıdaki yapılandırmada, beş saniyede bir 80 numaralı bağlantı noktasında bir bağlantı açarak her TargetServer'ı yoklayan bir HealthMonitor tanımlanmıştır. (Bağlantı noktası isteğe bağlıdır. Belirtilmemişse TCPMonitor bağlantı noktası, TargetServer bağlantı noktasıdır.)

• Bağlantı başarısız olursa veya bağlanması 10 saniyeden uzun sürerse bu TargetServer için hata sayısı 1 artar.
• Bağlantı başarılı olursa TargetServer için hata sayısı 0'a sıfırlanır.

HealthMonitor'ı, aşağıda gösterildiği gibi TargetEndpoint'in HTTPTargetConnetion öğesinin alt öğesi olarak ekleyebilirsiniz:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
      <Path>/test</Path>
      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <TCPMonitor>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <Port>80</Port>
        </TCPMonitor>
      </HealthMonitor>
  </HTTPTargetConnection>
. . .

TCPMonitor yapılandırma öğelerine sahip HealthMonitor

Aşağıdaki tabloda TCPMonitor yapılandırma öğeleri açıklanmaktadır:

Ad	Açıklama	Varsayılan	Zorunlu mu?
IsEnabled	HealthMonitor'ı etkinleştiren veya devre dışı bırakan bir boole değeridir.	false	Hayır
IntervalInSec	Her bir yoklama TCP isteği arasındaki saniye cinsinden zaman aralığı.	0	Evet
ConnectTimeoutInSec	Başarılı olarak kabul edilmesi için TCP bağlantı noktası ile bağlantının kurulması gereken süre. Belirtilen aralıkta bağlantı kurulamaması, hata olarak sayılır ve TargetServer için yük dengeleyicinin hata sayısını artırır.	0	Evet
Port	İsteğe bağlı. TCP bağlantısının kurulacağı bağlantı noktası. Belirtilmemişse TCPMonitor bağlantı noktası, TargetServer bağlantı noktasıdır.	0	Hayır

HTTPMonitor

HTTPMonitor kullanan örnek bir HealthMonitor, her beş saniyede bir arka uç hizmetine GET isteği gönderir. Aşağıdaki örnek, istek mesajına bir HTTP Temel Yetkilendirme üst bilgisi ekler. Yanıt yapılandırması, arka uç hizmetinden gelen gerçek yanıtla karşılaştırılacak ayarları tanımlar. Aşağıdaki örnekte beklenen yanıt, değeri YourOK olan bir HTTP yanıt kodu 200 ve özel HTTP üst bilgisi ImOK'dir. Yanıt eşleşmezse istek, yük dengeleyici yapılandırması tarafından hata olarak değerlendirilir.

HTTPMonitor, HTTP ve tek yönlü HTTPS protokollerini kullanacak şekilde yapılandırılmış arka uç hizmetlerini destekler. Ancak aşağıdakiler desteklenmez:

• İki yönlü HTTPS (iki yönlü TLS/SSL olarak da adlandırılır)
• Kendinden imzalı sertifikalar.

Bir HTTP izleyicisindeki tüm İstek ve Yanıt ayarlarının, çağrılması gereken arka uç hizmetine özel olacağını unutmayın.

    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <IsSSL>true</IsSSL>
          <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
          <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
          <Port>80</Port>
          <Verb>GET</Verb>
          <Path>/healthcheck</Path>
          <Header name="Authorization">Basic 12e98yfw87etf</Header>
          <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader>
        </Request>
        <SuccessResponse>
          <ResponseCode>200</ResponseCode>
          <Header name="ImOK">YourOK</Header>
        </SuccessResponse>
      </HTTPMonitor>
    </HealthMonitor>
    

HTTPMonitor yapılandırma öğelerine sahip HealthMonitor

Aşağıdaki tabloda HTTPMonitor yapılandırma öğeleri açıklanmaktadır:

Ad	Açıklama	Varsayılan	Zorunlu mu?
IsEnabled	HealthMonitor'ı etkinleştiren veya devre dışı bırakan bir boole değeridir.	false	Hayır
IntervalInSec	Her bir yoklama isteği arasındaki saniye cinsinden zaman aralığı.	0	Evet
Request	HealthMonitor tarafından rotasyondaki TargetServer'lara gönderilen giden istek mesajının yapılandırma seçenekleri. Yol, değişkenleri desteklemiyor.	Yok	Evet
IsSSL	Bağlantıları izlemek için HTTPS (güvenli HTTP) kullanılıp kullanılmayacağını belirtir. Olası değerler: true: HTTP kullanılır. false: HTTP kullanılır. Belirtilmemiş: Hedef sunucu yapılandırmasını kullanır.	false	Hayır
ConnectTimeoutInSec	HTTP hizmetine TCP bağlantısı el sıkışmasının başarılı kabul edilmesi için tamamlanması gereken saniye cinsinden süre. Belirtilen aralıkta bağlantı kurulamaması, hata olarak sayılır ve TargetServer için LoadBalancer'ın hata sayısını artırır.	0	Hayır
SocketReadTimeoutInSec	Saniye cinsinden verilerin başarılı olarak kabul edilmesi için HTTP hizmetinden okunması gereken süre. Belirtilen aralıkta okumanın başarısız olması hata olarak sayılır ve TargetServer için LoadBalancer'ın hata sayısı artar.	0	Hayır
Port	Arka uç hizmetiyle olan HTTP bağlantısının kurulacağı bağlantı noktası.	Yok	Hayır
Verb	Arka uç hizmetine yapılan her yoklama HTTP isteği için kullanılan HTTP fiili .	Yok	Hayır
Path	TargetServer'da tanımlanan URL'ye eklenen yol. HTTP hizmetinizde "yoklama uç noktası" yapılandırmak için path öğesini kullanın.	Yok	Hayır
IncludeHealthCheckIdHeader	Yukarı akış sistemlerinde durum denetimi isteklerini izlemenize olanak tanır. IncludeHealthCheckIdHeader bir Boole değeri alır ve varsayılan olarak false değerine ayarlanır. Bunu true olarak ayarlarsanız durum denetimi isteğine eklenen X-Apigee-Healthcheck-Id adında bir Header olur. Üst bilginin değeri dinamik olarak atanır ve ORG/ENV/SERVER_UUID/N biçimindedir. Burada ORG kuruluş adı, ENV ortam adı, SERVER_UUID, MP'yi tanımlayan benzersiz bir kimlik ve N, 1 Ocak 1970 tarihinden itibaren geçen milisaniye sayısıdır. Sonuçta elde edilen istek başlığı örneği: X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123	false	Hayır
Payload	Her yoklama HTTP isteği için oluşturulan HTTP gövdesi. Bu öğenin GET istekleri için gerekli olmadığını unutmayın.	Yok	Hayır
SuccessResponse	Sorgulanan arka uç hizmeti tarafından oluşturulan gelen HTTP yanıtı mesajı için eşleştirme seçenekleri. Eşleşmeyen yanıtlar hata sayısını 1 artırır.	Yok	Hayır
ResponseCode	Sorgulanan TargetServer'dan alınması beklenen HTTP yanıt kodu. Belirtilen koddan farklı bir kod, hatayla sonuçlanır ve sorgulanan arka uç hizmeti için sayı artar. Birden çok ResponseCode öğesi tanımlayabilirsiniz.	Yok	Hayır
Headers	Sorgulanan arka uç hizmetinden alınması beklenen bir veya daha fazla HTTP üst bilgisi ve değerinin listesidir. Yanıtta belirtilenlerden farklı olan HTTP üst bilgileri veya değerleri hataya neden olur ve sorgulanan TargetServer sayısı 1 artar. Birden çok Üstbilgi öğesi tanımlayabilirsiniz.	Yok	Hayır