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

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

Belirti

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

HTTP durum kodu - 504 Gateway Timeout hatası, bir API yürütülürken istemcinin Uç Ağ Geçidi 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?

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

Edge platformundaki istemci uygulaması, yönlendiriciler ve Mesaj İşlemcileri uygun zaman aşımı değerleriyle ayarlanmıştı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 ne zaman zaman aşımlarının oluşabileceği hakkında daha fazla ayrıntı sunulmaktadır:

Zaman aşımı oluşumu Ayrıntılar
Mesaj işleyicide zaman aşımı yaşanıyor
  • Arka uç sunucu, Mesaj İşleyicide belirtilen zaman aşımı süresi içinde Mesaj İşleyici'ye yanıt vermez.
  • İleti İşleyen zaman aşımına uğrar ve yanıt durumunu 504 Gateway Timeout olarak Yönlendirici'ye gönderir.
Yönlendiricide zaman aşımı
  • Mesaj işleyici, yönlendiricide belirtilen zaman aşımı süresi içinde yönlendiriciye yanıt vermez.
  • Yönlendirici zaman aşımına uğrar ve yanıt durumunu istemci uygulamasına 504 Gateway Timeout olarak gönderir.
İstemci uygulamasında zaman aşımı oluyor
  • Yönlendirici, yönlendiricide belirtilen zaman aşımı süresi içinde istemci uygulamasına yanıt vermez.
  • İstemci uygulaması zaman aşımına uğrar ve son kullanıcıya yanıt durumunu 504 Gateway Timeout olarak sonlandırır.

Olası nedenler

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

Neden Ayrıntılar Aşağıdakiler için verilen adımlar
Yavaş arka uç sunucusu API isteğini işleyen arka uç sunucu, yüksek yük veya düşük performans nedeniyle çok yavaştır. Herkese açık ve Private Cloud kullanıcıları
Edge tarafından yavaş API isteği işleme Edge'in, yüksek yük veya düşük performans nedeniyle API isteğini işlemesi uzun sürüyor.

Arka uç sunucunun yavaş olması

Arka uç sunucusu çok yavaşsa veya API isteğinin işlenmesi 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ğrar.
  2. Yönlendirici, ileti işleyici/arka uç sunucusu yanıt vermeden önce zaman aşımına uğrar.
  3. İstemci uygulaması, Yönlendirici/Mesaj İşleyen/arka uç sunucusu yanıt vermeden önce zaman aşımına uğrar.

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

Senaryo #1: Mesaj işleyici, arka uç sunucusu yanıt vermeden önce zaman aşımına uğrar

Teşhis

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

1. Prosedür: Trace'i kullanma

Sorun hâlâ devam ediyorsa (504 hataları hâlâ ortaya çıkıyorsa) aşağıdaki adımları uygulayın:

  1. Edge kullanıcı arayüzünde etkilenen API'yi izleyin. Hatanın oluşmasını bekleyin veya API çağrınız varsa bazı API çağrıları yaparak 504 Gateway Timeout hatasını yeniden oluşturun.
  2. Hata oluştuktan sonra, yanıt kodunu 504 olarak gösteren belirli isteği inceleyin.
  3. Her aşamada geçen süreyi kontrol edin ve en çok sürenin harcandığı aşamayı not edin.
  4. Hatayı aşağıdaki aşamalardan birinin hemen ardından, geçen en uzun süreye sahip olarak gözlemlemeniz, arka uç sunucusunun yavaş olduğu veya isteği işlemesinin uzun sürdüğü anlamına gelir:
    • İstek hedef sunucuya gönderildi
    • ServiceCallout politikası

Aşağıda, arka uç sunucunun 55 saniye sonra bile yanıt vermediğini ve bunun sonucunda 504 Gateway Timeout hatası oluştuğunu gösteren örnek bir izleme sunulmaktadır:

