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ı hakkında daha fazla bilgi edinmek için aşağıdaki videolara göz atın:

Belirti

İstemci uygulaması, API proxy istekleri için Service Unavailable mesajı ve NoActiveTargets 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

NoActiveTargets hata koduyla birlikte 503 Service Unavailable 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 oyun kitabı, durum denetimi hataları nedeniyle oluşan NoActiveTargets hata koduyla birlikte 503 Hizmet Kullanılamıyor hatasını ele alı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ı

Sağlık durumu kontrolü hataları yalnızca API proxy'nizin hedef uç noktasında hedef sunucu yük dengeleme yapılandırmasının bir parçası olarak Sağlık durumu izleyicisi 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. Söz konusu sunucunun durum denetimi başarısızlıklarının sayısı önceden tanımlanmış eşiğe (<MaxFailures>) ulaşırsa, Mesaj İşleyici aşağıdaki uyarı mesajını 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 sayede, hangi hedef sunucunun MaxFailure sayısına ulaştığını anlayabilirsiniz:

• Hedef sunucu adı
• Kuruluş ve ortam adları
• API proxy'si 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 NoActiveTargets hata koduyla birlikte 503 Hizmet Kullanılamıyor olarak yanıtlanır.

Durum izleyiciyi kullanmak, API proxy'sini yeniden dağıtmaya gerek kalmadan hedef sunucunun sağlıklı hale geldiğinde Apigee Edge tarafından otomatik olarak rotasyona dahil edilmesine yardımcı olur.

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

Sık karşılaşılan teşhis adımları

Başarısız olan isteğin ileti kimliğini belirleyin.

Yaygın hata mesajları

Hedef sunucular kullanılırken ve Mesaj İşleyici, arka uç sunucuya bağlanmaya çalışırken bir hata oluşursa Mesaj İşleyici günlüklerinde birkaç yaygın hata mesajı görürsünüz. Bu hatalar, hataya neden olan gerçek istisna/hata mesajından sonra günlüğe kaydedilir.

Mesaj İşleyici günlüklerinde gözlemlenen yaygın hata mesajları (/opt/apigee/var/log/edge-message-processor/logs/system.log) ile ilgili olarak 503 Hizmet Kullanılamıyor hata kodu NoActiveTargets şeklindedir:

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ı, bir hata nedeniyle isteğin arka uç sunucusuna gönderilemediğini gösterir. Sonuç olarak, Mesaj İşleyici, istemciye yanıt olarak 503 Service Unavailable hatasını NoActiveTargets hata koduyla birlikte gönderir.

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

Teşhis

1. Başarısız olan isteğin mesaj kimliğini belirleyin.
2. Mesaj İş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. Ancak durum denetimi hatalarının gerçek nedenini öğrenmek için bu yaygın hata mesajlarının üzerine kaydırın ve HEALTH MONITOR hatalarını kontrol edin.

   Örneğin, aşağıdaki HEALTH MONITOR hata mesajı, sağlık kontrolü API isteği gönderilirken Mesaj İşleyicinin bağlantı zaman aşımına uğradığı için başarısız olduğunu gösterir:

   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 izleyicide yapılandırılan MaxFailure sayısı kadar tekrarlanırsa şu gibi 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 sayısının, NoActiveTargets hata koduyla 503 yanıt kodunu aldığınız belirli API proxy'sinde kullanılan hedef sunucu için ulaşıldığından emin olun.

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

telnet <BackendServer-HostName> 443
      

