503 Hizmet Kullanılamıyor - Etkin Hedef Yok - HealthCheckFailures

Apigee Edge belgelerini görüntülüyorsunuz.
. Git: Apigee X belgeleri.
bilgi

Videolar

503 hatalarıyla ilgili daha fazla bilgi için aşağıdaki videoları izleyin:

Video Açıklama
Sorun giderme ve "503 Hizmet Kullanılamıyor - NoActiveTarget" sorununu giderme Aşağıdakiler hakkında bilgi edinin:
  • Hedef Sunucuların ve Durum Monitörlerinin Önemi
  • Gerçek zamanlı 503 Hizmeti Kullanılamıyor sorunlarını giderme ve sorunları çözme - NoActiveTarget durum denetimi hatası nedeniyle oluşan hata

Belirti

İstemci uygulaması 503 HTTP yanıt durum kodunu Hizmet Kullanılamıyor mesajı ve NoActiveTargets hata kodu API proxy isteklerine yönelik.

Hata mesajı

Aşağıdaki hata yanıtını görürsünüz:

HTTP/1.1 503 Service Unavailable
  

HTTP yanıtında aşağıdaki hata mesajını görürsünüz:

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.NoActiveTargets"
       }
    }
}
  

Olası nedenler

Genellikle NoActiveTarget hata kodunu içeren 503 Hizmet Kullanılamıyor HTTP yanıtı gözlemlenir. API Proxy'nizdeki hedef uç nokta yapılandırmasında bir veya daha fazla hedef sunucu kullandığınızda

Bu başucu kitabında, hata koduyla birlikte 503 Hizmet Kullanılamıyor durumu ele alınmaktadır Durum denetimi hataları nedeniyle NoActiveTargets 'ta sorun yaşandı. Bu hatanın diğer nedenleri hakkında bilgi edinmek için lütfen bu başucu kitabına bakın.

Durum denetimi hataları

Durum denetimi hataları yalnızca Durum Monitörü, API Proxy'nizin hedef uç noktasında hedef sunucu yük dengeleme yapılandırmasının bir parçası olarak.

Hedef sunucu durum denetiminde başarısız olursa Edge o sunucunun hata sayısını artırır. Söz konusu sunucunun durum denetimi hatalarının sayısı önceden tanımlanmış eşiğe (<MaxFailures>) ulaşırsa İleti İşleyen, uyarı mesajını aşağıda gösterilen şekilde günlük dosyasına kaydeder:

Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
    

Uyarı mesajında aşağıdaki bilgiler bulunur. Bu, hangi hedef sunucunun MaxFailure sayısına ulaştığını anlamanıza yardımcı olur:

  • Hedef Sunucu adı
  • Kuruluş ve Ortam adları
  • API Proxy adı
  • Hedef Uç Nokta adı

Ardından Edge, söz konusu sunucuya başka istek göndermeyi durdurur. Tüm hedeflenen LoadBalancer yapılandırmasında yapılandırılan sunucular MaxFailure sayısına ulaşırken sonraki API isteklerine NoActiveTarget hata koduyla 503 Hizmet Kullanılamıyor mesajıyla yanıt verilir.

Health Monitor'ün kullanılması, Apigee Edge'in iyileştiğinde döndürmesine yardımcı olur.

Durum denetimi hatalarının olası nedenleri şunlardır:

Neden Açıklama Sorun giderme adımlarını kimler uygulayabilir?
Bağlantı Zaman Aşımı Hatası İleti İşleyici, belirtilen zaman aşımı süresi içinde hedef sunucuya bağlanamıyor dönemini ifade eder. Edge Private Cloud kullanıcıları
Güvenli Olmayan Bağlantı Noktasında Güvenli İstek
  1. Hedef sunucu güvenli bir sunucu olarak tanımlanmışsa ancak güvenli olmayan bir bağlantı noktası oluşturabilirsiniz.
  2. Hedef sunucu güvenli bir sunucu olarak tanımlanmışsa, ancak durum izleyici güvenli olmayan bir bağlantı noktasında durum denetimleri gerçekleştirecek şekilde yapılandırıldı.