Yukarıdaki izlemede, arka uç sunucu yanıt vermediği için Mesaj İşleyen 55002 ms sonra zaman aşımına uğrar.

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ürseniz bu, Mesaj İşleyici'nin zaman aşımına uğradığını gösterir.

    Geçiş Timeout Hatası'nı 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 İleti İşleyici günlüğünde, XX.XX.XX.XX IP adresiyle belirtilen arka uç sunucusunun 55 saniye (lastIO=55000ms) sonra bile yanıt vermediğini fark ediyorsunuz. Sonuç olarak, Mesaj İşleyici zaman aşımına uğradı ve 504 Gateway Timeout hatası gönderdi.

    Şunu kontrol edin: Mesaj İşleyicide zaman aşımı nasıl kontrol edilir?

    • Mesaj işleyicide zaman aşımı nasıl kontrol edilir? Mesaj işleyiciler genellikle HTTPTransport.io.timeout.millis mülkü aracılığıyla 55 saniyelik varsayılan zaman aşımı değeri ile ayarlanır. Bu zaman aşımı değeri, bu Mesaj İşleyici 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 Mesaj İşleyici zaman aşımına uğrar ve istemciye 504 Gateway Timeout hatası gönderir.
    • Mesaj İşleyen'de belirtilen zaman aşımı değeri, API Proxy'sinde belirtilen io.timeout.millis mülkü tarafından geçersiz kılınabilir. Bu zaman aşımı değeri, yukarıda belirtilen mülkün belirtildiği 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 için 10 saniyelik zaman aşımı değeri kullanılır.
      • Arka uç sunucu, belirli bir API Proxy için 10 saniye içinde yanıt vermezse Mesaj İşleyici zaman aşımına uğrar ve istemciye 504 Gateway Timeout hatası gönderir.

Çözünürlük

  1. Arka uç sunucunun 55 saniyeden uzun süre neden sürdüğünü kontrol edin ve daha hızlı yanıt vermesi için düzeltilip optimize edilip edilemeyeceğine bakın.
  2. Arka uç sunucuyu düzeltmek/optimize etmek mümkün değilse veya arka uç sunucunun yapılandırılmış zaman aşımından daha uzun süre aldığı biliniyorsa yönlendiricideki ve mesaj işleyicideki zaman aşımı değerini uygun bir değere yükseltin.

Senaryo #2: Yönlendirici, ileti işleyici/arka uç sunucusu yanıt vermeden önce zaman aşımına uğrar

Yönlendirici, ileti işleyici/arka uç sunucusu yanıt vermeden önce zaman aşımına uğrarsa 504 Gateway Timeout hataları alabilirsiniz. Bu durum aşağıdaki durumlardan birinde gerçekleşebilir:

  • Yönlendiricide ayarlanan zaman aşımı değeri Mesaj İşleyicide ayarlanan zaman aşımı değerinden kısa. Örneğin, yönlendiricideki zaman aşımının 50 saniye, ileti işleyicinin ise 55 saniye olduğunu varsayalım.
    Yönlendiricide zaman aşımı Mesaj işleyicide zaman aşımı
    50 saniye 55 saniye
  • Mesaj İşleyici'deki 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 ayarlanırsa:

    Yönlendiricide zaman aşımı İleti İşleyicide zaman aşımı API Proxy'sinde zaman aşımı
    57 saniye 55 saniye 120 saniye

    Ancak io.timeout.millis, API Proxy'sinde 120 saniyeye 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) az olsa bile Mesaj İşleyen 55 saniye sonra zaman aşımına uğramaz. 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 API Proxy'si için Mesaj İşleyici'nin zaman aşımı değeri 120 saniye olur.

    Yönlendirici, API Proxy'de ayarlanan 120 saniyeye kıyasla daha düşük bir zaman aşımı değerine (57 saniye) sahip olduğundan, arka uç sunucu 57 saniye sonra yanıt vermezse yönlendirici zaman aşımına uğrar.

