Apigee Edge belgelerini görüntülüyorsunuz.
Apigee X belgelerine gidin. info
Belirti
İstemci uygulaması 502 Bad Gateway hatası alır. Mesaj İşleyici, bir arka uç sunucusundan yanıt almadığında bu hatayı istemci uygulamasına döndürür.
Hata mesajı
İstemci uygulaması aşağıdaki yanıt kodunu alır:
HTTP/1.1 502 Bad Gateway
Ayrıca, aşağıdaki hata mesajını da görebilirsiniz:
{
"fault": {
"faultstring":"Bad Gateway",
"detail":{
"errorcode":"messaging.adaptors.http.flow.BadGateway"
}
}
}
Olası Neden
Bu sorunun olası nedeni aşağıdaki tabloda listelenmiştir:
Neden | Açıklama | Sorun giderme adımları aşağıdaki kişiler tarafından gerçekleştirilebilir |
TLS/SSL el sıkışması zaman aşımı | İleti işleyici ile arka uç sunucu arasında TLS/SSL el sıkışma işlemi sırasında zaman aşımı yaşanır. | Edge Private ve Public Cloud kullanıcıları |
Neden: TLS/SSL el sıkışması zaman aşımı
Apigee Edge'de, Edge İleti İşlemcisi ile arka uç sunucu arasında TLS iletişimini etkinleştirmek için arka uç sunucuyla TLS/SSL bağlantısı oluşturabilirsiniz.
TLS/SSL el sıkışması birkaç adımdan oluşur. Bu hata genellikle Mesaj İşleyen ile arka uç sunucu arasındaki TLS/SSL el sıkışma süresi dolduğunda meydana gelir.
Teşhis
Bu bölümde, TLS/SSL el sıkışma zaman aşımının doğru şekilde nasıl teşhis edileceği açıklanmaktadır. Edge Özel Bulut ve Herkese Açık Bulut talimatları listelenmiştir.
İzleme oturumu çıkışını inceleme
Aşağıdaki adımlarda, Apigee Edge Trace aracı kullanılarak sorunun nasıl ön teşhis edileceği açıklanmaktadır.
- Edge kullanıcı arayüzünde, etkilenen API proxy'si için bir İzleme oturumu etkinleştirin.
Başarısız olan API isteğinin izlemesinde aşağıdaki hata görünüyorsa muhtemelen bir TLS/SSL el sıkışma zaman aşımı hatası oluşmuştur. Hatanın olası nedeni, arka uç sunucusunun güvenlik duvarının Apigee trafiğini engellemesidir.
- 502 Hatalı Ağ Geçidi hatasının 55 saniye sonra (Mesaj İşleyen'de ayarlanan varsayılan zaman aşımı süresi) oluşup oluşmadığını belirleyin. Hatanın 55 saniye sonra oluştuğunu görürseniz sorunun muhtemelen zaman aşımı nedeniyle ortaya çıktığını anlayabilirsiniz.
- Hatada messaging.adaptors.http.BadGateway hatası gösterilip gösterilmediğini belirleyin. Bu hata da genellikle zaman aşımı oluştuğunu gösterir.
Edge Private Cloud kullanıyorsanız aşağıdaki gibi izleme çıkışındaki X-Apigee.Message-ID alanının değerini not edin. Private Cloud kullanıcıları, daha sonra açıklandığı gibi daha ayrıntılı sorun giderme işlemleri yapmak için bu kimlik değerini kullanabilir.
İzleme yolunda Analytics Verileri Kaydedildi simgesini tıklayın:
Sayfayı aşağı kaydırıp X-Apigee.Message-ID adlı alanın değerini not edin.
Hatanın nedeninin TLS/SSL el sıkışma zaman aşımı olduğunu onaylamak için Public Cloud'u mu yoksa Private Cloud'u mu kullandığınıza bağlı olarak aşağıdaki bölümlerdeki adımları uygulayın.
Yalnızca Edge Private Cloud kullanıcıları için ek teşhis adımları
Apigee Edge Private Cloud kullanıyorsanız el sıkışma hatasının nedenini doğrulamak için aşağıdaki adımları uygulayabilirsiniz. Bu adımda, ilgili bilgiler için İleti İşleyen günlük dosyasını incelersiniz. Edge Public Cloud kullanıyorsanız bu bölümü atlayabilir ve Private ve Public Cloud Kullanıcıları İçin Daha Fazla Teşhis Adımları'na gidebilirsiniz.
telnet
komutunu kullanarak belirli bir arka uç sunucuya doğrudan her İleti İşleyen'den bağlanıp bağlanamadığınızı kontrol edin:Arka uç sunucu tek bir IP adresine çözülüyorsa şu komutu kullanın:
telnet BackendServer-IPaddress 443
Arka uç sunucusu birden fazla IP adresine çözümleniyorsa telnet komutunda arka uç sunucusunun ana makine adını aşağıdaki gibi kullanın:
telnet BackendServer-HostName 443
Arka uç sunucuya herhangi bir hata almadan bağlanabiliyorsanız sonraki adıma geçin.
telnet
komutu başarısız olursa mesaj işleyici ile arka uç sunucu arasındaki bağlantıyı kontrol etmek için ağ ekibinizle birlikte çalışmanız gerekir.El sıkışma hatası olduğuna dair kanıt için İleti İşleyen günlük dosyasını kontrol edin. Dosyayı açın:
/opt/apigee/var/log/edge-message-processor/system.log
ve benzersiz ileti kimliğini (izleme dosyasında bulduğunuz X-Apigee.Message-ID değerini) arayın. Aşağıda gösterildiği gibi, mesaj kimliğiyle ilişkili bir el sıkışma hata mesajı görüp görmediğinizi belirleyin:
org:xxx env:xxx api:xxx rev:x messageid:<MESSAGE_ID> NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeTimeout() : SSLClientChannel[Connected: Remote:X.X.X.X:443 Local:X.X.X.X]@739028 useCount=1 bytesRead=0 bytesWritten=0 age=55221ms lastIO=55221ms isOpen=true handshake timeout
Mesaj işleyicinin günlük dosyasında bu hatayı görürseniz daha ayrıntılı bir inceleme yapın. Edge Private ve Public Cloud kullanıcıları için daha fazla teşhis adımı başlıklı makaleyi inceleyin.
Günlük dosyasında el sıkışma mesajını görmüyorsanız Teşhis Bilgileri Toplanması Gerekir başlıklı makaleyi inceleyin.
Edge Private ve Public Cloud kullanıcıları için daha fazla teşhis adımı
Sorunu daha ayrıntılı olarak belirlemek için tcpdump aracını kullanarak TLS/SSL el sıkışması sırasında zaman aşımı oluşup oluşmadığını doğrulamak amacıyla TCP/IP paketlerini analiz edebilirsiniz.
- Private Cloud kullanıcısıysanız arka uç sunucusunda veya Mesaj İşleyicide TCP/IP paketlerini yakalayabilirsiniz. Paketlerin şifresi arka uç sunucuda çözüldüğü için tercihen arka uç sunucuda yakalama yapın.
- Herkese açık bulut kullanıcısıysanız Mesaj İşleyici'ye erişiminiz yoktur. Ancak TCP/IP paketlerini arka uç sunucusunda yakalamak bir sorunu belirlemeye yardımcı olabilir.
TCP/IP paketlerini nerede yakalayacağınıza karar verdikten sonra, TCP/IP paketlerini yakalamak için aşağıdaki tcpdump komutunu kullanın.
tcpdump -i any -s 0 host <IP address> -w <File name>
TCP/IP paketlerini arka uç sunucuda alıyorsanız
tcpdump
komutunda Mesaj İşleyicisi'nin herkese açık IP adresini kullanın. Arka uç sunucu trafiğini incelemek için komutu kullanmayla ilgili yardım için tcpdump başlıklı makaleyi inceleyin.TCP/IP paketlerini Mesaj İşleyicide alıyorsanız
tcpdump
komutunda arka uç sunucunun herkese açık IP adresini kullanın. İleti İşleyen trafiğini incelemek için komutu kullanmayla ilgili yardım için tcpdump başlıklı makaleyi inceleyin.Arka uç sunucusu/Mesaj İşlemci için birden fazla IP adresi varsa başka bir
tcpdump
komut kullanımı denemeniz gerekir. Bu araç ve bu komutun diğer varyantları hakkında daha fazla bilgi için tcpdump'a bakın.
TCP/IP paketlerini Wireshark aracını veya benzer bir aracı kullanarak analiz edin. Aşağıdaki ekran görüntüsünde, Wireshark'taki TCP/IP paketleri gösterilmektedir.
Wireshark çıkışında, üç yönlü TCP el sıkışmasının ilk 3 pakette başarıyla tamamlandığını görebilirsiniz.
Ardından Mesaj İşleyen, 4. pakette "Client Hello" mesajını gönderir.
Arka uç sunucusundan onay almadığımız için Mesaj İşleyici, önceden tanımlanmış bir zaman aralığı bekledikten sonra 5, 6 ve 7. paketlerde "Client Hello" mesajını birden çok kez yeniden iletir.
İleti işleyici, 3 denemeden sonra herhangi bir onay almadığında bağlantıyı kapattığını belirtmek için arka uç sunucuya FIN, ACK mesajını gönderir.
Örnek Wireshark oturumunda gösterildiği gibi, arka uçla bağlantı başarılıdır (1. adım). Ancak arka uç sunucusu hiçbir yanıt vermediği için SSL el sıkışım işlemi zaman aşımına uğramıştır.
Bu başlıkta yer alan sorun giderme adımlarını uyguladıysanız ve TLS/SSL el sıkışma hatasının zaman aşımından kaynaklandığını belirlediyseniz Çözüm bölümüne gidin.
Sorun belirlemek için API Monitoring kullanma
API Monitoring, sorun alanlarını hızla izole ederek 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 etmenizi sağlar.
API Monitoring'i kullanarak API'lerinizle ilgili 5xx sorunlarını nasıl gidereceğinizi gösteren örnek bir senaryoyu adım adım uygulayın. Örneğin, messaging.adaptors.http.BadGateway hata sayısı belirli bir eşiği aştığında bildirim almak için bir uyarı oluşturmak isteyebilirsiniz.
Çözünürlük
SSL el sıkma zaman aşımları genellikle arka uç sunucusunda Apigee Edge'den gelen trafiği engelleyen güvenlik duvarı kısıtlamaları nedeniyle gerçekleşir. Teşhis adımlarını uygulayıp el sıkışma hatasının nedeninin bir zaman aşımı olduğunu belirlediyseniz, bunun nedenini belirlemek ve güvenlik duvarı kısıtlamalarını gidermek için ağ ekibinizle iletişime geçmeniz gerekir.
Güvenlik duvarı kısıtlamalarının farklı ağ katmanlarında uygulanabileceğini unutmayın. Apigee Edge ile arka uç sunucu arasında sorunsuz bir trafik akışı sağlamak için tüm ağ katmanlarındaki Mesaj İşleyen IP'leriyle ilgili kısıtlamaların kaldırıldığından emin olmanız önemlidir.
Güvenlik duvarı kısıtlaması yoksa ve/veya sorun devam ediyorsa Teşhis Bilgileri Toplanması Gerekiyor başlıklı makaleyi inceleyin.
Teşhis Bilgileri Toplanması Gerekir
Yukarıdaki talimatlar uygulandıktan sonra bile sorun devam ederse lütfen aşağıdaki teşhis bilgilerini toplayın. Apigee Edge 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
- Hatayı gösteren izleme dosyası
- Arka uç sunucuda yakalanan TCP/IP paketleri
- Private Cloud kullanıcısıysanız aşağıdaki bilgileri sağlayın:
- Tamamlanan Hata Mesajını gözlemledim
- API Proxy paketi
- Hatayı gösteren izleme dosyası
- Mesaj İşleyici günlükleri /opt/apigee/var/log/edge-message-processor/logs/system.log
- Arka uç sunucuda veya İleti İşleyicide yakalanan TCP/IP paketleri.
- Bu Başucu Kitabı'nda hangi bölümleri denediğinizle ilgili ayrıntılar ve bu sorunun çözümünü yavaşlatmamıza yardımcı olacak diğer bilgiler.