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 "Bad Gateway" mesajıyla birlikte 502 HTTP durum kodunu alır.

HTTP durum kodu 502, 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 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ç sunucusundan kaynaklanıyorsa şuna benzer bir mesaj görebilirsiniz. Arka uçtaki 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 Bad Gateway hatasına yol açabilecek olası nedenlerden bazıları şunlardır:

Neden Açıklama Aşağıdaki Durumlarda Geçerli Sorun Giderme Talimatları
Havuzda kullanılabilir MP yok Bu hata, havuzdaki tüm MP'ler kullanılamıyorsa (yani kapalı veya meşgullerse ve bu nedenle yanıt vermiyorlarsa) görülür. Edge Private Cloud kullanıcıları
Yönlendiriciler ve MP'ler arasındaki SSL yapılandırması yanlış Bu hata, istemcinin CA tarafından imzalanmış kök sertifikası Edge'in yönlendiricisinin güven deposunda eksikse görülür. Edge Private Cloud kullanıcıları
Arka uç sunucusundan hata Arka uç sunucusu başarısız olursa ve bu yanıtı gönderirse bu hata gözlemlenir. Edge Public ve Private Cloud kullanıcıları

Neden: Havuzda MP yok

Bu hata, yönlendirici belirli bir bölgedeki/veri merkezindeki tüm ileti işlemcilerin kullanılamadığını (ör. hepsinin kapalı olduğunu) tespit ederse oluşur.

Apigee Edge, belirli bir bölgedeki/veri merkezindeki gelen API trafiğinin (istekler) her zaman aynı bölgedeki/veri merkezindeki yönlendiricilerden mesaj işleyicilere (MP'ler) yönlendirileceği şekilde yapılandırılır. Bazı durumlarda Apigee Edge bileşenleri yalnızca bir bölgede/veri merkezinde kurulabilir. Bazı durumlarda ise birden fazla bölgede/veri merkezinde kurulabilir. Her bölgede/veri merkezinde iki veya daha fazla yönlendirici ve mesaj işlemci yapılandırılır.

Teşhis

  1. Birden fazla bölge/veri merkezi varsa API isteklerinin 502 Bad Gateway hatasıyla başarısız olduğu bölgeyi/veri merkezlerini belirleyin. Bunu, kullanıcıların 502 hatalarını gözlemlediği bölgeyi belirleyerek veya farklı bölgelere ait her bir yönlendiricideki /opt/apigee/var/log/edge-router/nginx/ dizininde NGINX erişim günlüklerini kontrol ederek bulabilirsiniz.
  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 ileti işlemcileri kapalı

  1. Belirli bir bölgedeki/veri merkezindeki Mesaj İşleyicilerin çalışıp çalışmadığını kontrol edin.
  2. Tüm Mesaj İşleyiciler kapalıysa bunları yeniden başlatın.

Çözünürlük

Aşağıdaki komutu kullanarak tüm ileti işlemcilerini yeniden başlatın:

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

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

Bu hata, yönlendiriciler belirli bir bölgedeki/veri merkezindeki tüm ileti işlemcilerin, devam eden istekleri işlemekle meşgul oldukları için kullanılamadığını tespit ettiğinde oluşur.

  1. Belirli bir bölgedeki/veri merkezindeki Mesaj İşleyicilerin çalışıp çalışmadığını kontrol edin.
  2. Tüm Mesaj İşleyiciler çalışır ve etkin durumdaysa Mesaj İşleyicilerde yüksek CPU kullanımı olup olmadığını kontrol edin. Ardından, aşağıdaki komutu kullanarak 30 saniyede bir üç iş parçacığı dökümü oluşturun:
    <JAVA_HOME>/bin/jstack -l <pid> > <filename>
  3. Mesaj İşleyici(ler) 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 Mesaj İşleyici'yi yeniden başlatın. CPU ve bellek kullanımını azaltmalıdı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çin ve thread dökümlerini, yığın dökümünü ve Message Processor günlüklerini (/opt/apigee/var/log/edge-message-processor/logs/system.log) paylaşın.

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

Teşhis

  1. NGINX erişim 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ını 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 ile mesaj işlemcisi arasındaki SSL el sıkışma işlemlerinin başarısız olduğunu gösterir.
  4. 1. ve 2. adımdaki hata mesajını dikkatlice incelerseniz Mesaj İşleyici ile iletişim kurmak için kullanılan bağlantı noktasının 8998 olduğunu görürsünüz. Bu, güvenli olmayan bir bağlantı noktasıdır 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ışması başarısız olur.
  5. Bu durum genellikle yönlendirici ile 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 çıkar. Burada belirtilen adımları uygulayın.
    Örneğin, bu hata
    1. /opt/apigee/customer/application/message-processor.properties as shown below
      içinde bağlantı noktası numarası 8443 yerine 8998 olarak belirtiliyor. 
              conf/message-processor-communication.properties+local.http.port=8998
    2. /opt/nginx/conf.d/* dizinindeki yönlendirici yapılandırma dosyaları silinmez ve SSL yapılandırması yapılırken yönlendirici yeniden başlatılmaz. Bu senaryoda, ileti işlemcilerinin bağlantı noktası numarasının yapılandırma dosyalarında 8998 olarak kaldığını fark edebilirsiniz.

Çözünürlük

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

Nedeni: Arka uç sunucusundan gelen hata

Teşhis

  1. Hata her seferinde oluşuyorsa başarısız olan isteklerin kullanıcı arayüzü izlemesini yakalayabilirsiniz. Başarısız olan bir isteği seçin ve izlemedeki çeşitli aşamalar arasında gezinin. Arka uç sunucusundan "502 Bad Gateway" hatası aldığınızı fark ederseniz sorun, arka uç sunucusunda bir hata oluşmuş olmasından kaynaklanabilir.
    Arka uç sunucusundan gelen 502 Hatalı Ağ Geçidi'ni gösteren izleme
  2. Sorun aralıklı olarak yaşanıyorsa ve izlemeyi yakalayamıyorsanız
    1. Herkese açık bulut kullanıcısıysanız API İzleme'yi kullanabilir ve 502 hatalarıyla ilgili ayrıntıları kontrol edebilirsiniz.
      1. Hata Kodunun messaging.adaptors.http.flow.ErrorResponseCode ve Hata Kaynağının target olduğunu görürseniz hatanın nedeni arka uç sunucusudur.
    2. Özel bulut kullanıcısıysanız NGINX erişim günlüklerini analiz edebilirsiniz.
      /opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log.
      Başarısız olan istekle ilgili girişi şu ş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 Kodunun messaging.adaptors.http.flow.ErrorResponseCode ve Hata Kaynağının target olduğunu görürseniz hatanın nedeni arka uç sunucusudur.

Çözünürlük

  1. Bu sorunu arka uçta düzeltmek için arka uç sunucusu 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).