Edge Private Cloud kullanıcıları
Güvenli Bağlantı Noktasında Güvenli Olmayan İstek
  1. Hedef sunucu güvenli olmayan bir sunucu olarak tanımlanmışsa ancak yanlış yapılandırılmışsa bunu güvenli bir bağlantı noktasından çıkarabilirsiniz.
  2. Hedef sunucu güvenli olmayan bir sunucu olarak tanımlandıysa ancak durum izleyicisi güvenli olmayan bir sunucu olarak tanımlandıysa güvenli bir bağlantı noktasında durum denetimleri gerçekleştirecek şekilde yapılandırılmıştır.
Edge Private Cloud kullanıcıları
Health Check API hata veriyor Durum denetimi API bir hatayla veya yanıt koduyla yanıt verirse Durum Monitörü'nün SuccessResponse öğesinde belirtilmiş. Edge Private Cloud kullanıcıları

Sık kullanılan teşhis adımları

Başarısız isteğin Mesaj Kimliğini belirleme

İzleme aracı

İzleme aracını kullanarak başarısız isteğin ileti kimliğini belirlemek için:

  1. İzleme oturumunu etkinleştirin. bu API çağrısını yapın ve sorunu yeniden oluşturun: 503 Hizmet Kullanılamıyor ve NoActiveTargets hata kodu.
  2. Başarısız isteklerden birini seçin.
  3. AX aşamasına gidip ileti kimliğini (X-Apigee.Message-ID) belirleyin Aşama Ayrıntıları bölümünde aşağı doğru kaydırarak istek ekleyin.

    Aşama Ayrıntıları bölümünde mesaj kimliği

NGINX erişim günlükleri

NGINX erişim günlüklerini kullanarak başarısız isteğin ileti kimliğini belirlemek için:

