502 Hatalı Ağ Geçidi Beklenmeyen EOF

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

Belirti

İstemci uygulaması, API çağrılarına yanıt olarak 502 HTTP durum kodunu ve Bad Gateway mesajını alır.

502 HTTP durum kodu, istemcinin isteği aslında karşılaması gereken arka uç sunucularından geçerli bir yanıt almadığı anlamına gelir.

Hata mesajları

İ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": "Unexpected EOF at target",
      "detail": {
           "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget"
       }
    }
}

Olası nedenler

502 Bad Gateway Error hatasının yaygın nedenlerinden biri Unexpected EOF hatasıdır. Bu hatanın nedenleri şunlar olabilir:

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

Hatayı teşhis etmek için aşağıdaki yöntemlerden herhangi birini kullanabilirsiniz:

• API İzleme
• İzleme aracı
• NGINX erişim günlükleri

Neden: Hedef sunucu yanlış yapılandırılmış

Hedef sunucu, TLS/SSL bağlantılarını destekleyecek şekilde düzgün yapılandırılmamış.

Teşhis

1. 502 hatası için ileti kimliğini, hata kodunu ve hata kaynağını belirlemek üzere API İzleme, İzleme aracı veya NGINX erişim günlüklerini kullanın.
2. Etkilenen API için kullanıcı arayüzünde izlemeyi etkinleştirin.
3. Başarısız olan API isteğinin izlemesinde aşağıdakiler gösteriliyorsa:
   1. 502 Bad Gateway hatası, hedef akış isteği başlatılır başlatılmaz görülür.
   2. error.class, messaging.adaptors.http.UnexpectedEOF. öğesini gösterir.

      Bu durumda, sorunun yanlış hedef sunucu yapılandırmasından kaynaklanması çok olasıdır.

4. Edge yönetim API'si çağrısını kullanarak hedef sunucu tanımını alın:
   1. Herkese açık bulut kullanıcısıysanız şu API'yi kullanın:

      curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>

   2. Private Cloud kullanıcısıysanız şu API'yi kullanın:

      curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>

      Hatalı TargetServer tanımı örneği:

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

5. Resimde gösterilen TargetServer tanımı, tipik yanlış yapılandırmalardan birinin örneğidir ve şu şekilde açıklanır:

   Hedef sunucunun mocktarget.apigee.net, 443 numaralı bağlantı noktasında güvenli (HTTPS) bağlantıları kabul edecek şekilde yapılandırıldığını varsayalım. Ancak hedef sunucu tanımına baktığınızda, güvenli bağlantılar için tasarlandığını gösteren başka özellik/işaret olmadığını görürsünüz. Bu durum, Edge'in belirli hedef sunucuya giden API isteklerini HTTP (güvenli olmayan) istekler olarak değerlendirmesine neden olur. Bu nedenle Edge, hedef sunucuyla SSL el sıkışması sürecini başlatmaz.

   Hedef sunucu, 443 üzerinde yalnızca HTTPS (SSL) isteklerini kabul edecek şekilde yapılandırıldığından Edge'den gelen isteği reddeder veya bağlantıyı kapatır. Bu nedenle, Mesaj İşleyici'de UnexpectedEOFAtTarget hatası alırsınız. Mesaj İşleyen, istemciye yanıt olarak 502 Bad Gateway gönderir.

Çözünürlük

Hedef sunucunun her zaman gereksinimlerinize göre doğru şekilde yapılandırıldığından emin olun.

Yukarıdaki örnekte, güvenli (HTTPS/SSL) bir hedef sunucuya istekte bulunmak istiyorsanız SSLInfo özelliklerini enabled işareti true olarak ayarlanmış şekilde eklemeniz gerekir. Hedef uç nokta tanımına hedef sunucu için SSLInfo özellikleri eklemek mümkün olsa da karışıklığı önlemek için SSLInfo özelliklerini hedef sunucu tanımının bir parçası olarak eklemeniz önerilir.