Teşhis

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

  2. Mesaj İşleyici'den önce yönlendirici zaman aşımına uğrarsa belirli API isteği için NGINX erişim günlüklerinde 504 durumunu görürsünüz ve Mesaj İşleyicideki message id - olarak ayarlanır. Bunun nedeni, Yönlendirici'nin yönlendiricide ayarlanan zaman aşımı süresi içinde Mesaj İşleyici'den herhangi bir yanıt almamasıdır.

    Yönlendirici zaman aşımı nedeniyle 504 gösteren örnek NGINX günlük girişi

  3. Yukarıdaki örnekte, NGINX'teki 504 durumuna, İleti İşleyen'den gelen ileti kimliğine (-) ve geçen toplam süreye (57.001 saniye) dikkat edin. Bunun nedeni, yönlendiricinin 57.001 saniye sonra zaman aşımına uğramış ve Mesaj İşleyici'den herhangi bir yanıt almamış olmamızdır.
  4. Bu durumda, İleti İşleyen 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>

Yönlendirici zaman aşımına uğradığında Mesaj İşleyici ile bağlantıyı kapattığı için bu hata gösterilir. Mesaj İşleyen, işleme işlemini tamamladığında yanıtı yönlendiriciye yazmaya çalışır. Yönlendiriciyle bağlantı zaten kapalı olduğu için Mesaj İşleyicide Broken Pipe exception simgesini görürsünüz.

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 hâlâ arka uç sunucusunun yanıt vermesi uzun sürmesidir ve bu sorunu gidermeniz gerekir.

Çözünürlük

  1. Özel bir arka uç sunucusu ise
    1. Arka uç sunucusunun yanıt vermesinin neden uzun sürdüğünü kontrol edin ve daha hızlı yanıt vermek için düzeltilip düzeltilemeyeceğini/optimize edilip edilemeyeceğini öğrenin.
    2. Arka uç sunucusunu düzeltmek/optimize etmek mümkün değilse veya arka uç sunucusunun uzun sürdüğü bilinen bir gerçekse Yönlendirici ve Mesaj İşleyicide 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 İşleyicide Zaman Aşımı > API Proxy'sinde Zaman Aşımı
  2. Bu bir NodeJS arka uç sunucusuysa:
    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üre harcadığını kontrol edin ve uygun şekilde sorunu düzeltin.
    2. Mesaj işleyicilerin yüksek CPU veya bellek kullanımı yaşayıp yaşamadığını kontrol edin:
      1. Herhangi bir İleti İşleyen'de yüksek CPU kullanımı yaşanıyorsa aşağıdaki komutu kullanarak 30 saniyede bir üç işleme devam eden mesaj yığını oluşturun: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. Herhangi bir Mesaj İşleyicide yüksek bellek kullanımı yaşanıyorsa aşağıdaki komutu kullanarak bir 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ı düşürü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ı olması için /opt/apigee/var/log/edge-message-processor/logs/system.log)iş parçacığı dökümlerini, yığın dökümünü ve Mesaj İşlemcisi günlüklerini sağlayın.

Bunu Kontrol Edin: Mesaj İşleyicide NodeJS arka uç sunucuları için zaman aşımı nasıl kontrol edilir?

  • NodeJS arka uç sunucusu, Mesaj İşleyici'nin JVM işleminde çalışır. NodeJS arka uç sunucuları için zaman aşımı değeri, nodejs.properties dosyasında http.request.timeout.seconds mülkü aracılığıyla kontrol edilir. Bu özellik varsayılan olarak 0 değerine ayarlanır. Yani zaman aşımı, bu Mesaj İşleyici tarafından sunulan bir kuruluşa ait tüm API Proxy'leri için varsayılan olarak devre dışıdır. Bu nedenle, NodeJS arka uç sunucusu uzun süre alsa bile Mesaj İşleyici zaman aşımına uğramaz.
  • Ancak NodeJS arka uç sunucusu uzun sürerse ve API isteğinin süresi 57 saniyeden fazlaysa yönlendirici zaman aşımına uğrar ve istemciye 504 Gateway Timeout hatası gönderir.

Senaryo #3: Yönlendirici/Mesaj İşleyen/arka uç sunucu yanıt vermeden önce istemci uygulaması zaman aşımına uğrar

