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

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

Videolar

503 hatalarıyla ilgili daha fazla bilgi için aşağıdaki videolara bakın:

Belirti

İstemci uygulaması, API proxy istekleri için Hizmet Kullanılamıyor mesajı ve NoActiveTarget hata koduyla birlikte 503 HTTP yanıt durum kodunu alır.

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

NoActiveTarget hata koduna sahip 503 Hizmet Kullanılamıyor HTTP yanıtı, genellikle API Proxy'nizdeki hedef uç nokta yapılandırmasında bir veya daha fazla hedef sunucu kullandığınızda görülür.

Bu başucu kitabında, durum denetimi hatalarından kaynaklanan NoActiveTarget hata koduyla birlikte 503 Hizmet Kullanılamıyor durumu ele alınmaktadır. 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 API proxy'nizin hedef uç noktasında, hedef sunucu yük dengeleme yapılandırmasının bir parçası olarak bir Durum İzleyicisi yapılandırdıysanız gözlemlenir.

Bir hedef sunucu durum denetiminde başarısız olduğunda Edge bu sunucunun hata sayısını artırır. Bu sunucu için durum denetimi hatalarının sayısı önceden tanımlanmış eşiğe (<MaxFailures>) ulaşırsa İleti İşleyici, uyarı mesajını aşağıda gösterildiği gibi 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 yer alır. 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. LoadBalancer yapılandırmasında yapılandırılan tüm hedef sunucular MaxFailure sayısına ulaştığında, sonraki API istekleri NoActiveTarget hata koduyla 503 Service Kullanılamıyor şeklinde yanıtlanır.

Durum İzleme'yi kullanmak, Apigee Edge'in bir hedef sunucu iyi duruma geldiğinde API Proxy'sini yeniden dağıtmak zorunda kalmadan otomatik olarak rotasyona tekrar eklemesine yardımcı olur.

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

Yaygın teşhis adımları

Başarısız isteğin ileti kimliğini belirleme

Yaygın hata mesajları

Hedef sunucular kullanıldığında ve Mesaj İşleyici arka uç sunucusuna bağlanmaya çalışırken bir hata oluştuğunda Mesaj İşleyici günlüklerinde sık karşılaşılan birkaç hata mesajı gösterilir. Bu hatalar, hataya neden olan gerçek istisna/hata mesajından sonra günlüğe kaydedilir.

Mesaj İşleyici günlüklerinde (/opt/apigee/var/log/edge-message-processor/logs/system.log) 503 Service Kullanılamıyor hatasıyla ilişkili olarak NoActiveTarget hata kodunu içeren yaygın hata mesajları (/opt/apigee/var/log/edge-message-processor/logs/system.log) 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 hata nedeniyle arka uç sunucusuna gönderilemediğini gösterir. Sonuç olarak, Mesaj İşleyici, istemciye yanıt olarak NoActiveTarget hata koduyla birlikte 503 Service Kullanılamıyor ifadesini gönderir.

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

Teşhis

1. Başarısız isteğin mesaj kimliğini belirleyin.
2. İleti İşleyici günlüğünde (/opt/apigee/var/log/edge-message-processor/logs/system.log) ileti kimliğini arayın.
3. Mesaj kimliğine karşılık gelen sık karşılaşılan hata mesajlarını görürsünüz. Bununla birlikte, durum denetimi hatalarının gerçek nedenini öğrenmek için bu sık karşılaşılan hata mesajlarının üst kısmına gidin ve HEALTH MONITOR hataları olup olmadığını kontrol edin.

   Örneğin aşağıdaki HEALTH MONITOR hata mesajı, durum denetimi API isteği yapılırken bağlantı zaman aşımına uğrayarak Mesaj İşleyicinin başarısız olduğunu belirtir:

   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, Sağlık İzleyicisi'nde MaxFailure kez yapılandırılmışsa ş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. NoActiveTargets hata koduna sahip 503 yanıt koduyla karşılaştığınız belirli API Proxy'sinde kullanılan bir hedef sunucu için MaxFailure sayısına ulaşıldığından emin olun.

4. Yukarıdaki örnekte durum denetimi connection timed out hatasıyla başarısız oldu. telnet komutunu kullanarak Mesaj İşleyicilerin her birinden doğrudan belirli arka uç sunucusuna bağlanıp bağlanamadığınızı kontrol edin:

telnet <BackendServer-HostName> 443
      