1. Arka uç hizmeti tek yönlü SSL iletişimi gerektiriyorsa:
   1. Aşağıda gösterildiği gibi TargetServer tanımında SSLInfo özelliklerini ekleyerek TLS/SSL'yi etkinleştirmeniz gerekir. Bu özelliklerde enabled işareti true olarak ayarlanır:

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

   2. Hedef sunucunun sertifikasını Edge'de doğrulamak istiyorsanız güvenli depoyu (hedef sunucunun sertifikasını içeren) da aşağıdaki gibi eklememiz gerekir:

      <TargetServer  name="mocktarget">
          <Host>mocktarget.apigee.net</Host>
          <Port>443</Port>
          <IsEnabled>true</IsEnabled>
          <SSLInfo>
              <Ciphers/>
              <ClientAuthEnabled>false</ClientAuthEnabled>
              <Enabled>true</Enabled>
              <IgnoreValidationErrors>false</IgnoreValidationErrors>
              <Protocols/>
              <TrustStore>mocktarget-truststore</TrustStore>
          </SSLInfo>
      </TargetServer>

2. Arka uç hizmeti iki yönlü SSL iletişimi gerektiriyorsa:
   1. Aşağıda gösterildiği gibi SSLInfo özelliklerinde ClientAuthEnabled, Keystore, KeyAlias ve Truststore işaretlerinin uygun şekilde ayarlanmış olması gerekir:

      <TargetServer  name="mocktarget">
           <IsEnabled>true</IsEnabled>
           <Host>www.example.com</Host>
           <Port>443</Port>
           <SSLInfo>
               <Ciphers/>
               <ClientAuthEnabled>true</ClientAuthEnabled>
               <Enabled>true</Enabled>
               <IgnoreValidationErrors>false</IgnoreValidationErrors>
               <KeyAlias>keystore-alias</KeyAlias>
               <KeyStore>keystore-name</KeyStore>
               <Protocols/>
               <TrustStore>truststore-name</TrustStore>
           </SSLInfo>
        </TargetServer >

Referanslar

Arka uç sunucularında yük dengeleme

Neden: Arka uç sunucusundan EOFException

Arka uç sunucusu, EOF'yi (Dosya Sonu) aniden gönderebilir.

Teşhis

1. 502 hatası için ileti kimliğini, hata kodunu ve hata kaynağını belirlemek üzere API İzleme, İzleme aracı veya NGINX erişim günlüklerini kullanın.
2. Mesaj İşleyici günlüklerini (/opt/apigee/var/log/edge-message-processor/logs/system.log) kontrol edin ve belirli API için eof unexpected olup olmadığını veya API isteği için benzersiz messageid olup olmadığını görmek için arama yapın. Ardından, benzersiz'yi arayabilirsiniz.

   Mesaj işleyici günlüğünden örnek istisna yığın izleme

   "message": "org:myorg env:test api:api-v1 rev:10 messageid:rrt-1-14707-63403485-19 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : SSLClientChannel[C:193.35.250.192:8443 Remote host:0.0.0.0:50100]@459069 useCount=6 bytesRead=0 bytesWritten=755 age=40107ms lastIO=12832ms .onExceptionRead exception: {}
   java.io.EOFException: eof unexpected
   at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) ~[nio-1.0.0.jar:na]
   at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) ~[nio-1.0.0.jar:na]
   at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:79) ~[http-1.0.0.jar:na]
   at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) [nio-1.0.0.jar:na]
   at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:123) [nio-1.0.0.jar:na]"

   Yukarıdaki örnekte, Mesaj İşleyici arka uç sunucusundan yanıt okumaya çalışırken java.io.EOFException: eof unexpected hatasının oluştuğunu görebilirsiniz. Bu istisna, dosyanın sonunun (EOF) veya akışın sonunun beklenmedik bir şekilde ulaşıldığını gösterir.

   Yani, Mesaj İşleyici API isteğini arka uç sunucusuna göndermiş ve yanıtı bekliyor veya okuyordu. Ancak arka uç sunucusu, Mesaj İşleyici yanıtı almadan veya yanıtı tamamen okuyamadan önce bağlantıyı aniden sonlandırdı.

