504 Ağ Geçidi Zaman Aşımı

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

Belirti

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

504 Gateway Timeout HTTP durum kodu, istemcinin bir API yürütülürken Edge Gateway'den veya arka uç sunucusundan zamanında yanıt almadığını gösterir.

Hata mesajları

İstemci uygulaması aşağıdaki yanıt kodunu alır:

HTTP/1.1 504 Gateway Timeout

Bazı durumlarda aşağıdaki hata mesajı da görülebilir:

{
   "fault": {
      "faultstring": "Gateway Timeout",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.GatewayTimeout"
       }
    }
}

Ağ geçidi zaman aşımlarına ne neden olur?

Edge platformu üzerinden yapılan bir API isteğinin tipik yolu, aşağıdaki şekilde gösterildiği gibi İstemci -> Yönlendirici -> Mesaj İşleyici -> Arka Uç Sunucusu olur:

Edge platformundaki istemci uygulaması, yönlendiriciler ve ileti işlemciler uygun zaman aşımı değerleriyle ayarlanır. Edge platformu, zaman aşımı değerlerine bağlı olarak her API isteği için belirli bir süre içinde yanıt gönderilmesini bekler. Belirtilen süre içinde yanıt almazsanız 504 Gateway Timeout Error döndürülür.

Aşağıdaki tabloda, Edge'de zaman aşımlarının ne zaman meydana gelebileceği hakkında daha fazla bilgi verilmektedir:

Olası nedenler

Edge'de 504 Gateway Timeout hatasının tipik nedenleri şunlardır:

Yavaş arka uç sunucu

Arka uç sunucusu çok yavaşsa veya API isteğini işlemek uzun sürüyorsa 504 Gateway Timeout hatası alırsınız. Yukarıdaki bölümde açıklandığı gibi, zaman aşımı aşağıdaki senaryolardan birinde gerçekleşebilir:

1. Arka uç sunucusu yanıt vermeden önce Mesaj İşleyici zaman aşımına uğruyor.
2. Yönlendiricinin zaman aşımı süresi, Mesaj İşleyici/arka uç sunucusu yanıt vermeden önce doluyor.
3. İstemci uygulaması, yönlendirici/mesaj işlemcisi/arka uç sunucusu yanıt vermeden önce zaman aşımına uğruyor.

Aşağıdaki bölümlerde, bu senaryoların her birinde sorunun nasıl teşhis edileceği ve çözüleceği açıklanmaktadır.

Senaryo 1 Arka uç sunucusu yanıt vermeden önce Mesaj İşleyicinin zaman aşımı gerçekleşiyor

Teşhis

504 Gateway Timeout hatasının yavaş arka uç sunucudan kaynaklanıp kaynaklanmadığını teşhis etmek için aşağıdaki prosedürleri kullanabilirsiniz.

1. Prosedür: Trace'i kullanma

Sorun devam ediyorsa (504 hataları görülmeye devam ediyorsa) aşağıdaki adımları uygulayın:

1. Etkilenen API'yi Edge kullanıcı arayüzünde izleyin. Hatayı bekleyin veya API çağrınız varsa bazı API çağrıları yapıp 504 Gateway Timeout hatasını yeniden oluşturun.
2. Hata oluştuktan sonra, yanıt kodunu 504 olarak gösteren isteği inceleyin.
3. Her aşamada geçen süreyi kontrol edin ve en çok zaman harcanan aşamayı not edin.
4. Aşağıdaki aşamalardan birinin hemen ardından en uzun süre geçen hatayı görürseniz bu, arka uç sunucusunun yavaş olduğunu veya isteği işlemek için uzun zaman aldığını gösterir:
   • İstek hedef sunucuya gönderildi
   • ServiceCallout politikası

Aşağıda, arka uç sunucunun 55 saniye sonra bile yanıt vermediğini ve 504 Gateway Timeout hatasına neden olduğunu gösteren örnek bir izleme verilmiştir:

Yukarıdaki izlemede, arka uç sunucusu yanıt vermediği için Mesaj İşleyici'nin zaman aşımı süresi 55002 ms sonra doluyor.

2. Prosedür: Mesaj işleyici günlüklerini kullanma

1. Mesaj İşleyici'nin günlüğünü kontrol edin (/opt/apigee/var/log/edge-message-processor/logs/system.log)