5. Arka uç sunucusuna bağlanabiliyorsanız Connected to backend-server (Arka uç sunucusuna bağlandı) gibi bir mesaj görebilirsiniz. Bu durumda sorun geçici olabilir ve çözülmüş veya aralıklı olarak yaşanıyor olabilir. 4. adımı birkaç kez (10'dan fazla) tekrarlayın ve çıkışı doğrulayın.
1. telnet komutunda sürekli olarak hata yoksa sorun çözülmüştür. Durum denetimi hatalarının durup durmadığını tekrar kontrol edin. Evetse başka bir işlem yapmanız gerekmez.
2. telnet komutuyla arka uç sunucuya aralıklı olarak bağlanamıyorsanız ağ sorunu olabilir veya arka uç sunucunuz meşgul olabilir.
6. telnet komutuyla arka uç sunucusuna sürekli olarak bağlanamıyorsanız bunun nedeni, belirli arka uç sunucusunda Mesaj İşleyiciler'den gelen trafiğe izin verilmemesi olabilir.

Çözünürlük

connection timed out hatası sürekli olarak gözlemleniyorsa arka uç sunucusunda güvenlik duvarı kısıtlaması olmadığından ve Apigee Edge Message Processors'dan gelen trafiğe izin verildiğinden emin olun. Örneğin, Linux'ta arka uç sunucusunda ileti işlemcisinin IP adreslerinden gelen trafiğe izin vermek için 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 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 olan isteğin mesaj kimliğini belirleyin.
2. Mesaj İş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. Ancak durum denetimi hatalarının gerçek nedenini öğrenmek için bu yaygın hata mesajlarının üzerine kaydırın ve HEALTH MONITOR hatalarını kontrol edin.

   Örneğin, aşağıda gösterildiği gibi bir SAĞLIK MONİTÖRÜ 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 izleyicide yapılandırılan MaxFailure kez tekrar ederse şu gibi 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 sayısının, NoActiveTargets hata koduyla 503 yanıt kodunu aldığınız belirli API proxy'sinde kullanılan hedef sunucu için ulaşıldığından emin olun.

4. Durum denetimi şu hatayla 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 80 numaralı bağlantı noktasında güvenli bir çağrı (HTTPS) yapılmasından kaynaklandığını gösteriyor.

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

   • Güvenli olmayan bağlantı noktasıyla tanımlanan güvenli hedef sunucu
   • Güvenli hedef sunucu tanımlanmış ancak durum izleme aracı güvenli olmayan bir bağlantı noktasıyla yapılandırılmış

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

   1. senaryo: Güvenli olmayan bağlantı noktasıyla tanımlanan güvenli hedef sunucu

   Güvenli bir hedef sunucu tanımladıysanız ancak 80 gibi güvenli olmayan bir bağlantı noktası kullandı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 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>
     <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österiyor. Ancak güvenli olmayan 80 numaralı bağlantı noktasıyla yapılandırılmıştır.

   2. Şimdi hedef uç nokta yapılandırmasındaki hedef sunucunun durum izleme yapılandırmasını kontrol edin:

      Durum İzleme Aracı 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 sağlık durumu izleme yapılandırmasında <Port> öğesinin belirtilmediğini unutmayın. Bu durumda, Edge'in mesaj işlemcisi, hedef sunucu tanımında belirtilen bağlantı noktasını (80) kullanarak sağlık durumu kontrolü API çağrıları yapar.

   3. Yukarıdaki bilgilere göre bu hatanın nedeni, hedef sunucunun güvenli bir sunucu olarak tanımlanmış (SSLInfo bloğu etkinleştirilmiş) olması ancak güvenli olmayan 80 numaralı bağlantı noktasını kullanmasıdır.

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

   2. senaryo: Güvenli hedef sunucu tanımlanmış ancak Health Monitor güvenli olmayan bir bağlantı noktasıyla yapılandırılmış

   Güvenli bir hedef sunucu tanımladıysanız ancak sağlık monitörü 80 gibi güvenli olmayan 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 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 SSLInfo bloğuyla belirtildiği gibi hedef sunucunun mocktarget güvenli bir sunucu olduğunu gösteriyor.

   2. Ardından, hedef uç nokta yapılandırmasındaki hedef sunucunun durum izleme yapılandırmasını kontrol edin:

      Durum İzleme Aracı 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, <Port> öğesinin gösterdiği gibi, sağlık izleme aracı güvenli olmayan 80 numaralı bağlantı noktasıyla 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 olduğundan) ve güvenli bağlantı noktası 443'ü kullanması ancak durum denetleyicinin durum denetimlerini güvenli olmayan bir bağlantı noktası 80 ile (<Port> öğesinde belirtildiği gibi) gerçekleştirecek şekilde yapılandırılmasıdır.

      Yani bu durumda Edge, durum denetimi API'lerini güvenli olmayan 80 numaralı bağlantı noktasıyla güvenli 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>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 olan isteğin mesaj kimliğini belirleyin.