Arka uç sunucusu yanıt vermeden önce istemci uygulaması zaman aşımına uğrarsa 504 Gateway Timeout hataları alabilirsiniz. Bu durum, aşağıdaki durumlarda yaşanabilir:

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

    Örneğin, aşağıdaki zaman aşımı değerleri ayarlanırsa:

    İ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ği için yanıt almak üzere kullanılabilecek toplam süre 50 saniyeden kısadır. Buna API isteği oluşturmak için geçen süre, isteğin Edge (Yönlendirici, Mesaj İşleyici) tarafından işlenmesi, isteğin arka uç sunucuya gönderilmesi (varsa), arka uç tarafından isteğin işlenmesi ve yanıtın gönderilmesi, Edge'in yanıtı işleyerek istemciye geri göndermesi dahildir.

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

    Bu işlem, NGINX'in istemcinin bağlantıyı kapattığını belirten 499 durum kodunu 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.

    499 durum kodunu gösteren örnek NGINX günlük girişi

  2. Yukarıdaki örnekte, NGINX'teki 499 durumunun ve geçen toplam 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, İleti İşleyen günlüğünde Broken Pipe İstisnaları 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-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önlendirici zaman aşımına uğradıktan sonra Mesaj İşleyen ile bağlantıyı kapatır. Mesaj işleyici, işlemeyi tamamladığında yanıtı Yönlendirici'ye yazmaya çalışır. Yönlendiriciye olan bağlantı zaten kapalı olduğu için Mesaj İşleyicide Broken Pipe exception alırsınız.
  5. Yukarıda açıklanan koşullarda bu istisna beklenir. Dolayısıyla 504 Gateway Timeout hatasının asıl nedeni, arka uç sunucunun yanıt vermesinin uzun sürmesidir ve bu sorunu çözmeniz gerekir.

Çözünürlük

  1. Özel arka uç sunucunuzsa:
    1. 57 saniyeden uzun sürmesinin nedenini belirlemek için arka uç sunucusunu kontrol edin ve daha hızlı yanıt vermesi için düzeltilip optimize edilip edilemeyeceğine bakın.
    2. Arka uç sunucuyu düzeltmek/optimize etmek mümkün değilse veya arka uç sunucunun uzun süreceğini biliyorsanız yönlendiricideki ve Mesaj İşleyicideki zaman aşımı değerini artırın.

      Fikir: Farklı bileşenlerde zaman aşımı değerini aşağıdaki sırayla ayarlayın:

      İstemcide Zaman Aşımı > Yönlendiricide Zaman Aşımı > Mesaj İşleyicide Zaman Aşımı > API Proxy'sinde Zaman Aşımı
  2. NodeJS arka ucu ise:
    1. NodeJS kodunun başka arka uç sunucularına çağrı yapıp yapmadığını ve bunun geri dönmesi uzun sürüyor mu? Bu arka uç sunucularının neden daha uzun sürdüğünü kontrol edin.
    2. Mesaj İşlemcilerinin yüksek CPU veya bellek kullanımı yaşayıp yaşamadığını kontrol edin:
      1. Bir Mesaj İşleyicide yüksek CPU kullanımı yaşanıyorsa aşağıdaki komutu kullanarak 30 saniyede bir üç işleme devam eden mesaj ipi dökümü oluşturun: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. Bir Mesaj İşleyicide yüksek bellek kullanımı yaşanıyorsa aşağıdaki komutu kullanarak bir 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 İleti İşlemciyi yeniden başlatın. Bu, CPU ve bellek kullanımını düşürür: 
        /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
      4. Sorunun devam edip etmediğini onaylamak 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ırmalarına yardımcı olmak için /opt/apigee/var/log/edge-message-processor/logs/system.log)iş parçacığı dökümlerini, yığın dökümünü ve Mesaj İşlemcisi günlüklerini sağlayın.

Yönlendiricide ve Mesaj İşleyici'de zaman aşımı değerini artırın

Yönlendiricide ve Mesaj İşleyicide ayarlanacak zaman aşımı değerlerini gereksinimlerinize göre dikkatlice seçin. İsteğe bağlı 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 (henüz yoksa).
  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 apigee'ye ait olduğundan emin olun:
  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 İşleyen makinesinde /opt/apigee/customer/application/message-processor.properties dosyasını oluşturun.
  2. Aşağıdaki satırı bu dosyaya ekleyin: 
    conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS

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

    conf_http_HTTPTransport.io.timeout.millis=120000
  3. Bu dosyanın Apigee'ye ait olduğundan emin olun: 
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
  4. Mesaj İşlemciyi yeniden başlatın: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  5. Birden fazla Mesaj İşleyiciniz varsa tüm Mesaj İşleyenler için yukarıdaki adımları tekrarlayın.