2. Belirli bir API proxy isteği için belirli bir zamanda Gateway Timeout ve onTimeoutRead hataları görüyorsanız bu, Mesaj İşleyici'nin zaman aşımına uğradığını gösterir.

   Ağ Geçidi Zaman Aşımı Hatası gösteren örnek Mesaj İşleyici günlüğü

   2015-09-29 20:16:54,340 org:myorg env:staging api:profiles rev:13 NIOThread@1
   ERROR ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
   AbstractResponseListener.onError(HTTPResponse@4d898cf1, Gateway
   Timeout)
   2015-09-29 20:16:57,361 org:myorg env:staging api:profileNewsletters rev:8
   NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onTimeout() :
   SSLClientChannel[C:XX.XX.XX.XX:443 Remote
   host:192.168.38.54:38302]@120171 useCount=2 bytesRead=0
   bytesWritten=824 age=55458ms lastIO=55000ms .onTimeoutRead

   Yukarıdaki Mesaj İşleyici günlüğünde, XX.XX.XX.XX IP adresiyle belirtilen arka uç sunucusunun 55 saniye sonra bile yanıt vermediğini (lastIO=55000ms) görüyorsunuz. Sonuç olarak, Mesaj İşleyici'nin zaman aşımı gerçekleşti ve 504 Gateway Timeout hatası gönderildi.

   Şunu kontrol edin: Mesaj İşleyici'de zaman aşımı nasıl kontrol edilir? Mesaj işleyicide zaman aşımı nasıl kontrol edilir? İleti işlemciler genellikle HTTPTransport.io.timeout.millis özelliği aracılığıyla 55 saniyelik bir varsayılan zaman aşımı değeri ile ayarlanır. Bu zaman aşımı değeri, bu mesaj işlemcisi tarafından sunulan bir kuruluşa ait tüm API proxy'leri için geçerlidir. Arka uç sunucusu 55 saniye içinde yanıt vermezse Message Processor zaman aşımına uğrar ve istemciye 504 Gateway Timeout hatası gönderir. Mesaj İşleyici'de belirtilen zaman aşımı değeri, API proxy'sinde belirtilen io.timeout.millis özelliğiyle geçersiz kılınabilir. Bu zaman aşımı değeri, yukarıda belirtilen özelliğin tanımlandığı belirli bir API proxy'si için geçerlidir. Örneğin, API proxy'sinde io.timeout.millis 10 saniye olarak ayarlanırsa bu API proxy'si için 10 saniyelik zaman aşımı değeri kullanılır. Arka uç sunucusu belirli bir API Proxy'si için 10 saniye içinde yanıt vermezse Mesaj İşleyici'nin zaman aşımı gerçekleşir ve istemciye 504 Gateway Timeout hatası gönderilir.

Çözünürlük

1. Arka uç sunucusunun neden 55 saniyeden uzun sürdüğünü kontrol edin ve daha hızlı yanıt verecek şekilde düzeltilip/optimize edilip edilemeyeceğini görün.
2. Arka uç sunucusunu düzeltmek/optimize etmek mümkün değilse veya arka uç sunucusunun yapılandırılan zaman aşımından daha uzun sürdüğü biliniyorsa Yönlendirici ve Mesaj İşleyici'deki zaman aşımı değerini uygun bir değere yükseltin.

Senaryo #2 - Yönlendiricinin zaman aşımı süresi, Mesaj İşleyici/arka uç sunucusu yanıt vermeden önce doluyor

Yönlendiricinin, Message Processor/arka uç sunucusu yanıt vermeden önce zaman aşımına uğraması durumunda 504 Gateway Timeout hataları alabilirsiniz. Bu durum, aşağıdaki koşullardan herhangi birinde gerçekleşebilir:

• Yönlendiricide ayarlanan zaman aşımı değeri, Mesaj İşleyici'de ayarlanan zaman aşımı değerinden daha kısa. Örneğin, yönlendiricideki zaman aşımının 50 saniye, ileti işlemcisindeki zaman aşımının ise 55 saniye olduğunu varsayalım.

  Yönlendiricide zaman aşımı	Mesaj işleyicide zaman aşımı
  50 saniye	55 saniye