503 hatalarının ileti kimliğini belirlemek için NGINX Erişim günlüklerine de bakabilirsiniz. Bu, özellikle sorun geçmişte olduysa veya ara sıra devam ediyorsa işe yarar ve kullanıcı arayüzünde izini yakalayamazsınız. NGINX erişim günlüklerindeki bu bilgileri belirlemek için aşağıdaki adımları uygulayın:

  1. NGINX erişim günlüklerini kontrol edin: (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
  2. Belirli bir süre içinde belirli API proxy'si için 503 hatası olup olmadığını arayın (sorun geçmişte oluşmuşsa) veya 503 ile hâlâ başarısız olan istekler varsa.
  3. X-Apigee-fault-codeMessaging.adaptors.http.flow.NoActiveTargets'da 503 Hataları varsa aşağıdaki örnekte gösterildiği gibi, bu tür bir veya daha fazla isteğin ileti kimliğini not edin:

    503 Hatası'nı gösteren Örnek Giriş

    Durum kodu, mesaj kimliği, hata kaynağı ve hata kodunu gösteren örnek giriş

Yaygın hata mesajları

Hedef sunucular kullanıldığında ve İleti İşleyici çalışırken hata oluştuğunda bağlantı kurduğunuzda İleti işleyen günlükleri. Bu hatalar, asıl istisna/hata mesajından sonra günlüğe kaydedilir neden olmuş olabilir.

İleti İşleyici günlüklerinde sık karşılaşılan hata iletileri (/opt/apigee/var/log/edge-message-processor/logs/system.log) NoActiveTarget hata koduyla 503 Hizmet Kullanılamıyor aşağıdaki gibidir:

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 INFO  ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : Failed to send request to target servers : [demo-target] for default{Organization=myorgEnvironment=prod,Application=TestTargetServer__2}

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : No Active Target server Found for default{Organization=myorgEnvironment=prod,Application=TestTargetServer__2}

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : Unexpected error while sending request
com.apigee.errors.http.server.ServiceUnavailableException: The Service is temporarily unavailable
	at com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender.sendRequest(LBTargetRequestSender.java:299)
	at com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender.access$400(LBTargetRequestSender.java:57)
	…<snipped>

Bu hata mesajları, isteğin bir başarısız olur. Sonuç olarak, Mesaj İşleyen, 503 Hizmet Kullanılamıyor hatasını gönderir. NoActiveTargets hata koduna sahip olabilir.

Neden: Bağlantı zaman aşımı

Teşhis

  1. Başarısız isteğin mesaj kimliğini belirleyin.
  2. İleti İşleyen günlüğünde (/opt/apigee/var/log/edge-message-processor/logs/system.log) ileti kimliğini arayın.
  3. Bir İleti kimliğine karşılık gelen yaygın hata mesajları. Ancak, durum denetimi hatalarının gerçek nedenini öğrenmek için bu hataların üzerine kaydırın yaygın hata mesajlarını inceleyin ve HEALTH MONITOR hatası olup olmadığını kontrol edin.

    Örneğin, aşağıdaki HEALTH MONITOR hata mesajı, İleti İşleyen'in başarısız olduğunu belirtir. durum denetimi API isteği yapılırken bağlantı zaman aşımına uğradı hatası ile:

    Apigee-Timer-6 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : https://<BackendServer-Hostname>:443/status
    java.net.ConnectException: Connection timed out (Connection timed out)
    	at java.net.PlainSocketImpl.socketConnect(Native Method)
    	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
    	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
    …<snipped>
            

    Bu hata, Durum Monitörü'nde yapılandırma işlemi için MaxFailure kez tekrarlanırsa şuna benzer bir uyarı mesajı görürsünüz:

    Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
            

    Uyarı mesajında verilen bilgileri dikkatlice okuyun. MaxFailure ziyaret etmekte olduğunuz belirli API Proxy'sinde kullanılan bir hedef sunucu için NoActiveTargets hata koduyla karşılaşan 503 yanıt kodu sorunu.

  4. Yukarıdaki örnekte durum denetimi connection timed out hatası nedeniyle başarısız olmuştur. Her bir telnet komutunu kullanarak mesaj işleyenler:
  5. telnet <BackendServer-HostName> 443
          
  6. Arka uç sunucusuna bağlanabiliyorsanız aşağıdaki gibi bir mesaj görebilirsiniz: Arka uç sunucusuna bağlanıldı. Sorun geçici bir sorun olabilir ve bu sorun çözülmüş olabilir ya da ara sıra yaşanan bir sorundur. 4. adımı birkaç kez tekrarlayın (10'dan fazla kez) ve çıkışı doğrulayın.
    1. telnet komutunda tutarlı bir şekilde hata yoksa sorun çözüme ulaştırıldı. Durum denetimi hatalarının durup durmadığını tekrar kontrol edin. Cevabınız evetse herhangi bir işlem yapmanız gerekmez. devam edelim.
    2. telnet komutuyla arka uç sunucusuna ara sıra bağlanamıyorsanız ağla ilgili bir sorun olabilir veya arka uç sunucunuz meşgul olabilir.
  7. telnet komutuyla arka uç sunucusuna tutarlı şekilde bağlanamıyorsanız bu durum, söz konusu arka uç sunucusundaki Mesaj İşleyicilerden gelen trafiğe izin verilmemesinden kaynaklanabilir.

Çözünürlük

Sürekli olarak connection timed out hatası gözlemleniyorsa arka ucun sunucuda herhangi bir güvenlik duvarı kısıtlaması bulunmaz ve Apigee Edge Mesaj İşlemcilerinden gelen trafiğe izin verilir. Örneğin, Linux'ta, web'den gelen trafiğe izin vermek için iptables Mesaj İşleyici'nin arka uç sunucusundaki IP adresleri.

Sorun devam ederse, sorunu belirlemek ve düzeltmek için ağ yöneticinizle birlikte çalışın. Apigee'den daha fazla yardıma ihtiyacınız olursa Apigee Destek Ekibi ile iletişime geçin.

Neden: Güvenli olmayan bağlantı noktasında güvenli istek

Teşhis

  1. Başarısız isteğin mesaj kimliğini belirleyin.
  2. İleti İşleyen günlüğünde (/opt/apigee/var/log/edge-message-processor/logs/system.log) ileti kimliğini arayın.
  3. İleti kimliğine karşılık gelen sık karşılaşılan hata mesajlarını görürsünüz. Ancak durum denetimi hatalarının asıl nedenini öğrenmek için bu hataların üzerine kaydırın yaygın hata mesajlarını inceleyin ve HEALTH MONITOR hatası olup olmadığını kontrol edin.

    Örneğin, aşağıda gösterildiği gibi bir HEALTH MONITOR hatası görebilirsiniz:

    Apigee-Timer-1 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : https://mocktarget.apigee.net:80/status
    javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
            at sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
            at sun.security.ssl.InputRecord.read(InputRecord.java:527)
            at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)
            at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
            at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
            at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
    …<snipped>
            

    Bu hata, Durum Monitörü'nde MaxFailure kez yapılandırıldıysa şuna benzer bir uyarı mesajı görürsünüz:

    Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
            

    Uyarı mesajında verilen bilgileri dikkatlice okuyun. MaxFailure ziyaret etmekte olduğunuz belirli API Proxy'sinde kullanılan bir hedef sunucu için NoActiveTargets hata koduyla karşılaşan 503 yanıt kodu sorunu.

  4. Durum denetimi şu hata nedeniyle başarısız oldu:
    Error sending request Request URL : https://mocktarget.apigee.net:80/statuscode/200
    javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
          
    .

    Hata mesajı ve URL, bu sorunun nedeninin güvenli olmayan bağlantı noktası 80 üzerinde güvenli arama (HTTPS) yapıldı.

    Bu hata, aşağıdaki iki senaryoda ortaya çıkabilir:

    • Güvenli hedef sunucu, güvenli olmayan bağlantı noktasıyla tanımlanmış
    • Güvenli hedef sunucu tanımlandı ancak Sağlık Monitörü güvenli olmayan bir bağlantı noktasıyla yapılandırıldı

    Güvenli hedef güvenli olmayan bağlantı noktası

    1. Senaryo: Güvenli hedef sunucu, güvenli olmayan bağlantı noktasıyla tanımlandı

    Güvenli hedef sunucu tanımladıysanız ancak 80 gibi güvenli olmayan bir bağlantı noktası belirlediyseniz bu hata mesajını alıyorsunuz. Bu sorunun nedeninin bu olup olmadığını doğrulamak için aşağıdaki adımları uygulayın:

    1. Hedef uç nokta yapılandırmasında kullanılan hedef sunucunun tanımını kontrol edin.
    2. Şunu kullanın: TargetServer API'yi alma kullanarak hedef sunucu tanımını öğrenebilirsiniz.

      Hedef Sunucu Tanımı Çıkışı

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

      Yukarıdaki örnekte tanım, mocktarget hedef sunucusunun güvenli bir sunucu olduğunu göstermektedir SSLInfo bloğuyla belirtilen sunucuyu kapsamalıdır. Ancak güvenli olmayan bir Bağlantı Noktası 80 ile yapılandırılmıştır.

    3. Şimdi, hedef uç nokta yapılandırmasındaki hedef sunucunun Durum Monitörü yapılandırmasını kontrol edin:

      Durum Monitörü Yapılandırması

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
                

      <Port> Durum Monitörü yapılandırmasını yukarıda bulabilirsiniz. Bu durumda, Edge'in İleti İşlemcisi, durum denetimi API çağrıları yapmak için hedef sunucu tanımında (yani 80'dir) belirtilir.

    4. Yukarıdaki bilgilere göre bu hatanın nedeni, hedef sunucunun güvenli bir sunucu olarak tanımlanır (SSLInfo bloğu etkin olduğu şekilde), ancak güvenli olmayan bir bağlantı noktası olan 80.

    Güvenli hedef güvenli olmayan HM bağlantı noktası

    2. Senaryo: Güvenli hedef sunucu tanımlandı ancak Durum Monitörü güvenli olmayan bir bağlantı noktasıyla yapılandırıldı

    Güvenli bir hedef sunucu tanımladıysanız ancak Durum Monitörü 80 gibi güvenli olmayan bir bağlantı noktası kullanıyorsanız bu hatayı alırsınız. Doğrulamak için aşağıdaki adımları uygulayın Bu sorunun nedeni buysa:

    1. Hedef uç nokta yapılandırmasında kullanılan hedef sunucunun tanımını kontrol edin.

      Hedef sunucu tanımını almak için TargetServer API'yi alın.

      Hedef Sunucu Tanımı Çıkışı

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

      Yukarıdaki örnekte, tanım mocktarget hedef sunucusunun SSLInfo bloğuyla belirtilen güvenli bir sunucu olduğunu göstermektedir.

    2. Ardından, hedef uç nokta yapılandırmasında hedef sunucunun Durum Monitörü yapılandırmasını kontrol edin:

      Durum Monitörü Yapılandırması

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
         	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Port>80</Port>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
              

      Yukarıdaki örnekte Durum Monitörü, <Port> öğesi tarafından gösterildiği gibi güvenli olmayan bir Bağlantı Noktası 80 ile yapılandırılmıştır.

    3. Yukarıdaki bilgilere göre bu hatanın nedeni, hedef sunucunun tanımlanmış olmasıdır. güvenli bir sunucu olarak çalışır (SSLInfo bloğu etkin olduğundan) ve güvenli bağlantı noktası 443'ü kullanır ancak Durum Monitörü güvenli olmayan bir bağlantı noktası 80 ile (<Port> öğesinde belirtilir) durum denetimleri gerçekleştirecek şekilde yapılandırılır.

      Bu durumda Edge, durum denetimi API'lerini güvenli olmayan bağlantı noktası 80'dir ve yukarıda belirtilen hatayla başarısız olur.