3. Arka uç sunucu günlüklerinizi kontrol edin ve arka uç sunucunun bağlantıyı aniden sonlandırmasına neden olabilecek herhangi bir hata veya bilgi olup olmadığını görün. Herhangi bir hata/bilgi bulursanız Çözüm bölümüne gidin ve sorunu arka uç sunucunuzda uygun şekilde düzeltin.
4. Arka uç sunucunuzda herhangi bir hata veya bilgi bulamazsanız ileti işlemcilerinde tcpdump çıkışını toplayın:
   1. Arka uç sunucunuzun tek bir IP adresi varsa aşağıdaki komutu kullanın:

      tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME

   2. Arka uç sunucunuzun birden fazla IP adresi varsa aşağıdaki komutu kullanın:

      tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME

      Bu hata genellikle, Mesaj İşleyici isteği arka uç sunucusuna gönderir göndermez arka uç sunucusunun [FIN,ACK] ile yanıt vermesinden kaynaklanır.

5. Aşağıdaki tcpdump örneğini inceleyin.

   502 Bad Gateway Error (UnexpectedEOFAtTarget) meydana geldiğinde tcpdump örneği alındı

   

6. TCPDump çıkışında aşağıdaki etkinlik sırasını görüyorsunuz:
   1. 985 paketinde, Mesaj İşleyici API isteğini arka uç sunucusuna gönderir.
   2. 986 paketinde arka uç sunucusu hemen [FIN,ACK] ile yanıt verir.
   3. 987 paketinde, Mesaj İşleyici, arka uç sunucusuna [FIN,ACK] ile yanıt verir.
   4. Sonunda bağlantılar her iki taraftan da [ACK] ve [RST] ile kapatılır.
   5. Arka uç sunucusu [FIN,ACK] gönderdiğinden, Message Processor'da java.io.EOFException: eof unexpected istisnası alırsınız.
7. Bu durum, arka uç sunucusunda ağ sorunu varsa ortaya çıkabilir. Bu sorunu daha ayrıntılı bir şekilde araştırmak için ağ operasyonları ekibinizle iletişime geçin.

Çözünürlük

Arka uç sunucusundaki sorunu uygun şekilde düzeltin.

Sorun devam ederse ve 502 Bad Gateway Error ile ilgili sorun giderme konusunda yardıma ihtiyacınız varsa veya sorunun Edge'de olduğunu düşünüyorsanız Apigee Edge Destek Ekibi ile iletişime geçin.

Neden: Etkin tutma zaman aşımı yanlış yapılandırılmış

502 hatalarının nedeni bu olup olmadığını teşhis etmeden önce lütfen aşağıdaki kavramları okuyun.

Apigee'de kalıcı bağlantılar

Apigee, hedef arka uç sunucuyla iletişim kurarken varsayılan olarak (ve HTTP/1.1 standardına uygun olarak) kalıcı bağlantılar kullanır. Kalıcı bağlantılar, önceden oluşturulmuş bir TCP ve (varsa) TLS/SSL bağlantısının yeniden kullanılmasına izin vererek performansı artırabilir. Bu da gecikme ek yüklerini azaltır. Bağlantının ne kadar süreyle devam etmesi gerektiği, keep alive timeout (keepalive.timeout.millis) özelliğiyle kontrol edilir.

Hem arka uç sunucu hem de Apigee Mesaj İşleyici, bağlantıları açık tutmak için keep-alive zaman aşımlarını kullanır. Etkin tutma zaman aşımı süresi içinde veri alınmadığında arka uç sunucusu veya mesaj işlemcisi, diğeriyle olan bağlantıyı kapatabilir.

Apigee'deki bir Mesaj İşleyici'ye dağıtılan API proxy'lerinde, geçersiz kılınmadığı sürece varsayılan olarak 60s değerine ayarlanmış bir etkin tutma zaman aşımı vardır. 60s için veri alınmadığında Apigee, arka uç sunucusuyla bağlantıyı kapatır. Arka uç sunucusu, etkin tutma zaman aşımını da korur ve bu süre dolduğunda arka uç sunucusu, Mesaj İşleyici ile bağlantıyı kapatır.