• Mesaj İşleyicisindeki zaman aşımı değeri, API proxy'sinin hedef uç nokta yapılandırmasında ayarlanan io.timeout.millis özelliği kullanılarak daha yüksek bir zaman aşımı değeriyle geçersiz kılınır:

  Örneğin, aşağıdaki zaman aşımı değerleri ayarlanmışsa:

  Yönlendiricide zaman aşımı	Mesaj işleyicide zaman aşımı	API proxy'sinde zaman aşımı
  57 saniye	55 saniye	120 saniye

  Ancak API proxy'sinde io.timeout.millis 120 saniye olarak ayarlanmıştır:

  <HTTPTargetConnection>
       <Properties>
            <Property name="io.timeout.millis">120000</Property>
        </Properties>
        <URL>http://www.apigee.com</URL>
  </HTTPTargetConnection>

  Bu durumda, zaman aşımı değeri (55 saniye) yönlendiricideki zaman aşımı değerinden (57 saniye) daha az olsa bile Mesaj İşleyici'nin zaman aşımı 55 saniye sonra gerçekleşmez. Bunun nedeni, Mesaj İşleyici'deki 55 saniyelik zaman aşımı değerinin, API proxy'sinde ayarlanan 120 saniyelik değerle geçersiz kılınmasıdır. Bu nedenle, bu belirli API proxy'si için Mesaj İşleyici'nin zaman aşımı değeri 120 saniye olur.

  Yönlendiricinin zaman aşımı değeri (57 saniye), API proxy'sinde ayarlanan 120 saniyeye kıyasla daha düşük olduğundan arka uç sunucusu 57 saniye sonra yanıt vermezse yönlendiricinin zaman aşımı gerçekleşir.

Teşhis

1. NGINX erişim günlüğünü kontrol edin (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)

2. Yönlendiricinin zaman aşımı süresi Mesaj İşleyicisi'nden önce dolarsa belirli API isteği için NGINX erişim günlüklerinde 504 durumu gösterilir ve Mesaj İşleyicisi'nden gelen message id, - olarak ayarlanır. Bunun nedeni, yönlendiricinin yönlendiricide ayarlanan zaman aşımı süresi içinde Mesaj İşleyici'den yanıt almamasıdır.

   Yönlendiricinin zaman aşımına uğraması nedeniyle 504 hatasını gösteren örnek NGINX günlük girişi

   

3. Yukarıdaki örnekte, NGINX'te 504 durumuna dikkat edin.İleti İşlemcisi'nden gelen ileti kimliği - ve geçen toplam süre 57, 001 saniyedir. Bunun nedeni, yönlendiricinin 57,001 saniye sonra zaman aşımına uğraması ve Mesaj İşleyici'den yanıt alamamamızdır.
4. Bu durumda, Message Processor günlüklerinde Broken Pipe istisna görürsünüz (/opt/apigee/var/log/edge-message-processor/logs/system.log).

   2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
   2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
   java.io.IOException: Broken pipe
           at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
           at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
           at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
            … <snipped>

Bu hata, yönlendiricinin zaman aşımı süresi dolduğunda Mesaj İşleyici ile bağlantıyı kapatması nedeniyle gösterilir. Mesaj İşleyici, işlemeyi tamamladığında yanıtı yönlendiriciye yazmaya çalışır. Yönlendiriciyle bağlantı zaten kapatıldığından Mesaj İşlemcisi'nde Broken Pipe exception simgesi gösterilir.

Bu istisnanın, yukarıda açıklanan koşullarda görülmesi beklenir. Dolayısıyla 504 Gateway Timeout hatasının asıl nedeni, arka uç sunucusunun yanıt vermesinin daha uzun sürmesidir ve bu sorunu çözmeniz gerekir.

Çözünürlük

1. Özel bir arka uç sunucusuysa:
   1. Arka uç sunucusunun neden uzun sürede yanıt verdiğini kontrol edin ve daha hızlı yanıt verecek şekilde düzeltilip/optimize edilip edilemeyeceğini görün.
   2. Arka uç sunucusunun düzeltilmesi/optimize edilmesi mümkün değilse veya arka uç sunucusunun uzun sürdüğü biliniyorsa Yönlendirici ve Mesaj İşleyici'de zaman aşımı değerini artırın.

      Fikir: Farklı bileşenlerdeki zaman aşımı değerini aşağıdaki sırayla ayarlayın: İstemcide Zaman Aşımı > Yönlendiricide Zaman Aşımı > Mesaj İşlemcisinde Zaman Aşımı > API Proxy'sinde Zaman Aşımı