Çözünürlük

Güvenli hedef güvenli olmayan bağlantı noktası

1. Senaryo: Güvenli hedef sunucu, güvenli olmayan bağlantı noktasıyla tanımlandı

Bu hatayı düzeltmek için hedef sunucu tanımını uygun bir güvenli bağlantı noktası kullanacak şekilde güncelleyin.

Hedef sunucu tanımını güncellemek için bir TargetServer API'yi güncelleyin ve Aşağıdaki örnekte gösterildiği gibi güvenli bir bağlantı noktası (örneğin: 443) kullanılır:

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

Güvenli hedef güvenli olmayan HM bağlantı noktası

2. Senaryo: Güvenli hedef sunucu tanımlandı ancak Durum Monitörü güvenli olmayan bir bağlantı noktasıyla yapılandırıldı

Bu hatayı düzeltmek için aşağıdaki talimatları uygulayın:

  1. Hedef gerçekleştirmek için durum izleme yapılandırmasını güvenli bir bağlantı noktası (ör. 443) kullanacak şekilde değiştirin. aşağıda gösterildiği gibi, başarısız olan API Proxy'sinin hedef uç nokta yapılandırmasında sunucu durum denetimleri bulunur:
    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
        <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
          <Port>443</Port>
          <Verb>GET</Verb>
          <Path>/statuscode/200</Path>
        </Request>
        <SuccessResponse>
          <ResponseCode>200</ResponseCode>
        </SuccessResponse>
      </HTTPMonitor>
    </HealthMonitor>
            
    .
  2. API Proxy'sinde yapılan değişiklikleri kaydedin.