Yanlış etkin tutma zaman aşımı yapılandırmasının etkisi

Apigee veya arka uç sunucusu yanlış etkin tutma zaman aşımlarıyla yapılandırılırsa bu durum, arka uç sunucusunun bir kaynak isteğine yanıt olarak beklenmedik bir End Of File (FIN) göndermesine neden olan bir yarış durumuyla sonuçlanır.

Örneğin, API proxy'sinde veya mesaj işleyicide etkin tutma zaman aşımı, yukarı akış arka uç sunucusunun zaman aşımından büyük ya da ona eşit bir değerle yapılandırılırsa aşağıdaki yarış durumu oluşabilir. Yani, Mesaj İşleyici, arka uç sunucunun etkin tutma zaman aşımı eşiğine çok yaklaşana kadar herhangi bir veri almazsa bir istek gelir ve mevcut bağlantı kullanılarak arka uç sunucuya gönderilir. Bu durum, aşağıda açıklandığı gibi 502 Bad Gateway nedeniyle beklenmedik EOF hatasına yol açabilir:

1. Hem Mesaj İşleyici'de hem de arka uç sunucusunda ayarlanan etkin tutma zaman aşımının 60 saniye olduğunu ve önceki istek belirli Mesaj İşleyici tarafından işlendikten sonraki 59 saniyeye kadar yeni bir istek gelmediğini varsayalım.
2. Mesaj İşleyici, 59. saniyede gelen isteği mevcut bağlantıyı kullanarak (keep-alive zaman aşımı henüz geçmediği için) işler ve isteği arka uç sunucusuna gönderir.
3. Ancak istek arka uç sunucusuna ulaşmadan önce arka uç sunucusunda etkin tutma zaman aşımı eşiği aşılmıştır.
4. Mesaj İşleyici'nin kaynak isteği devam ediyor ancak arka uç sunucusu, Mesaj İşleyici'ye FIN paketi göndererek bağlantıyı kapatmaya çalışıyor.
5. İleti İşleyici, verilerin alınmasını beklerken bunun yerine beklenmedik bir FIN alır ve bağlantı sonlandırılır.
6. Bu durum, Unexpected EOF ile sonuçlanır ve ardından Mesaj İşleyici tarafından istemciye 502 döndürülür.

Bu durumda, hem Mesaj İşleyici'de hem de arka uç sunucusunda aynı 60 saniyelik etkin tutma zaman aşımı değeri yapılandırıldığından 502 hatasının oluştuğunu gözlemledik. Benzer şekilde, bu sorun, ileti işlemcisinde etkin tutma zaman aşımı için arka uç sunucusundakinden daha yüksek bir değer yapılandırılırsa da oluşabilir.

Teşhis

1. Herkese açık bulut kullanıcısıysanız:
   1. API İzleme veya İzleme aracını kullanın (Yaygın teşhis adımları bölümünde açıklandığı gibi) ve aşağıdaki ayarların her ikisine de sahip olduğunuzu doğrulayın:
      • Hata kodu: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • Hata kaynağı: target
   2. Daha ayrıntılı inceleme için tcpdump kullanma bölümüne gidin.