5. Arka uç sunucusuna bağlanabiliyorsanız Arka uç sunucusuna bağlandı gibi bir mesaj görebilirsiniz. Öyleyse sorun geçici bir sorun olabilir. Çözüme kavuşturulmuş veya ara sıra ortaya çıkan bir sorun olabilir. 4. adımı birkaç kez (10'dan fazla kez) tekrarlayın ve çıkışı doğrulayın.
1. telnet komutuyla ilgili sürekli bir hata olmuyorsa sorun çözülmüş demektir. Durum denetimi hatalarının durup durmadığını tekrar kontrol edin. Yanıtınız evet ise başka bir işlem yapmanız gerekmez.
2. Arka uç sunucusuna telnet komutuyla aralıklı olarak bağlanamıyorsanız ağ sorunu veya arka uç sunucunuz meşgul olabilir.
6. Arka uç sunucusuna telnet komutuyla tutarlı bir şekilde bağlanamıyorsanız bu durum, belirli arka uç sunucusundaki Mesaj İşleyicilerden gelen trafiğe izin verilmemesinden kaynaklanabilir.

Çözünürlük

connection timed out hatası sürekli görülürse arka uç sunucusunda güvenlik duvarı kısıtlaması olmadığından ve Apigee Edge Mesaj İşleyicilerinden gelen trafiğe izin verdiğinden emin olun. Örneğin, Linux'ta, Mesaj İşleyicinin IP adreslerinden gelen trafiğe izin vermek için arka uç sunucuda iptables kullanabilirsiniz.

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 Desteği 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 İşleyici 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. Bununla birlikte, durum denetimi hatalarının gerçek nedenini öğrenmek için bu sık karşılaşılan hata mesajlarının üst kısmına gidin ve HEALTH MONITOR hataları 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, Sağlık Denetleyicisi'nde MaxFailure kez yapılandırılmışsa ş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. NoActiveTargets hata koduna sahip 503 yanıt koduyla karşılaştığınız belirli API Proxy'sinde kullanılan bir hedef sunucu için MaxFailure sayısına ulaşıldığından emin olun.

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'de güvenli çağrı (HTTPS) yapılmış olduğunu göstermektedir.

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

   • Güvenli hedef sunucu, güvenli olmayan bağlantı noktasıyla tanımlandı
   • Güvenli hedef sunucu tanımlandı ancak Durum İzleme özelliği güvenli olmayan bir bağlantı noktasıyla yapılandırılmış

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

   Senaryo 1: Güvenli olmayan bağlantı noktasıyla tanımlanmış güvenli hedef sunucu

   Tanımladığınız güvenli hedef sunucu varsa ancak 80 gibi güvenli olmayan bir bağlantı noktası varsa bu hatayı alırsınız. 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ı öğrenmek için TargetServer API'yi Alın'ı kullanın.

   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 SSLInfo bloğunda belirtildiği gibi güvenli bir sunucu olduğunu göstermektedir. Ancak, güvenli olmayan bir Bağlantı Noktası 80 ile yapılandırılmıştır.

   2. Şimdi, hedef uç nokta yapılandırmasında hedef sunucunun Durum İzleme yapılandırmasını kontrol edin:

      Durum İzleme 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>
                

      Yukarıdaki Durum Denetleyicisi yapılandırmasında <Port> öğesi belirtilmediğine dikkat edin. Bu durumda, Edge'in Mesaj İşleyicisi durum denetimi API çağrıları yapmak için hedef sunucu tanımında belirtilen bağlantı noktasını (80) kullanır.

   3. Yukarıdaki bilgilere göre bu hatanın nedeni, hedef sunucunun güvenli olmayan bir bağlantı noktası olan 80 ile güvenli bir sunucu olarak (SSLInfo bloğu etkin olduğu için) tanımlanmasıdır.

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

   2. Senaryo: Güvenli hedef sunucu tanımlandı ancak Durum İzleme özelliği güvenli olmayan bir bağlantı noktasıyla yapılandırılmış

   Güvenli bir hedef sunucu tanımladıysanız ancak Durum İzleme Aracı 80 gibi güvenli olmayan bir bağlantı noktasıyla yapılandırılmışsa bu hatayı alırsınız. 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ı öğrenmek için Get TargetServer API'yi kullanı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ğunda belirtildiği gibi güvenli bir sunucu olduğunu göstermektedir.

   2. Ardından, hedef uç nokta yapılandırmasındaki hedef sunucu için Durum İzleme yapılandırmasını kontrol edin:

      Durum İzleme 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 Denetleyicisi, <Port> öğesinde belirtildiği şekilde güvenli olmayan 80 numaralı Bağlantı Noktası ile yapılandırılmıştır.

   3. Yukarıdaki bilgilere göre bu hatanın nedeni, hedef sunucunun güvenli bir sunucu olarak tanımlanması (SSLInfo bloğu etkin olarak) ve 443 numaralı güvenli bağlantı noktasını kullanması, ancak Durum Denetleyicisi'nin güvenli olmayan 80 bağlantı noktasıyla (<Port> öğesinde belirtilir) durum denetimleri gerçekleştirecek şekilde yapılandırılmış olmasıdır.

      Yani bu durumda Edge, durum denetimi API'lerini güvenli olmayan bağlantı noktası 80 ile güvenli bir çağrı olarak oluşturur ve yukarıda belirtilen hatayla başarısız olur.

Çözünürlük

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

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

Teşhis

1. Başarısız isteğin mesaj kimliğini belirleyin.
2. İleti İşleyici günlüğünde (/opt/apigee/var/log/edge-message-processor/logs/system.log) ileti kimliğini arayın.
3. Mesaj kimliğine karşılık gelen sık karşılaşılan hata mesajlarını görürsünüz. Bununla birlikte, durum denetimi hatalarının gerçek nedenini öğrenmek için bu sık karşılaşılan hata mesajlarının üst kısmına gidin ve HEALTH MONITOR hataları 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, Sağlık Denetleyicisi'nde MaxFailure kez yapılandırılmışsa ş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. NoActiveTargets hata koduna sahip 503 yanıt koduyla karşılaştığınız belirli API Proxy'sinde kullanılan bir hedef sunucu için MaxFailure sayısına ulaşıldığından emin olun.

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 olmayan bağlantı noktası 443 üzerinde güvenli olmayan bir çağrı (HTTP) yapılmış olduğunu göstermektedir.

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

   • Güvenli olmayan hedef sunucu, güvenli bağlantı noktasıyla tanımlanmış
   • Güvenli olmayan hedef sunucu tanımlandı ancak Durum İzleme özelliği güvenli bir bağlantı noktasıyla yapılandırılmış

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

   Senaryo 1: Güvenli bağlantı noktasıyla tanımlanmış güvenli olmayan hedef sunucu

   443 gibi güvenli bir bağlantı noktası içeren ancak güvenli olmayan bir hedef sunucu tanımladıysanız bu hatayı alırsınız. 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ı öğrenmek için Get TargetServer API'yi kullanı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, SSLInfo bloğu olmadığından mocktarget hedef sunucusunun güvenli olmayan bir sunucu olduğunu göstermektedir. Ancak güvenli bir Bağlantı Noktası 443 ile yanlış yapılandırılmıştır.

   2. Şimdi, hedef uç nokta yapılandırmasında hedef sunucunun Durum İzleme yapılandırmasını kontrol edin:

      Durum İzleme 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>
                      

      Yukarıdaki Durum Monitörü yapılandırmasında <Port> öğesi belirtilmediğine dikkat edin. Bu durumda, Edge'in Mesaj İşleyicisi, hedef sunucu tanımında (443) belirtilen bağlantı noktasını kullanır.

   3. Yukarıdaki bilgilere göre bu hatanın nedeni, hedef sunucunun 443 numaralı güvenli bağlantı noktasıyla (SSLInfo bloğu tanımlanmadığı için) güvenli olmayan bir sunucu olarak tanımlanmasıdır.

      Yani 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.

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

   2. Senaryo: Güvenli olmayan hedef sunucu tanımlandı ancak Durum İzleme özelliği güvenli bir bağlantı noktasıyla yapılandırılmış

   Güvenli olmayan bir hedef sunucu tanımladıysanız ancak Durum Denetleyicisi 443 gibi güvenli bir bağlantı noktasıyla yapılandırılmışsa bu hatayı alırsınız. 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ı öğrenmek için Get TargetServer API'yi kullanı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 (SSLInfo bloğu bulunmadığından) güvenli olmayan bir bağlantı noktası olan 80 ile doğru şekilde yapılandırılmış olduğunu göstermektedir.

   2. Ardından, hedef uç nokta yapılandırmasındaki hedef sunucu için Durum İzleme yapılandırmasını kontrol edin:

      Durum İzleme 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 Denetleyicisi, <Port> öğesinde belirtildiği gibi güvenli bir Bağlantı Noktası 443 ile yapılandırılmıştır.

   3. Yukarıdaki bilgiler ışığında, bu hatanın nedeni, hedef sunucunun güvenli olmayan bağlantı noktası 80 ile doğru şekilde güvenli olmayan bir sunucu olarak tanımlanması (SSLInfo bloğunun tanımlanmadığı şekilde) ancak Durum İzleme aracının 443 güvenli bağlantı noktası (<Port> öğesinde belirtilir) ile durum denetimleri gerçekleştirecek şekilde yapılandırılmış olmasıdır.

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

Çözünürlük

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

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

Teşhis

1. Başarısız isteğin mesaj kimliğini belirleyin.
2. İleti İşleyici 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. Bununla birlikte, durum denetimi hatalarının gerçek nedenini öğrenmek için bu sık karşılaşılan hata mesajlarının üst kısmına gidin ve HEALTH MONITOR Hataları/Uyarıları olup olmadığını kontrol edin.

   Örneğin, aşağıdaki gibi bir SAĞLIK İZLEYİCİ 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, Sağlık Denetleyicisi'nde MaxFailure kez yapılandırılmışsa ş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. NoActiveTargets hata koduna sahip 503 yanıt koduyla karşılaştığınız belirli API Proxy'sinde kullanılan bir hedef sunucu için MaxFailure sayısına ulaşıldığından emin olun.

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ında, durum denetimi API'si için beklenen yanıt kodu 200 ancak alınan gerçek yanıtın 404 olduğu belirtilmektedir. Bu nedenle, bu bir hata olarak kabul edilir.

5. Durum denetimi API'sinden alınan hata yanıtının nedenini araştırmadan önce, Edge'in durum denetimi API'si için yanıt kodunu neden 200 olarak beklediğini belirleyin. Bunun için hedef uç nokta yapılandırmasındaki hedef sunucunun Durum İzleme yapılandırmasını kontrol edin:

   Durum İzleme 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 İzleme yapılandırmasının <SuccessResponse> öğesi altındaki 200 yanıt koduyla yapılandırıldığına dikkat edin. Dolayısıyla Edge, durum denetimi API'sinden 200 dışında herhangi bir yanıt kodu (400, 401, 404, 500 gibi) alırsa bu kod hata olarak değerlendirilir ve hata sayısını artırır.

6. Şimdi, durum denetimi API'sinden alınan hata yanıtının nedenini araştırmak için aşağıdaki adımları uygulayın:
1. Message Processor günlüğündeki uyarı mesajından önceki mesaja 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 bir çağrı yapabilir ve gerçek yanıtı kontrol edebilirsiniz

   curl -i https://mocktarget.apigee.net:443/status/200
             

   Yukarıdaki çağrının yanıtında, Message Processor günlüklerinde görüldüğü gibi 404 hatası verilir:

   < HTTP/2 404
             

3. Bu durum, durum denetimi URL'sine yapılan doğrudan çağrının bile aynı yanıt kodu 404 ile 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 İzleme yapılandırmasında yanlış URL kullanılmasından kaynaklanır. Örnek Hedef API'de doğru URL'nin https://mocktarget.apigee.net:443/statuscode/200 olduğu belirlendi.
7. Başka bir hata yanıtı alırsanız yukarıdaki adımları uygulayarak bu hatanın nedenini belirleyin. Gerekirse arka uç ekibinizle çalışın.

Çözünürlük

1. Arka uç sunucunuzdaki durum denetimi API ile ilgili sorunu düzeltin.
2. Yukarıda açıklanan örnekte belirtilen sorunu düzeltmek için:
1. Durum İzleme 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'sinde değişiklikleri kaydedin.

Sorun devam ederse Teşhis Bilgilerinin Toplanması Zorunlu bölümüne gidin.

API izlemeyi kullanarak sorunları teşhis edin

API Monitoring; hata, performans ve gecikme sorunlarını ve bunların kaynaklarını (ör. geliştirici uygulamaları, API proxy'leri, arka uç hedefleri veya API platformu) teşhis etmek için sorunlu alanları hızla izole etmenize olanak tanır.

API Monitoring'i kullanarak API'lerinizle ilgili 5xx sorunlarını nasıl gidereceğinizi gösteren örnek bir senaryoyu inceleyin. Örneğin, messaging.adaptors.http.flow.NoActiveTargets hata sayısı belirli bir eşiği aştığında bilgilendirilecek bir uyarı ayarlamak isteyebilirsiniz.

Teşhis bilgileri toplanmalıdır

Yukarıdaki talimatları uygulamanıza rağmen sorun devam ederse lütfen aşağıdaki teşhis bilgilerini toplayın. Apigee Desteği ile iletişime geçin ve 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. NoActiveTarget hata koduyla birlikte 503 Hizmet Kullanılamıyor istekleri içeren 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. NoActiveTarget hata koduyla birlikte 503 Hizmet Kullanılamıyor istekleri içeren 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)