Neden: Güvenli bir bağlantı noktasında güvenli olmayan istek

Teşhis

  1. Başarısız isteğin mesaj kimliğini belirleyin.
  2. İleti İşleyen günlüğünde (/opt/apigee/var/log/edge-message-processor/logs/system.log) ileti kimliğini arayın.
  3. Bir İleti kimliğine karşılık gelen yaygın hata mesajları. Ancak durum denetimi hatalarının asıl nedenini öğrenmek için bu hataların üzerine kaydırın yaygın hata mesajlarını inceleyin ve HEALTH MONITOR hatası olup olmadığını kontrol edin.

    Örneğin, aşağıda gösterildiği gibi bir HEALTH MONITOR hatası görebilirsiniz:

    Apigee-Timer-2 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : http://mocktarget.apigee.net:443/status
    java.net.SocketException: Unexpected end of file from server
    	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:851)
    	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
    	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:848)
    	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
    	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1587)
    …<snipped>
              

    Bu hata, Durum Monitörü'nde MaxFailure kez yapılandırıldıysa şuna benzer bir uyarı mesajı görürsünüz:

    Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
              

    Uyarı mesajında verilen bilgileri dikkatlice okuyun. MaxFailure ziyaret etmekte olduğunuz belirli API Proxy'sinde kullanılan bir hedef sunucu için NoActiveTargets hata koduyla karşılaşan 503 yanıt kodu sorunu.

  4. Durum denetimi şu hata nedeniyle başarısız oldu:
    Error sending request Request URL : http://mocktarget.apigee.net:443/status
    java.net.SocketException: Unexpected end of file from server
          
    .

    Hata mesajı ve URL, bu sorunun nedeninin güvenli bağlantı noktası 443'ten güvenli olmayan çağrı (HTTP) yapıldı.

    Bu hata, aşağıdaki iki senaryoda ortaya çıkabilir:

    • Güvenli bağlantı noktasıyla tanımlanan güvenli olmayan hedef sunucu
    • Güvenli olmayan hedef sunucu tanımlandı ancak Sağlık Monitörü güvenli bir bağlantı noktasıyla yapılandırıldı

    Güvenli olmayan hedef güvenli bağlantı noktası

    1. Senaryo: Güvenli olmayan hedef sunucu, güvenli bağlantı noktasıyla tanımlandı

    443 gibi güvenli bir bağlantı noktasına sahip olup güvenli olmayan bir hedef sunucu tanımladıysanız bu hatayı alırsınız. Bu sorunun nedeninin bu olup olmadığını doğrulamak için aşağıdaki adımları uygulayın:

    1. Hedef uç nokta yapılandırmasında kullanılan hedef sunucunun tanımını kontrol edin.

      Hedef sunucu tanımını almak için TargetServer API'yi alın.

      Hedef Sunucu Tanımı Çıkışı

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

      Yukarıdaki örnekte tanım, mocktarget hedef sunucunun olduğunu göstermektedir SSLInfo bloğu bulunmadığından güvenli olmayan bir sunucudur. Ancak, bununla güvenli Bağlantı Noktası 443 ile yapılandırıldığından emin olun.

    2. Şimdi, hedef uç nokta yapılandırmasındaki hedef sunucunun Durum Monitörü yapılandırmasını kontrol edin:

      Durum Monitörü Yapılandırması

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
                      

      Durum Monitörü'nde <Port> öğesi belirtilmediğine dikkat edin yapılandırma yukarıdaki. Bu durumda Edge'in İleti İşlemcisi şu adreste belirtilen bağlantı noktasını kullanır: hedef sunucu tanımıdır.

    3. Yukarıdaki bilgilere göre bu hatanın nedeni, hedef sunucunun tanımlanmış olmasıdır. güvenli olmayan bir sunucu olarak (SSLInfo bloğu tanımlanmadığından) ancak güvenli bağlantı noktası 443'tür.

      Yani Edge, durum denetimlerini güvenli bağlantı noktası 443 ile güvenli olmayan bir çağrı olarak yapar ve başarısız olur. belirtilen hata nedeniyle geri dönülemez.

    Güvenli olmayan hedef güvenli HM bağlantı noktası

    2. Senaryo: Güvenli olmayan hedef sunucu tanımlandı ancak Durum Monitörü güvenli bir bağlantı noktasıyla yapılandırıldı

    Güvenli olmayan bir hedef sunucu tanımladıysanız ancak Durum Monitörü 443 gibi güvenli bir bağlantı noktasıyla yapılandırılmışsa bu hatayı alırsınız. Bu sorunun nedeninin bu olup olmadığını doğrulamak için aşağıdaki adımları uygulayın:

    1. Hedef uç nokta yapılandırmasında kullanılan hedef sunucunun tanımını kontrol edin.

      Hedef sunucu tanımını almak için TargetServer API'yi alın.

      Hedef Sunucu Tanımı Çıkışı

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>80</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer>
              

      Yukarıdaki örnekte tanım, mocktarget hedef sunucusunun güvenli olmayan bir sunucu olduğunu göstermektedir güvenli olmayan bağlantı noktası 80 doğru şekilde ile yapılandırılmış bir SSLInfo bloğu olmadığından) emin olun.

    2. Ardından, hedef uç nokta yapılandırmasında hedef sunucunun Durum Monitörü yapılandırmasını kontrol edin:

      Durum Monitörü Yapılandırması

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
         	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Port>443</Port>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
            

      Yukarıdaki örnekte, Durum Monitörü <Port> öğesi ile gösterildiği gibi güvenli bir Bağlantı Noktası 443 ile yapılandırılmıştır.

    3. Yukarıdaki bilgilere göre bu hatanın nedeni, hedef sunucunun güvenli olmayan bir sunucu kullanıyorsanız (SSLInfo bloğu tanımlanmadığından) ve güvenli olmayan bağlantı noktası 80'i doğru şekilde kullanabilirsiniz. Ancak Durum Monitörü, 443 güvenli bağlantı noktası ile durum denetimleri gerçekleştirecek şekilde yapılandırılmıştır (<Port> öğesinde belirtilir).

      Bu durumda Edge, durum denetimlerini güvenli bağlantı noktası 443 ile güvenli olmayan bir çağrı olarak yapar ve yukarıda belirtilen hatayla başarısız olur.