2. Private Cloud kullanıcısıysanız:
   1. 502 hatasıyla ilgili ileti kimliğini, hata kodunu ve hata kaynağını belirlemek için İzleme aracını veya NGINX erişim günlüklerini kullanın.
   2. Mesaj İşleyici günlüğünde ileti kimliğini arayın
      (/opt/apigee/var/log/edge-message-processor/logs/system.log).
   3. Aşağıda gösterildiği gibi java.io.EOFEXception: eof unexpected simgesini görürsünüz:

      2020-11-22 14:42:39,917 org:myorg env:prod api:myproxy rev:1 messageid:myorg-opdk-dc1-node2-17812-56001-1  NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() :  ClientChannel[Connected: Remote:51.254.225.9:80 Local:10.154.0.61:35326]@12972 useCount=7 bytesRead=0 bytesWritten=159 age=7872ms  lastIO=479ms  isOpen=true.onExceptionRead exception: {}
              java.io.EOFException: eof unexpected
              at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45)
              at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103)
              at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:80)
              at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51)
              at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:220)

   4. java.io.EOFException: eof unexpected hatası, Mesaj İşleyici'nin arka uç sunucusundan yanıt okumayı beklerken EOF aldığını gösterir.
   5. Yukarıdaki hata mesajında useCount=7 özelliği, Mesaj İşleyici'nin bu bağlantıyı yaklaşık yedi kez yeniden kullandığını, bytesWritten=159 özelliği ise Mesaj İşleyici'nin arka uç sunucusuna 159 baytlık istek yükü gönderdiğini gösterir. Ancak beklenmeyen EOF oluştuğunda sıfır bayt geri alındı.

   6. Bu, Mesaj İşleyici'nin aynı bağlantıyı birden çok kez yeniden kullandığını ve bu durumda veri gönderdiğini ancak kısa bir süre sonra herhangi bir veri alınmadan önce EOF aldığını gösteriyor. Bu, arka uç sunucusunun etkin tutma zaman aşımının API proxy'sinde ayarlananla eşit veya daha kısa olma olasılığının yüksek olduğu anlamına gelir.

      Aşağıda açıklandığı gibi tcpdump yardımıyla daha ayrıntılı bir inceleme yapabilirsiniz.

tcpdump'ı kullanma

1. Aşağıdaki komutla arka uç sunucusunda tcpdump yakalayın:

   tcpdump -i any -s 0 host MP_IP_Address -w File_Name

2. Yakalanan tcpdump öğelerini analiz edin:

   Aşağıda örnek bir tcpdump çıkışı verilmiştir:

   

   Yukarıdaki örnekte tcpdump şunları görebilirsiniz:

   1. 5992, paketinde arka uç sunucusu GET isteği aldı.
   2. 6064 paketinde 200 OK. ile yanıt verilir.
   3. 6084 paketinde, arka uç sunucusu başka bir GET isteği aldı.
   4. 6154 paketinde 200 OK ile yanıt veriyor.
   5. 6228 paketinde arka uç sunucusu üçüncü bir GET isteği aldı.
   6. Bu kez, arka uç sunucusu bağlantının kapatılmasını başlatan Mesaj İşleyici'ye FIN, ACK döndürür (paket 6285).

   Bu örnekte aynı bağlantı iki kez başarıyla yeniden kullanıldı ancak üçüncü istekte arka uç sunucusu bağlantının kapatılmasını başlatırken Mesaj İşleyici, arka uç sunucusundan gelen verileri bekliyor. Bu durum, arka uç sunucusunun canlı tutma zaman aşımının büyük olasılıkla API proxy'sinde ayarlanan değerden daha kısa veya bu değere eşit olduğunu gösterir. Bunu doğrulamak için Apigee ve arka uç sunucusunda etkin tutma zaman aşımını karşılaştırma başlıklı makaleyi inceleyin.

Apigee ve arka uç sunucusunda etkin tutma zaman aşımını karşılaştırma

1. Apigee, varsayılan olarak canlı tutma zaman aşımı özelliği için 60 saniyelik bir değer kullanır.

2. Ancak, API proxy'sinde varsayılan değeri geçersiz kılmış olabilirsiniz. Bunu, 502 hataları veren başarısız API proxy'sindeki belirli TargetEndpoint tanımını kontrol ederek doğrulayabilirsiniz.

   Örnek TargetEndpoint yapılandırması:

   <TargetEndpoint name="default">
     <HTTPTargetConnection>
       <URL>https://mocktarget.apigee.net/json</URL>
       <Properties>
         <Property name="keepalive.timeout.millis">30000</Property>
       </Properties>
     </HTTPTargetConnection>
   </TargetEndpoint>

   Yukarıdaki örnekte, etkin tutma zaman aşımı özelliği 30 saniye (30000 milisaniye) değeriyle geçersiz kılınır.