2. Arka uç sunucusu NodeJS ise:
   1. NodeJS kodunun başka arka uç sunucularına çağrı yapıp yapmadığını ve yanıt döndürmesinin uzun sürüp sürmediğini kontrol edin. Arka uç sunucularının neden daha uzun sürdüğünü kontrol edin ve sorunu uygun şekilde düzeltin.
   2. İleti işlemcilerinde yüksek CPU veya bellek kullanımı olup olmadığını kontrol edin:
      1. Herhangi bir mesaj işlemcisinde yüksek CPU kullanımı varsa aşağıdaki komutu kullanarak 30 saniyede bir üç iş parçacığı dökümü oluşturun:

         JAVA_HOME/bin/jstack -l PID > FILENAME

      2. Herhangi bir Mesaj İşleyici yüksek bellek kullanımı yaşıyorsa aşağıdaki komutu kullanarak yığın dökümü oluşturun:

         sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID

      3. 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

      4. Sorunun devam edip etmediğini doğrulamak için API çağrılarını izleyin.
      5. Apigee Edge Destek Ekibi ile iletişime geçin ve yüksek CPU/bellek kullanımının nedenini araştırmaya yardımcı olmak için 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.

Senaryo #3: İstemci uygulaması, yönlendirici/mesaj işlemcisi/arka uç sunucusu yanıt vermeden önce zaman aşımına uğruyor

Arka uç sunucusu yanıt vermeden önce istemci uygulamasının zaman aşımı olursa 504 Gateway Timeout hataları alabilirsiniz. Bu durumun nedeni şunlar olabilir:

1. İstemci uygulamasında ayarlanan zaman aşımı değeri, yönlendiricide ve mesaj işlemcisinde ayarlanan zaman aşımı değerinden daha düşük:

   Örneğin, aşağıdaki zaman aşımı değerleri ayarlanmışsa:

   İstemcide Zaman Aşımı	Yönlendiricide zaman aşımı	Mesaj işleyicide zaman aşımı
   50 saniye	57 saniye	55 saniye

   Bu durumda, Edge üzerinden bir API isteğine yanıt almak için kullanılabilen toplam süre <= 50 saniyedir. Buna, API isteğinde bulunma süresi, isteğin Edge (Yönlendirici, Mesaj İşleyici) tarafından işlenmesi, isteğin arka uç sunucusuna gönderilmesi (geçerliyse), arka ucun isteği işlemesi ve yanıtı göndermesi, Edge'in yanıtı işlemesi ve son olarak istemciye geri göndermesi için geçen süre dahildir.

   Yönlendirici 50 saniye içinde istemciye yanıt vermezse istemcinin bağlantı zaman aşımına uğrar ve yönlendiriciyle olan bağlantı kapatılır. İstemci, 504 yanıt kodunu alır.

   Bu durum, NGINX'in istemcinin bağlantıyı kapattığını belirten bir 499 durum kodu ayarlamasına neden olur.

Teşhis

1. İstemci uygulaması yönlendiriciden yanıt almadan önce zaman aşımına uğrarsa yönlendiriciyle bağlantıyı kapatır. Bu durumda, belirli API isteği için NGINX erişim günlüklerinde 499 durum kodu görürsünüz.

   Durum kodu 499'u gösteren örnek NGINX günlük girişi
   
   

2. Yukarıdaki örnekte, NGINX'teki 499 durumunun ve toplam geçen sürenin 50,001 saniye olduğunu unutmayın. Bu, istemcinin 50.001 saniye sonra zaman aşımına uğradığını gösterir.
3. Bu durumda, Broken Pipe Message Processor günlüklerinde /opt/apigee/var/log/edge-message-processor/logs/system.log).
   istisnalarını görürsünüz.

   2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
   2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
   java.io.IOException: Broken pipe
           at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
           at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
           at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
            … <snipped>