Çözünürlük

Güvenli olmayan hedef güvenli bağlantı noktası

1. Senaryo: Güvenli olmayan hedef sunucu, güvenli bağlantı noktasıyla tanımlandı

Bu hatayı düzeltmek için hedef sunucu tanımını uygun bir güvenli bağlantı noktası kullanacak şekilde güncelleyin.

Hedef sunucu tanımını güncellemek için hedef sunucu API'sini güncelleyin ve Aşağıdaki örnekte gösterildiği gibi güvenli olmayan bir bağlantı noktası (örneğin: 80) kullanılır:

<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>
              

Güvenli olmayan hedef güvenli HM bağlantı noktası

2. Senaryo: Güvenli olmayan hedef sunucu tanımlandı ancak Durum Monitörü güvenli bir bağlantı noktasıyla yapılandırıldı

Bu hatayı düzeltmek için aşağıdaki talimatları uygulayın:

  1. <Port> öğesini Durum Monitörü yapılandırmasından kaldırın veya Health Monitor yapılandırmasını güvenli olmayan bağlantı noktası (örneğin: 80) kullanacak şekilde değiştirin. aşağıda gösterildiği gibi, başarısız olan API Proxy'sinin hedef uç nokta yapılandırmasında hedef sunucu durum denetimleri gerçekleştirmek için kullanılır:
    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
       	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
          <Port>80</Port>
          <Verb>GET</Verb>
          <Path>/statuscode/200</Path>
        </Request>
        <SuccessResponse>
          <ResponseCode>200</ResponseCode>
        </SuccessResponse>
      </HTTPMonitor>
    </HealthMonitor>
            
  2. API Proxy'sinde yapılan değişiklikleri kaydedin.

