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:
|
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 |
|
Edge Private Cloud kullanıcıları |
Güvenli Bağlantı Noktasında Güvenli Olmayan İstek |
|
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:
- İ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.
- Başarısız isteklerden birini seçin.
- 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.
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:
- NGINX erişim günlüklerini kontrol edin: (
/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log
) - 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.
- 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ş
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
- Başarısız isteğin mesaj kimliğini belirleyin.
- İleti İşleyen günlüğünde (
/opt/apigee/var/log/edge-message-processor/logs/system.log
) ileti kimliğini arayın. - 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. - Yukarıdaki örnekte durum denetimi
connection timed out
hatası nedeniyle başarısız olmuştur. Her birtelnet
komutunu kullanarak mesaj işleyenler: - 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.
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.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.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.
telnet <BackendServer-HostName> 443
Çö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
- Başarısız isteğin mesaj kimliğini belirleyin.
- İleti İşleyen günlüğünde (
/opt/apigee/var/log/edge-message-processor/logs/system.log
) ileti kimliğini arayın. - İ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. - 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:
- Hedef uç nokta yapılandırmasında kullanılan hedef sunucunun tanımını kontrol edin.
- Ş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. - 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.
Ş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.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:
- 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. - 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. - 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:
- 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>
. - API Proxy'sinde yapılan değişiklikleri kaydedin.
Neden: Güvenli bir bağlantı noktasında güvenli olmayan istek
Teşhis
- Başarısız isteğin mesaj kimliğini belirleyin.
- İleti İşleyen günlüğünde (
/opt/apigee/var/log/edge-message-processor/logs/system.log
) ileti kimliğini arayın. - 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. - 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:
- 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. - Ş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. - 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:
- 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. - 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. - 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:
<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>
- API Proxy'sinde yapılan değişiklikleri kaydedin.
Neden: Durum denetimi API'si hatayla yanıt veriyor
Teşhis
- Başarısız isteğin mesaj kimliğini belirleyin.
- İleti İşleyen günlüğünde (
/opt/apigee/var/log/edge-message-processor/logs/system.log
) ileti kimliğini arayın. - İ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. - 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.
- 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. - Şimdi, durum denetimi API'sinde hata yanıtının nedenini incelemek için aşağıdaki adımları uygulayın:
- 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.
- 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
- 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.
- 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. - 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
- Arka uç sunucunuzdaki durum denetimi API'siyle ilgili sorunu düzeltin.
- Yukarıda açıklanan örnekteki sorunu düzeltmek için:
- 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>
- 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:
- Herkese Açık Bulut kullanıcısıysanız aşağıdaki bilgileri sağlayın:
- Kuruluş Adı
- Ortam Adı
- API Proxy Adı
- Hatayı yeniden oluşturmak için curl komutunu tamamlayın
- 503 hizmeti kullanılamıyor durumuna sahip istekleri içeren ve NoActiveTarget hata koduna sahip izleme dosyası
- Private Cloud kullanıcısıysanız aşağıdaki bilgileri sağlayın:
- Tam Hata Mesajı gözlemlendi
- Ortam Adı
- API Proxy paketi
- 503 hizmeti kullanılamıyor durumuna sahip istekleri içeren ve NoActiveTarget hata koduna sahip izleme dosyası
- NGINX Erişim Günlükleri
(
/opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log
) - Mesaj İşlemci Günlükleri
(
/opt/apigee/var/log/edge-message-processor/logs/system.log
)