Fikir: Farklı bileşenlerde zaman aşımı değerini aşağıdaki sırayla ayarlayın:

İstemcide Zaman Aşımı > Yönlendiricide Zaman Aşımı > Mesaj İşleyicide Zaman Aşımı > API Proxy'sinde Zaman Aşımı

Edge'in yavaş API isteği işlemesi

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

Teşhis

  1. Edge kullanıcı arayüzünde etkilenen API'yi takip edin.
  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, Trace'te başarılı bir yanıt görebileceğinizi unutmayın.
    1. Mesaj işleyici, yönlendirici/istemcide belirtilen zaman aşımı süresi (hangisi daha düşükse) içinde yanıt vermediğinde yönlendirici/istemci zaman aşımına uğrar. Ancak Mesaj İşleyici, isteği işlemeye devam eder ve işlemi 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 kurduğunda tetiklenir. Diğer bir deyişle, API Proxy'deki herhangi bir politika (ServiceCallout politikası dışında) uzun süre aldığında bu zaman aşımı tetiklenmez.
  4. Hata oluştuktan sonra en uzun geçen süreye sahip isteği inceleyin.
  5. Her aşamada geçen süreyi kontrol edin ve en çok sürenin harcandığı aşamayı not edin.
  6. Hizmet açıklama metni politikası dışındaki politikalardan herhangi birinde en uzun geçen süreyi görüyorsanız Edge'in isteği işleme süresinin uzun olduğunu gösterir.
  7. JavaScript Politikası'nda geçen sürenin çok yüksek olduğunu gösteren örnek bir kullanıcı arayüzü izleme örneğini burada bulabilirsiniz:

  8. Yukarıdaki örnekte, JavaScript politikasının yaklaşık 245 saniye gibi anormal derecede uzun bir süre sürdüğünü fark edebilirsiniz.

Çözünürlük

  1. Yanıtlanması uzun süren politikanın olup olmadığını ve işlenmesinin uzun sürebileceği özel kod olup olmadığını kontrol edin. Böyle bir kod varsa tanımlanan kodu düzeltip düzeltemeyeceğinizi veya optimize edip edemeyeceğinize bakın.
  2. Uzun işleme süresine neden olabilecek özel bir kod yoksa Mesaj İşlemcilerinin yüksek CPU veya bellek kullanımı sağlayıp sağlamadığını kontrol edin:
    1. Herhangi bir Mesaj İşlemci, yüksek CPU kullanımı yaşıyorsa her 30 saniyede bir şu komutu kullanarak üç iş parçacığı dökümü oluşturun: 
      JAVA_HOME/bin/jstack -l PID > FILENAME
    2. Herhangi bir Mesaj İşleyen'in bellek kullanımı yüksekse aşağıdaki komutu kullanarak bir 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 İleti İşlemcisini yeniden başlatın. Bu işlem, CPU ve bellek kullanımını düşürür. 
      /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çin ve yüksek CPU/bellek kullanımının nedenini araştırmalarına yardımcı olmak için /opt/apigee/var/log/edge-message-processor/logs/system.log)mesaj dizisinin dökümlerini, yığın dökümünü ve Mesaj İşlemcisi günlüklerini sağlayın.

API İzleme'yi kullanarak sorunları teşhis etme

API İzleme, hata, performans ve gecikme sorunlarını ve bunların kaynakları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 tespit etmenizi sağlar.

API Monitoring'i kullanarak API'lerinizle ilgili 5xx sorunlarını nasıl gidereceğinizi gösteren örnek bir senaryoyu inceleyin. Örneğin, 504 durum kodlarının sayısı belirli bir eşiği aştığında bildirim almak için bir uyarı ayarlamak isteyebilirsiniz.