Neden: Durum denetimi API'si hatayla yanıt veriyor

Teşhis

  1. Başarısız isteğin mesaj kimliğini belirleyin.
  2. İleti İşleyen günlüğünde (/opt/apigee/var/log/edge-message-processor/logs/system.log) ileti kimliğini arayın.
  3. İleti kimliğine karşılık gelen sık karşılaşılan hata mesajlarını görürsünüz. Ancak durum denetimi hatalarının asıl nedenini öğrenmek için bu hataların üzerine kaydırın yaygın hata mesajlarını inceleyin ve HEALTH MONITOR Hataları/Uyarıları olup olmadığını kontrol edin.

    Örneğin, aşağıda gösterildiği gibi bir HEALTH MONITOR uyarısı görebilirsiniz:

    Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
    Apigee-Timer-7 WARN  SERVICES.HEALTH_MONITOR - HTTPMonitor.monitor() : HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
            

    Bu hata, Durum Monitörü'nde MaxFailure kez yapılandırıldıysa şuna benzer bir uyarı mesajı görürsünüz:

    Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
            

    Uyarı mesajında verilen bilgileri dikkatlice okuyun. MaxFailure ziyaret etmekte olduğunuz belirli API Proxy'sinde kullanılan bir hedef sunucu için NoActiveTargets hata koduyla karşılaşan 503 yanıt kodu sorunu.

  4. Durum denetimi şu uyarı mesajını döndürdü:
    HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
          
    .

    Yukarıdaki uyarı mesajı, health check API için beklenen yanıt kodunun 200 olduğunu belirtir. ancak alınan gerçek yanıt 404'tür. Dolayısıyla bu bir hata olarak değerlendirilir.

  5. Durum denetimi API'sinden gelen hata yanıtının nedenini araştırmadan önce Edge'in neden hata yaptığını belirleyin durum denetimi API'si için yanıt kodunun 200 olarak olmasını bekler. Bunun için Durum Monitörü'nü kontrol edin hedef uç nokta yapılandırmasındaki hedef sunucu için yapılandırma:

    Durum Monitörü Yapılandırması

    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
       	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
          <Port>443</Port>
          <Verb>GET</Verb>
          <Path>/status/200</Path>
        </Request>
        <SuccessResponse>
          <ResponseCode>200</ResponseCode>
        </SuccessResponse>
      </HTTPMonitor>
    </HealthMonitor>
            

    Durum Monitörü yapılandırmasının, <SuccessResponse> öğesi altında 200 yanıt koduyla yapılandırıldığına dikkat edin. Bu durumda Edge, durum denetimi API'sinden 200 dışında bir yanıt kodu (örneğin, 400, 401, 404, 500) alırsa bu bir hata olarak değerlendirilir ve hata sayısını artırır.

  6. Şimdi, durum denetimi API'sinde hata yanıtının nedenini incelemek için aşağıdaki adımları uygulayın:
    1. Mesaj İşleyen günlüğünde, uyarı mesajından önceki iletiye bakın.
      Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
                

      Bu iletideki durum denetimi URL'sini not edin.

    2. Mesaj İşleyici'den bu URL'ye doğrudan çağrı yapabilir ve mesajın kendisini kontrol edebilirsiniz
      curl -i https://mocktarget.apigee.net:443/status/200
                
      .

      Yukarıdaki çağrının yanıtı, İleti İşleyici günlüklerinde görüldüğü gibi 404 hatasını verir:

      < HTTP/2 404
                
    3. Bu, durum denetimi URL'sine yapılan doğrudan çağrının bile aynı yanıt koduyla 404 başarısız olduğunu gösterir. Bu, durum denetimi URL'sinin yanlış olabileceği veya URL'nin bir parçası olarak erişilen kaynağın artık kullanılamadığı anlamına gelir.
    4. Yukarıda sağlanan örnek durum denetimi API'sinde sorun, Durum Monitörü yapılandırmasında yanlış URL kullanıldığından ortaya çıkmaktadır. Doğru URL'nin https://mocktarget.apigee.net:443/statuscode/200 şuradan olduğu belirlendi: Örnek Hedef API.
  7. Başka bir hata yanıtı alırsanız aşağıdaki adımları uygulayarak aynı sorunun nedenini belirleyin adımları uygulayın. Gerekirse arka uç ekibinizle birlikte çalışın.