2. Mesaj İş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. Ancak durum denetimi hatalarının gerçek nedenini öğrenmek için bu yaygın hata mesajlarının üzerine kaydırın ve HEALTH MONITOR hatalarını kontrol edin.

   Örneğin, aşağıda gösterildiği gibi bir SAĞLIK MONİTÖRÜ 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 izleyicide yapılandırılan MaxFailure kez tekrar ederse şu gibi 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 sayısının, NoActiveTargets hata koduyla 503 yanıt kodunu aldığınız belirli API proxy'sinde kullanılan hedef sunucu için ulaşıldığından emin olun.

4. Durum denetimi şu hatayla 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 bir çağrının (HTTP) güvenli 443 numaralı bağlantı noktasında yapılması olduğunu gösteriyor.

   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ımlanmış ancak sağlık izleme aracı güvenli bir bağlantı noktasıyla yapılandırılmış

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

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

   Güvenli olmayan bir hedef sunucu tanımladıysanız ancak 443 gibi güvenli bir bağlantı noktası kullandı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 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, SSLInfo bloğu olmadığı için tanımda hedef sunucunun mocktarget güvenli olmayan bir sunucu olduğu gösterilmektedir. Ancak güvenli bağlantı noktası 443 ile yanlış yapılandırılmış.

   2. Şimdi hedef uç nokta yapılandırmasındaki hedef sunucunun durum izleme yapılandırmasını kontrol edin:

      Durum İzleme Aracı 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 sağlık durumu izleme yapılandırmasında <Port> öğesinin belirtilmediğini unutmayın. Bu durumda, Edge'in mesaj işlemcisi, hedef sunucu tanımında belirtilen bağlantı noktasını (443) kullanır.

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

      Yani Edge, durum denetimlerini güvenli olmayan bir çağrı olarak güvenli 443 bağlantı noktasıyla 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ımlanmış ancak Health Monitor güvenli bir bağlantı noktasıyla yapılandırılmış

   Güvenli olmayan bir hedef sunucu tanımladıysanız ancak sağlık izleme aracı 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 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, hedef sunucunun mocktarget güvenli olmayan bir sunucu olduğunu (SSLInfo bloğu olmadığından) ve güvenli olmayan 80 numaralı bağlantı noktasıyla doğru şekilde yapılandırıldığını gösteriyor.

   2. Ardından, hedef uç nokta yapılandırmasındaki hedef sunucunun durum izleme yapılandırmasını kontrol edin:

      Durum İzleme Aracı 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, <Port> öğesinin belirttiği gibi, sağlık izleme aracı güvenli bir 443 numaralı bağlantı noktasıyla yapılandırılmıştır.

   3. Yukarıdaki bilgilere göre bu hatanın nedeni, hedef sunucunun güvenli olmayan bağlantı noktası 80 ile doğru şekilde güvenli olmayan bir sunucu (SSLInfo bloğu tanımlanmadığı için) olarak tanımlanması ancak durum izleyicinin güvenli bağlantı noktası 443 ile durum denetimleri yapacak şekilde (<Port> öğesinde belirtildiği gibi) yapılandırılmasıdır.

      Yani 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

<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 olan isteğin mesaj kimliğini belirleyin.
2. Mesaj İş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. Ancak durum denetimi hatalarının gerçek nedenini öğrenmek için bu yaygın hata mesajlarının üzerine kaydırın ve HEALTH MONITOR hatalarını/uyarılarını kontrol edin.

   Örneğin, aşağıda gösterildiği gibi bir SAĞLIK MONİTÖRÜ 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 izleyicide yapılandırılan MaxFailure kez tekrar ederse şu gibi 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 sayısının, NoActiveTargets hata koduyla 503 yanıt kodunu aldığınız belirli API proxy'sinde kullanılan hedef sunucu için 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 kontrolü API'si için beklenen yanıt kodunun 200 olduğu ancak alınan gerçek yanıtın 404 olduğu belirtiliyor. Bu nedenle, işlem başarısız olarak kabul edilir.