4. Yönlendiricinin zaman aşımı süresi dolduktan sonra Mesaj İşleyici ile bağlantısı kapatılır. Mesaj İşleyici, işlemeyi tamamladığında yanıtı Yönlendirici'ye yazmaya çalışır. Yönlendirici ile bağlantı zaten kapalı olduğundan Mesaj İşleyici'de Broken Pipe exception simgesi gösterilir.
5. Bu istisnanın, yukarıda açıklanan koşullar altında gerçekleşmesi beklenir. Dolayısıyla 504 Gateway Timeout hatasının asıl nedeni, arka uç sunucusunun yanıt vermesinin uzun sürmesidir ve bu sorunu çözmeniz gerekir.

Çözünürlük

1. Özel arka uç sunucunuz ise:
   1. Arka uç sunucusunun neden 57 saniyeden uzun sürdüğünü belirlemek için sunucuyu kontrol edin ve daha hızlı yanıt verecek şekilde düzeltilip/optimize edilip edilemeyeceğini görün.
   2. Arka uç sunucusunu düzeltmek/optimize etmek mümkün değilse veya arka uç sunucusunun uzun süreceğini biliyorsanız yönlendiricide ve mesaj işlemcisinde zaman aşımı değerini artırın.
      
      

      Fikir: Farklı bileşenlerdeki zaman aşımı değerini aşağıdaki sırayla ayarlayın: İstemcide Zaman Aşımı > Yönlendiricide Zaman Aşımı > Mesaj İşlemcisinde Zaman Aşımı > API Proxy'sinde Zaman Aşımı

2. Arka uç NodeJS ise:
   1. NodeJS kodunun başka arka uç sunuculara çağrı yapıp yapmadığını ve bu çağrıların yanıt vermesinin uzun sürüp sürmediğini kontrol edin. Bu arka uç sunucuların neden daha uzun sürdüğünü kontrol edin.
   2. Mesaj işlemcilerinde yüksek CPU veya bellek kullanımı olup olmadığını kontrol edin:
      1. Bir mesaj işlemcisinde yüksek CPU kullanımı varsa aşağıdaki komutu kullanarak 30 saniyede bir üç iş parçacığı dökümü oluşturun:

         JAVA_HOME/bin/jstack -l PID > FILENAME

      2. Bir Mesaj İşleyici yüksek bellek kullanımı yaşıyorsa aşağıdaki komutu kullanarak yığın dökümü oluşturun:

         sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID

      3. Aşağıdaki komutu kullanarak Mesaj İşleyici'yi yeniden başlatın. Bu işlem, CPU ve bellek kullanımını azaltır:

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

      4. Sorunun devam edip etmediğini doğrulamak için API çağrılarını izleyin.
      5. Apigee Edge 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 sağlayın (/opt/apigee/var/log/edge-message-processor/logs/system.log)Yüksek CPU/bellek kullanımının nedenini araştırmalarına yardımcı olmak için).

Yönlendirici ve mesaj işleyicideki zaman aşımı değerini artırın.

Yönlendiricide ve Mesaj İşleyici'de ayarlanacak zaman aşımı değerlerini, gereksinimlerinize bağlı olarak dikkatli bir şekilde seçin. Keyfi olarak büyük zaman aşımı değerleri belirlemeyin. Yardıma ihtiyacınız varsa Apigee Edge Destek Ekibi ile iletişime geçin.

Yönlendirici

chown apigee:apigee /opt/apigee/customer/application/router.properties

1. Yönlendirici makinesinde /opt/apigee/customer/application/router.properties dosyasını oluşturun (mevcut değilse).
2. Bu dosyaya aşağıdaki satırı ekleyin:

   conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS

   Örneğin, zaman aşımı değerini 120 saniye olarak ayarlamak istiyorsanız aşağıdaki gibi ayarlayın:

   conf_load_balancing_load.balancing.driver.proxy.read.timeout=120

3. Bu dosyanın sahibi apigee olmalıdır:
4. Yönlendiriciyi yeniden başlatın:

   /opt/apigee/apigee-service/bin/apigee-service edge-router restart

5. Birden fazla yönlendiriciniz varsa yukarıdaki adımları tüm yönlendiricilerde tekrarlayın.

Mesaj İşleyici

