502 Bozuk Ağ Geçidi Zaman Aşımı Hatası

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

Belirti

İstemci uygulaması 502 Bad Gateway hatası alıyor. 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ı
TLS/SSL el sıkışması zaman aşımı Mesaj İşleyici ile arka uç sunucusu arasındaki TLS/SSL el sıkışması sırasında zaman aşımı oluşur. Edge Private ve Public Cloud kullanıcıları

Neden: TLS/SSL el sıkışması zaman aşımı

Apigee Edge'de, Edge Mesaj İşleyici ile arka uç sunucusu arasında TLS iletişimi sağlamak için arka uç sunucusuna TLS/SSL bağlantısı oluşturabilirsiniz.

TLS/SSL el sıkışması birden fazla adım içerir. Bu hata genellikle Mesaj İşleyici ile arka uç sunucusu arasındaki TLS/SSL el sıkışması zaman aşımına uğradığında oluşur.

Teşhis

Bu bölümde, TLS/SSL el sıkışması zaman aşımının nasıl doğru şekilde teşhis edileceği açıklanmaktadır. Edge Private Cloud ve Public Cloud ile ilgili talimatlar listelenir.

İzleme oturumu çıktısını inceleme

Aşağıdaki adımlarda, Apigee Edge Trace aracını kullanarak sorunla ilgili ön teşhisin nasıl yapılacağı açıklanmaktadır.

  1. Edge kullanıcı arayüzünde, etkilenen API proxy'si için İzleme oturumu'nu etkinleştirin.

  2. Başarısız olan API isteğinin izlemesinde aşağıdakiler gösteriliyorsa büyük olasılıkla bir TLS/SSL el sıkışma zaman aşımı hatası oluşmuştur. Hatanın olası nedeni, arka uç sunucusu güvenlik duvarının Apigee'den gelen trafiği engellemesidir.

    1. 502 Bad Gateway hatasının, Mesaj İşleyici'de ayarlanan varsayılan zaman aşımı süresi olan 55 saniye sonra oluşup oluşmadığını belirleyin. Hatanın 55 saniye sonra oluştuğunu görürseniz sorunun olası nedeninin zaman aşımı olduğunu anlarsınız.
    2. Hatada messaging.adaptors.http.BadGateway hatasının gösterilip gösterilmediğini belirleyin. Bu hata da genellikle zaman aşımı olduğunu gösterir.

    3. Edge Private Cloud kullanıyorsanız izleme çıkışındaki X-Apigee.Message-ID alanının değerini aşağıdaki gibi not edin. Bir Özel Bulut kullanıcısı, daha sonra açıklanacağı gibi bu kimlik değerini kullanarak daha fazla sorun giderme işlemi yapabilir.

      1. İzleme yolunda Analytics Verileri Kaydedildi simgesini tıklayın:

      2. Aşağı kaydırın ve X-Apigee.Message-ID adlı alanın değerini not edin.

TLS/SSL el sıkışma zaman aşımının hatanın nedeni olduğunu doğrulamak için, genel bulutta mı yoksa özel bulutta mı olduğunuzu 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, Mesaj İşleyici günlük dosyasını ilgili bilgiler için incelersiniz. Edge Public Cloud kullanıyorsanız bu bölümü atlayıp Private ve Public Cloud kullanıcıları için ek teşhis adımları bölümüne gidebilirsiniz.

  1. telnet komutunu kullanarak belirli bir arka uç sunucusuna her ileti işlemcisinden doğrudan bağlanıp bağlanamadığınızı kontrol edin:

    1. Arka uç sunucusu tek bir IP adresine çözümleniyorsa şu komutu kullanın:

      telnet BackendServer-IPaddress 443

    2. Arka uç sunucu birden fazla IP adresine çözümleniyorsa telnet komutunda arka uç sunucunun ana makine adını aşağıdaki gibi kullanın:

      telnet BackendServer-HostName 443

    Arka uç sunucuya hatasız bir şekilde bağlanabiliyorsanız sonraki adıma geçin.

    telnet komutu başarısız olursa ileti işlemcisi ile arka uç sunucusu arasındaki bağlantıyı kontrol etmek için ağ ekibinizle birlikte çalışmanız gerekir.

  2. El sıkışma hatası kanıtı için Mesaj İşleyici 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ğeri) 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

Bu hatayı ileti işlemcisinin günlük dosyasında görürseniz araştırmaya devam edin. Edge özel ve genel bulut kullanıcıları için ek teşhis adımları başlıklı makaleye gidin.

El sıkışma mesajını günlük dosyasında görmüyorsanız Must Gather Diagnostic Information (Teşhis Bilgileri Toplanmalıdır) başlıklı makaleye gidin.

Edge özel ve genel bulut kullanıcıları için ek teşhis adımları

