502 Bozuk Ağ Geçidi

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

Belirti

İstemci uygulaması, API çağrılarına yanıt olarak "Hatalı Ağ Geçidi" mesajıyla birlikte 502 HTTP durum kodunu alır.

502 HTTP durum kodu, istemcinin arka uç sunucularından isteği yerine getirmesi gereken geçerli bir yanıt alamadığı 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 mesajlarını da görebilirsiniz:

<html>
<head>
<title>Error</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>An error occurred.</h1>
<p>Sorry, the page you are looking for is currently unavailable.<br/>
Please try again later.</p>
</body>
</html>

Hata arka uç sunucudan geliyorsa aşağıdakine benzer bir hata görebilirsiniz. Arka uçtan gelen hata mesajı tamamen uygulamaya bağlıdır.

<html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
</body>
</html>

Olası Nedenler

Apigee Edge üzerinden geçen API'lerde 502 Hatalı Ağ Geçidi hatasına yol açabilecek bazı olası nedenler şunlardır:

Neden Açıklama Geçerli Sorun Giderme Talimatları
Havuzda milletvekili yok Bu hata, havuzdaki tüm parlamento mensupları kullanılamıyorsa, yani hizmet dışı veya meşgul oldukları için yanıt vermiyorsa görülür. Edge Private Cloud kullanıcıları
Yönlendiriciler ve MP'ler arasında yanlış SSL yapılandırması Bu hata, Edge'in Yönlendiricisinin güven deposunda istemcinin CA imzalı kök sertifikası yoksa görülür. Edge Private Cloud kullanıcıları
Arka uç sunucudaki hata Arka uç sunucusu başarısız olursa ve bu yanıtı gönderirse bu hata dikkate alınır. Edge Herkese Açık ve Private Cloud kullanıcıları

Neden: Havuzda parlamento üyesi yok

Bu hata, Yönlendirici belirli bir bölgedeki/veri işleme merkezlerindeki hiçbir Mesaj İşleyicilerinin kullanılamadığını belirlerse (örneğin, hepsi devre dışıysa) ortaya çıkar.