3. Ardından, arka uç sunucunuzda yapılandırılan etkin tutma zaman aşımı özelliğini kontrol edin. Arka uç sunucunuzun 25 seconds değeriyle yapılandırıldığını varsayalım.
4. Apigee'deki keep alive zaman aşımı özelliğinin değerinin, yukarıdaki örnekte olduğu gibi arka uç sunucusundaki keep alive zaman aşımı özelliğinin değerinden daha yüksek olduğunu belirlerseniz 502 hatalarının nedeni budur.

Çözünürlük

Apigee'de (API Proxy ve Mesaj İşleyici bileşeninde) etkin tutma zaman aşımı özelliğinin her zaman arka uç sunucusundakinden daha düşük olduğundan emin olun.

1. Arka uç sunucusunda etkin tutma zaman aşımı için ayarlanan değeri belirleyin.
2. API proxy'sinde veya mesaj işlemcisinde, etkin tutma zaman aşımı özelliğinin arka uç sunucusunda ayarlanan değerden daha düşük olacağı şekilde etkin tutma zaman aşımı özelliği için uygun bir değer yapılandırın. Bu işlem için Mesaj işlemcilerinde etkin tutma zaman aşımını yapılandırma bölümünde açıklanan adımları kullanın.

Sorun devam ederse Toplanması gereken teşhis bilgileri başlıklı makaleye gidin.

En İyi Uygulama

Bu tür yarışma durumlarını ve 502 hatalarını önlemek için, aşağı akış bileşenlerinin her zaman yukarı akış sunucularında yapılandırılan değerden daha düşük bir keep-alive zaman aşımı eşiğine sahip olması önemle tavsiye edilir. Her bir aşağı akış atlaması, her bir yukarı akış atlamasından daha düşük olmalıdır. Apigee Edge'de aşağıdaki yönergeleri kullanmak iyi bir uygulamadır:

1. İstemci canlı tutma zaman aşımı, Edge yönlendirici canlı tutma zaman aşımından daha kısa olmalıdır.
2. Edge yönlendiricinin etkin kalma zaman aşımı, mesaj işlemcinin etkin kalma zaman aşımından daha kısa olmalıdır.
3. Mesaj işlemcisinin etkin kalma zaman aşımı, hedef sunucunun etkin kalma zaman aşımından daha kısa olmalıdır.
4. Apigee'nin önünde veya arkasında başka atlamalarınız varsa aynı kural uygulanmalıdır. Yukarı akışla bağlantıyı kapatma sorumluluğunu her zaman aşağı akış istemcisine bırakmalısınız.

Teşhis bilgilerini toplamalıdır

Yukarıdaki talimatları uyguladıktan sonra sorun devam ederse aşağıdaki teşhis bilgilerini toplayın ve Apigee Edge Destek Ekibi ile iletişime geçin.

Herkese açık bulut kullanıcısıysanız aşağıdaki bilgileri sağlayın:

• Kuruluş adı
• Ortam adı
• API proxy'si adı
• 502 hatasını yeniden oluşturmak için curl komutunu tamamlayın.
• 502 Bad Gateway - Unexpected EOF hatası içeren istekleri içeren izleme dosyası
• 502 hataları şu anda oluşmuyorsa geçmişte 502 hatalarının oluştuğu zaman aralığını saat dilimi bilgisiyle birlikte belirtin.

Private Cloud kullanıcısıysanız aşağıdaki bilgileri sağlayın:

• Başarısız olan istekler için gözlemlenen hata mesajının tamamı
• Gözlemlediğiniz kuruluş, ortam adı ve API proxy adı 502 hataları
• API proxy paketi
• 502 Bad Gateway - Unexpected EOF hatası içeren istekleri içeren izleme dosyası
• NGINX erişim günlükleri
  /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
• Mesaj İşleyici günlükleri
  /opt/apigee/var/log/edge-message-processor/logs/system.log
• 502 hatalarının oluştuğu saat dilimi bilgisiyle birlikte zaman aralığı
• Tcpdumps, hata oluştuğunda Mesaj İşleyiciler'de veya arka uç sunucusunda ya da her ikisinde de toplanır.