Sorunu daha da net bir şekilde belirlemek için tcpdump aracını kullanarak TCP/IP paketlerini analiz edebilir ve TLS/SSL el sıkışması sırasında zaman aşımının gerçekleşip gerçekleşmediğini doğrulayabilirsiniz.

  1. Özel bulut kullanıcısıysanız TCP/IP paketlerini arka uç sunucusunda veya mesaj işlemcisinde yakalayabilirsiniz. Paketlerin kodu arka uç sunucusunda çözüldüğünden, bu paketleri tercihen arka uç sunucusunda yakalayın.
  2. Herkese açık bulut kullanıcısıysanız Mesaj İşleyici'ye erişiminiz yoktur. Ancak arka uç sunucusunda TCP/IP paketlerini yakalamak sorunu belirlemenize yardımcı olabilir.

  3. TCP/IP paketlerinin nerede yakalanacağına 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>

    • Arka uç sunucusunda TCP/IP paketlerini alıyorsanız tcpdump komutunda Mesaj İşleyici'nin genel 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.

    • Mesaj İşleyici'de TCP/IP paketlerini alıyorsanız tcpdump komutunda arka uç sunucusunun genel IP adresini kullanın. İleti İşleyici trafiğini incelemek için komutu kullanma konusunda yardım almak istiyorsanız tcpdump başlıklı makaleyi inceleyin.

    • Arka uç sunucusu/Mesaj İşleyici için birden fazla IP adresi varsa başka bir tcpdump komut kullanımını denemeniz gerekir. Bu araç ve komutun diğer varyantları hakkında daha fazla bilgi için tcpdump'a bakın.

  4. TCP/IP paketlerini Wireshark aracı veya benzer bir araçla analiz edin. Aşağıdaki ekran görüntüsünde Wireshark'taki TCP/IP paketleri gösterilmektedir.

  5. Wireshark çıkışında, üç yönlü TCP el sıkışmasının ilk 3 pakette başarıyla tamamlandığına dikkat edin.

  6. Ardından, Mesaj İşleyici 4 numaralı pakette "Client Hello" mesajını gönderir.

  7. Arka uç sunucusundan onay gelmediği için Message Processor, önceden tanımlanmış bir süre bekledikten sonra 5, 6 ve 7 numaralı paketlerde "Client Hello" mesajını birden çok kez yeniden iletir.

  8. Mesaj İşleyici, 3 yeniden denemeden sonra herhangi bir onay almadığında bağlantıyı kapattığını belirtmek için arka uç sunucusuna FIN, ACK mesajını gönderir.

  9. Örnek Wireshark oturumunda gösterdiğiniz gibi, arka uca bağlantı başarılı (1. adım) ancak arka uç sunucusu hiçbir zaman yanıt vermediğinden SSL el sıkışması zaman aşımına uğradı.

Bu oyun kitabındaki sorun giderme adımlarını uyguladıysanız ve TLS/SSL el sıkışma hatasına zaman aşımının neden olduğunu belirlediyseniz Çözüm bölümüne gidin.

Bir sorunu belirlemek için API İzleme'yi kullanma

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.BadGateway hatalarının sayısı belirli bir eşiği aştığında bildirim almak için uyarı ayarlamak isteyebilirsiniz.

Çözünürlük

SSL el sıkışması zaman aşımları genellikle arka uç sunucusundaki güvenlik duvarı kısıtlamaları nedeniyle gerçekleşir. Bu kısıtlamalar, Apigee Edge'den gelen trafiği engeller. Teşhis adımlarını uyguladıysanız ve el sıkışma hatasının nedeninin zaman aşımı olduğunu belirlediyseniz nedeni tespit etmek ve güvenlik duvarı kısıtlamalarını düzeltmek 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ç sunucusu arasında sorunsuz trafik akışı sağlamak için tüm ağ katmanlarındaki Mesaj İşleyici 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 Must Gather Diagnostic Information (Gerekli Teşhis Bilgilerini Toplama) bölümüne gidin.

Toplanması Gereken Teşhis Bilgileri

Yukarıdaki talimatları uyguladıktan sonra sorun devam ederse lütfen aşağıdaki teşhis bilgilerini toplayın. Aşağıdaki bilgileri Apigee Edge 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. Hatayı gösteren izleme dosyası
    6. Arka uç sunucusunda yakalanan TCP/IP paketleri
  2. Private Cloud kullanıcısıysanız aşağıdaki bilgileri sağlayın:
    1. Gözlemlenen hata mesajının tamamı
    2. API proxy paketi
    3. Hatayı gösteren izleme dosyası
    4. Mesaj İşleyici günlükleri /opt/apigee/var/log/edge-message-processor/logs/system.log
    5. Arka uç sunucusunda veya Mesaj İşleyicisinde yakalanan TCP/IP paketleri.
  3. Bu Playbook'taki hangi bölümleri denediğiniz ve bu sorunun çözümünü hızlandırmamıza yardımcı olacak diğer bilgiler.