Apigee Edge, belirli bir bölgede/veri merkezinden gelen API trafiği (istekler) her zaman yönlendiricilerden aynı bölgedeki mesaj işleyenlere (MP'ler) yönlendirilecek şekilde yapılandırılır. Apigee Edge bileşenleri bazı durumlarda yalnızca bir bölgede/veri merkezinde, bazı durumlarda ise birden fazla bölgede/veri merkezinde kurulabilir. Her bölge/veri merkezinde iki veya daha fazla yönlendirici ve mesaj işlemcisi yapılandırılmış olur.

Teşhis

  1. Birden fazla bölge/veri merkezi varsa API isteklerinin 502 Hatalı Ağ Geçidi hatasıyla başarısız olduğu bölgeyi/veri merkezlerini belirleyin. Kullanıcıların 502 hatalarını gözlemlediği bölgeyi tespit ederek veya farklı bölgelere ait olan her yönlendiricide /opt/apigee/var/log/edge-router/nginx/ dizinindeki NGINX Access günlüklerini kontrol ederek bu bilgiye ulaşabilirsiniz.
  2. NGINX hata günlüklerinde (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log) aşağıdaki hatayı görürsünüz
    2019/06/24 15:26:00 [error] 4796#4796: *56357443 no live upstreams while connecting to upstream, client: <Router_IP_address>, server: <HostAlias>, request: "PUT <BasePath> HTTP/1.1", upstream: "http://<ListOfMP-IP_R-MP-Port>/<BasePath>", host: "<HostAlias>"
    

1. Senaryo: Tüm İleti İşleyicileri çalışmıyor

  1. Belirli bir bölgedeki/veri merkezindeki Mesaj İşleyicilerinin çalışır durumda olup olmadığını kontrol edin.
  2. Tüm İleti İşleyicileri kapalıysa yeniden başlatın.

Çözünürlük

Aşağıdaki komutu kullanarak tüm İleti İşleyicileri yeniden başlatın:

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

2. Senaryo: Tüm Mesaj İşleyicileri devam eden istekleri işlemekle meşgul

Yönlendiriciler, belirli bir bölgedeki/veri merkezindeki hiçbir Mesaj İşleyicilerinin devam eden istekleri işlemekle meşgul olduğu için kullanılamaz olduğunu belirlerse bu hata oluşur.

  1. Belirli bir bölgedeki/veri merkezindeki Mesaj İşleyicilerinin çalışır durumda olup olmadığını kontrol edin.
  2. Tüm Mesaj İşleyicileri çalışır durumda ve etkinse Mesaj İşleyicilerin yüksek CPU kullanımı yaşayıp yaşamadığını kontrol edin. Ardından aşağıdaki komutu kullanarak her 30 saniyede bir üç iş parçacığı dökümü oluşturun:
    <JAVA_HOME>/bin/jstack -l <pid> > <filename>
    
  3. Mesaj İşleyicileri yüksek bellek kullanımı yaşıyorsa aşağıdaki komutu kullanarak bir yığın dökümü oluşturun:
    sudo -u apigee /bin/jmap -dump:live,format=b,file= 
    
  4. Aşağıdaki komutu kullanarak İleti İşleyici'yi yeniden başlatın. CPU ve Belleği azaltır:
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
    
  5. Sorunun devam edip etmediğini doğrulamak için API çağrılarını izleyin.
  6. Yüksek CPU/bellek kullanımının nedenini araştırmaya yardımcı olması için Apigee Destek Ekibi ile iletişime geçerek iş parçacığı dökümlerini, yığın dökümünü ve Mesaj İşleyici günlüklerini (/opt/apigee/var/log/edge-message-processor/logs/system.log) sağlayın.

Neden: Yönlendiriciler ve MP'ler arasında yanlış SSL yapılandırması

Teşhis

  1. NGINX Access günlüklerini (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log) kontrol edin. Aşağıda gösterildiği gibi 502 yanıtı görürsünüz:
        2019-07-23T12:13:42+03:00	sc-10-254-226-23	10.X.X.X:53634	10.X.X.X:8998	0.000	-	-	502	502	189	344	GET <path> curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2	<host alias>	mp-10-254-226-23-23706-8552529-1	10.129.107.101	-	-	-1	-	-	dc-2	gateway-2	green	-	gateway-2	dc-2	op	pilot	http	-
    
  2. NGINX Hata günlüklerini (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log) kontrol edin. Aşağıdaki gibi hatalar görürsünüz:
    	2019/07/30 17:02:24 [error] 7691#7691: *11753633 peer closed connection in SSL handshake while SSL handshaking to upstream, client: X.X.X.X, server: <HostAlias>, request: "GET /no-target HTTP/1.1", upstream: "https://X.X.X.X:8998/no-target", host: "<HostAlias>"
    
  3. Bu, Yönlendirici ve İleti İşleyici arasındaki SSL el sıkışma başarısızlığını gösterir.
  4. 1. ve 2. adımlardaki hata mesajında dikkatli bir şekilde fark ettiyseniz İleti İşleyici ile iletişim kurmak için kullanılan #numaralı bağlantı noktası, güvenli olmayan bir bağlantı noktası olan 8998'dir ancak protokol SSL'dir (https). Genellikle kullanılan güvenli bağlantı noktası numarası 8443'tür. Güvenli iletişim için güvenli olmayan bir bağlantı noktası kullanıldığından, SSL el sıkışma hatasına neden olur.
  5. Bu durum genellikle, Yönlendirici ve Mesaj İşleyici arasında SSL'yi yapılandırırken herhangi bir adımı atladıysanız veya yanlış değerler ayarladıysanız ortaya çıkabilir. Burada açıklanan adımlara bakın.
    Örneğin bu hata,
    1. Bağlantı noktası numarası, /opt/apigee/customer/application/message-processor.properties as shown below bölgesinde 8443 yerine 8998 olarak belirtilmiş
              conf/message-processor-communication.properties+local.http.port=8998
      
    2. /opt/nginx/conf.d/* dizini altındaki Yönlendirici yapılandırma dosyaları silinmez ve SSL yapılandırması yapılırken Yönlendirici yeniden başlatılmadı. Bu senaryoda, Mesaj İşleyicilerinin bağlantı noktası numarasının yapılandırma dosyalarında 8998 olarak kaldığını fark edebilirsiniz.

Çözünürlük

  1. Bir Yönlendirici ve İleti İşleyici arasında TLS'yi yapılandırma bölümünde verilen tüm adımların doğru bir şekilde uygulandığından emin olun.
  2. Sorun devam ederse Teşhis Bilgilerini Toplama bölümüne gidin.

Neden: Arka uç sunucudan gelen hata

Teşhis

  1. Hata her seferinde ortaya çıkıyorsa başarısız olan isteklerin kullanıcı arayüzü izlemesini yakalayabilirsiniz. Başarısız olan bir isteği seçin ve izdeki çeşitli aşamalar arasında gezinin. Arka uç sunucusunun kendisinden "502 Hatalı Ağ Geçidi" aldığınızı fark ederseniz arka uç sunucusunda bir hata oluşmuş olabilir.
    Arka uç sunucudan gelen 502 Hatalı Ağ Geçidini gösteren iz
  2. Sorun aralıklı olarak oluşuyorsa ve izi yakalayamıyorsanız
    1. Herkese Açık Bulut kullanıcısıysanız API İzleme'yi kullanarak 502 hatalarıyla ilgili ayrıntıları kontrol edebilirsiniz.
      1. Hata kodu messaging.adaptors.http.flow.ErrorResponseCode, Hata Kaynağı target ise hata arka uç sunucudan kaynaklanıyordur.
    2. Private Cloud kullanıcısıysanız NGINX Access günlüklerini analiz edebilirsiniz
      /opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log.
      Başarısız isteğin girişini aşağıdaki şekilde görürsünüz:
      2017-02-24T14:42:12+00:00	rt-01	192.8.155.2:18118	192.168.84.166:8998	10.225	-	-	502	502	440	0	GET /adv-eadlg-test/documents?type=doctype HTTP/1.1	rt-02efawae234-1234	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36	myorg-dev.apigee.net	 rt-02efawae234-1234	6	-	false	target	messaging.adaptors.http.flow.ErrorResponseCode	null/null	-	/organizations/myorg/environments/dev/apiproxies/api123
      
      1. Hata kodu messaging.adaptors.http.flow.ErrorResponseCode, Hata Kaynağı target ise hata arka uç sunucudan kaynaklanıyordur.

Çözünürlük

  1. Arka uçtaki bu sorunu düzeltmek için arka uç sunucu ekibinizle birlikte çalışın.

Teşhis Bilgilerini Toplama

  1. NGINX Erişim günlükleri
    (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log)
    ve Hata günlükleri
    (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log).
  2. Mesaj İşleyici günlükleri
    (/opt/apigee/var/log/edge-message-processor/logs/system.log).