Çözünürlük

  1. Arka uç sunucunuzdaki durum denetimi API'siyle ilgili sorunu düzeltin.
  2. Yukarıda açıklanan örnekteki sorunu düzeltmek için:
    1. Durum Monitörü yapılandırmasındaki <Path> öğesini aşağıda gösterildiği gibi /statuscode/200 olarak değiştirin:
      <Path>/statuscode/200</Path>
              
    2. API Proxy'sindeki değişiklikleri kaydedin.

Sorun devam ederse şu adrese gidin: Teşhis Bilgileri Toplanmalıdır.

API izlemeyi kullanarak sorunları teşhis edin

API İzleme, sorunları diğerlerinden ayırarak hata, performans ve gecikme sorunlarını ve bunların kaynağını hızla teşhis etmek için (ör. geliştirici, API proxy'leri, arka uç hedefleri veya API platformu.

Örnek senaryoyu inceleyin . Örneğin, messaging.adaptors.http.flow.NoActiveTargets sayısı konusunda bilgilendirilmek için bir uyarı ayarlayabilirsiniz belirli bir eşiği aştığını unutmayın.

Teşhis bilgileri toplanmalıdır

Yukarıdaki talimatları uygulamanıza rağmen sorun devam ederse lütfen aşağıdaki bilgileri toplayın teşhis bilgisi olarak kullanabilirsiniz. Apigee Destek Ekibi ile iletişime geçip paylaşın:

  1. Herkese Açık Bulut kullanıcısıysanız aşağıdaki bilgileri sağlayın:
    1. Kuruluş Adı
    2. Ortam Adı
    3. API Proxy Adı
    4. Hatayı yeniden oluşturmak için curl komutunu tamamlayın
    5. 503 hizmeti kullanılamıyor durumuna sahip istekleri içeren ve NoActiveTarget hata koduna sahip izleme dosyası
  2. Private Cloud kullanıcısıysanız aşağıdaki bilgileri sağlayın:
    1. Tam Hata Mesajı gözlemlendi
    2. Ortam Adı
    3. API Proxy paketi
    4. 503 hizmeti kullanılamıyor durumuna sahip istekleri içeren ve NoActiveTarget hata koduna sahip izleme dosyası
    5. NGINX Erişim Günlükleri

      (/opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log)

    6. Mesaj İşlemci Günlükleri

      (/opt/apigee/var/log/edge-message-processor/logs/system.log)