1. Henüz yoksa Mesaj İşleyici makinesinde /opt/apigee/customer/application/message-processor.properties dosyası oluşturun.
2. Bu dosyaya aşağıdaki satırı ekleyin:

   conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS

   Örneğin, zaman aşımı değerini 120 saniye olarak ayarlamak istiyorsanız aşağıdaki gibi ayarlayın:

   conf_http_HTTPTransport.io.timeout.millis=120000

3. Bu dosyanın sahibi apigee olmalıdır:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. Mesaj İşleyici'yi yeniden başlatın:

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

5. Birden fazla Mesaj İşleyiciniz varsa yukarıdaki adımları tüm Mesaj İşleyicilerde tekrarlayın.

Edge tarafından yavaş API isteği işleme

Edge çok yavaşsa ve/veya API isteğini işlemek uzun sürüyorsa 504 Gateway Timeout hatası alırsınız.

Teşhis

1. Etkilenen API'yi Edge kullanıcı arayüzünde izleyin.
2. Hatanın oluşmasını bekleyin veya API çağrınız varsa bazı API çağrıları yapıp 504 Gateway Timeout hatasını yeniden oluşturun.
3. Bu durumda, izlemede başarılı bir yanıt görebilirsiniz.
   1. Mesaj İşleyici, yönlendiricide/istemcide belirtilen zaman aşımı süresi içinde yanıt vermediğinden yönlendiricinin/istemcinin (hangisinin zaman aşımı süresi en kısaysa) zaman aşımı süresi doluyor. Ancak mesaj işleyici, isteği işlemeye devam eder ve başarıyla tamamlayabilir.
   2. Ayrıca, Mesaj İşleyici'de ayarlanan HTTPTransport.io.timeout.millis değeri yalnızca Mesaj İşleyici bir HTTP/HTTPS arka uç sunucusuyla iletişim kurarsa tetiklenir. Başka bir deyişle, API proxy'sindeki herhangi bir politika (ServiceCallout politikası hariç) uzun sürdüğünde bu zaman aşımı tetiklenmez.
4. Hata oluştuktan sonra en uzun geçen süreye sahip olan isteği inceleyin.
5. Her aşamada geçen süreyi kontrol edin ve en çok zaman harcanan aşamayı not edin.
6. Hizmet Çağrısı politikası dışındaki politikalardan herhangi birinde en uzun geçen süreyi gözlemlerseniz bu, Edge'in isteği işlemesinin uzun sürdüğünü gösterir.
7. JavaScript politikasında çok yüksek geçen süre gösteren örnek bir kullanıcı arayüzü izini aşağıda verilmiştir:

   

8. Yukarıdaki örnekte, JavaScript politikasının anormal derecede uzun sürdüğünü (~245 saniye) görüyorsunuz.

Çözünürlük

1. Yanıt vermesi uzun süren bir politika olup olmadığını ve işlenmesi uzun sürebilecek özel kod olup olmadığını kontrol edin. Bu tür bir kod varsa tanımlanan kodu düzeltip/optimize edip edemeyeceğinizi kontrol edin.
2. Yüksek işleme süresine neden olabilecek özel bir kod yoksa mesaj işlemcilerde yüksek CPU veya bellek kullanımı olup olmadığını kontrol edin:
   1. Herhangi bir mesaj işlemcisinde yüksek CPU kullanımı varsa aşağıdaki komutu kullanarak 30 saniyede bir üç iş parçacığı dökümü oluşturun:

      JAVA_HOME/bin/jstack -l PID > FILENAME

   2. Herhangi bir mesaj işlemcisinin bellek kullanımı yüksekse aşağıdaki komutu kullanarak yığın dökümü oluşturun:

      sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID

   3. Aşağıdaki komutu kullanarak Mesaj İşleyici'yi yeniden başlatın. Bu işlem, CPU ve belleği düşürmelidir.

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

   4. API çağrılarını izleyin ve sorunun devam edip etmediğini doğrulayın.
   5. Apigee Edge 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 sağlayın (/opt/apigee/var/log/edge-message-processor/logs/system.log)Yüksek CPU/bellek kullanımının nedenini araştırmalarına yardımcı olmak için).

API izlemeyi kullanarak sorunları teşhis etme

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, 504 durum kodlarının sayısı belirli bir eşiği aştığında bildirim almak için uyarı oluşturmak isteyebilirsiniz.