5. Durum denetimi API'sinden gelen hata yanıtının nedenini araştırmadan önce Edge'in durum denetimi API'si için neden yanıt kodunun 200 olmasını beklediğini belirleyin. Bunun için hedef uç nokta yapılandırmasındaki hedef sunucunun durum izleme yapılandırmasını kontrol edin:

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

   Sağlık durumu izleme yapılandırmasının, <SuccessResponse> öğesi altında 200 yanıt koduyla yapılandırıldığına dikkat edin. Bu, Edge'in durum denetimi API'sinden 200 dışında herhangi bir yanıt kodu (ör. 400, 401, 404, 500) alması durumunda bunun hata olarak değerlendirileceği ve hata sayısının artacağı anlamına gelir.

6. Şimdi, durum denetimi API'sinden gelen hata yanıtının nedenini araştırmak için aşağıdaki adımları uygulayın:
1. Mesaj İşleyici günlüğünde uyarı iletisinden ö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 mesajdaki durum denetimi URL'sini not edin.

2. İleti İşleyici'den bu URL'ye doğrudan çağrı yapabilir ve gerçek yanıtı kontrol edebilirsiniz.

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

   Yukarıdaki çağrıdan gelen yanıt, Mesaj İşleyici günlüklerinde görüldüğü gibi 404 sonucunu veriyor:

   < HTTP/2 404
             

3. Bu, sağlık durumu kontrolü URL'sine yapılan doğrudan çağrının bile aynı 404 yanıt koduyla başarısız olduğunu gösterir. Bu, durum kontrolü 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 verilen örnek durum denetimi API'sinde, sorunun nedeni Durum İzleyici yapılandırmasında yanlış bir URL kullanılmasıdır. Doğru URL'nin Mock Target API'den https://mocktarget.apigee.net:443/statuscode/200 olduğu bulundu.
7. Başka bir hata yanıtı alırsanız yukarıdaki adımları uygulayarak hatanın nedenini belirleyin. Gerekirse arka uç ekibinizle birlikte çalışın.

Çözünürlük

1. Arka uç sunucunuzdaki sağlık durumu kontrolü API'siyle ilgili sorunu düzeltin.
2. Yukarıda bahsedilen örnekteki sorunu düzeltmek için:
1. Sağlık 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 Must Gather Diagnostic Information (Teşhis Bilgileri Toplama) bölümüne gidin.

API izlemeyi kullanarak sorunları teşhis etme

API Monitoring, hata, performans ve gecikme sorunlarını ve bunların kaynağını (ör. geliştirici uygulamaları, API proxy'leri, arka uç hedefleri veya API platformu) teşhis etmek için sorunlu alanları hızlı bir şekilde izole etmenizi sağlar.

API İzleme'yi kullanarak API'lerinizdeki 5xx sorunlarını nasıl gidereceğinizi gösteren örnek bir senaryoyu adım adım inceleyin. Örneğin, messaging.adaptors.http.flow.NoActiveTargets hataların sayısı belirli bir eşiği aştığında bildirim almak için uyarı oluşturmak isteyebilirsiniz.

Teşhis bilgilerini toplamalıdır

Yukarıdaki talimatları uyguladıktan sonra sorun devam ederse lütfen aşağıdaki teşhis bilgilerini toplayın. Aşağıdaki bilgileri Apigee Destek Ekibi ile iletişime geçerek 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'sinin Adı
4. Hatayı yeniden oluşturmak için kullanılan curl komutunun tamamı
5. NoActiveTargets hata koduyla 503 Hizmet Kullanılamıyor hatası içeren istekleri içeren izleme dosyası
2. Private Cloud kullanıcısıysanız aşağıdaki bilgileri sağlayın:
   1. Gözlemlenen hata mesajının tamamı
   2. Ortam adı
   3. API proxy paketi
   4. NoActiveTargets hata koduyla 503 Hizmet Kullanılamıyor hatası içeren 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 İşleyici Günlükleri

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