499 İstemci bağlantısı kesildi

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

Belirti

İstemci uygulaması, API istekleri için bir zaman aşımı hatası alır veya API isteği Apigee'de yürütülürken istek aniden sonlandırılır.

API Monitoring ve NGINX Access günlüklerinde bu tür API istekleri için 499 durum kodunu görürsünüz. Bazen API Analytics'te, Mesaj İşleyici tarafından döndürülen durum kodu gösterildiği için farklı durum kodları görebilirsiniz.

Hata mesajı

İstemci uygulamalarında aşağıdaki gibi hatalar görülebilir: 

curl: (28) Operation timed out after 6001 milliseconds with 0 out of -1 bytes received

İstemci zaman aşımlarının nedeni nedir?

Edge platformunda bir API isteği için tipik yol, aşağıdaki şekilde gösterildiği gibi İstemci > Yönlendirici > Mesaj İşleyici > Arka Uç Sunucusu şeklindedir:

Apigee Edge platformundaki Yönlendiriciler ve Mesaj İşleyiciler, API isteklerinin tamamlanmasının çok uzun sürmesini önlemek amacıyla uygun varsayılan zaman aşımı değerleriyle ayarlanır.

İstemcide zaman aşımı

İstemci uygulamaları, ihtiyaçlarınıza göre uygun bir zaman aşımı değeriyle yapılandırılabilir.

Web tarayıcıları ve mobil uygulamalar gibi istemcilerin işletim sistemi tarafından tanımlanan zaman aşımları vardır.

Yönlendiricide zaman aşımı

Yönlendiricilerde yapılandırılan varsayılan zaman aşımı 57 saniyedir. Bu, API isteğinin Edge'de alınmasından yanıtın geri gönderilmesine kadar, arka uç yanıtı ve yürütülen tüm politikalar dahil olmak üzere bir API proxy'sinin yürütülebileceği maksimum süredir. Varsayılan zaman aşımı, Yönlendiricilerde G/Ç zaman aşımını yapılandırma bölümünde açıklandığı gibi Yönlendiriciler ve sanal ana makinelerde geçersiz kılınabilir.

Mesaj İşleyicilerinde zaman aşımı

İleti İşleyicilerinde yapılandırılan varsayılan zaman aşımı 55 saniyedir. Bu, arka uç sunucusunun isteği işlemek ve Mesaj İşleyici'ye yanıt vermek için kullanabileceği maksimum süredir. Varsayılan zaman aşımı, Mesaj İşleyicilerinde G/Ç zaman aşımını yapılandırma bölümünde açıklandığı gibi Mesaj İşleyicilerinde veya API Proxy'sinde geçersiz kılınabilir.

İstemci, API proxy'si zaman aşımına uğramadan önce Yönlendiriciyle olan bağlantıyı kapatırsa ilgili API isteği için zaman aşımı hatası gösterilir. 499 Client Closed Connection durum kodu, bu tür istekler için Yönlendiriciye kaydedilir. Bu kod, API Monitoring ve NGINX Access günlüklerinde gözlemlenebilir.

Olası Nedenler

Edge'de 499 Client Closed Connection hatasının tipik nedenleri şunlardır:

Neden Açıklama Şunun için geçerli sorun giderme talimatları:
İstemci, bağlantıyı aniden kapattı Bu durum, son kullanıcının işlem tamamlanmadan isteği iptal etmesi nedeniyle istemci bağlantıyı kapattığında meydana gelir. Herkese açık ve Private Cloud kullanıcıları
İstemci uygulaması zaman aşımı Bu durum, API proxy'sinin yanıtı işleyip göndermesi için zaman aşımına uğradığında istemci uygulaması zaman aşımına uğradığında meydana gelir. Bu durum genellikle istemci zaman aşımı, yönlendirici zaman aşımından kısa olduğunda görülür. Herkese açık ve Private Cloud kullanıcıları

Yaygın teşhis adımları

Bu hatayı teşhis etmek için aşağıdaki araçlardan/tekniklerden birini kullanın:

  • API Monitoring
  • NGINX erişim günlükleri

API Monitoring

API Monitoring'i kullanarak hatayı teşhis etmek için:

  1. Analiz > API İzleme > Araştır sayfasına gidin.
  2. 4xx hatalarını filtreleyin ve zaman aralığını seçin.
  3. Durum Kodu'nu Zaman'a göre çizin.
  4. Aşağıda gösterildiği gibi 499 hata içeren bir hücre seçin:

  5. Aşağıda gösterildiği gibi, sağ bölmede 499 hatasıyla ilgili bilgileri görürsünüz:

  6. Sağdaki bölmede Günlükleri görüntüle'yi tıklayın.

    Trafik Günlükleri penceresinde, bazı 499 hataları için aşağıdaki ayrıntıları not edin:

    • İstek:Çağrılar için kullanılan istek yöntemini ve URI'yı sağlar.
    • Yanıt Süresi:İstek için geçen toplam süreyi gösterir.

    API Monitoring GET günlükleri API'sini kullanarak da tüm günlükleri alabilirsiniz. Örneğin org, env, timeRange ve status günlüklerini sorgulayarak istemcinin zaman aşımına uğradığı işlemlerin tüm günlüklerini indirebilirsiniz.

    API Monitoring, HTTP 499 hataları için proxy'yi - olarak ayarladığından, sanal ana makine ve yol için ilişkili proxy'yi almak amacıyla API'yi (Logs API) kullanabilirsiniz.

    For example : 

    curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https://VIRTUAL_HOST/BASEBATH" -H "Authorization: Bearer $TOKEN"
  7. Diğer 499 hataları için Yanıt Süresi'ni inceleyin ve Yanıt Süresi'nin tüm 499 hataları arasında tutarlı olup olmadığını (örneğin 30 saniye) kontrol edin.

NGINX erişim günlükleri

NGINX erişim günlüklerini kullanarak hatayı teşhis etmek için:

  1. Private Cloud kullanıcısıysanız HTTP 499 hatalarıyla ilgili önemli bilgileri belirlemek için NGINX erişim günlüklerini kullanabilirsiniz.
  2. NGINX erişim günlüklerini kontrol edin:
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  3. Belirli bir süre boyunca 499 hatası olup olmadığını (sorun geçmişte gerçekleştiyse) veya 499 nedeniyle başarısız olan bir istek olup olmadığını görmek için arama yapın.
  4. Bazı 499 hataları için aşağıdaki bilgileri göz önünde bulundurun:
    • Toplam Yanıt Süresi
    • İstek URI'si
    • Kullanıcı aracısı

    NGINX erişim günlüğünden örnek 499 hatası:

    2019-08-23T06:50:07+00:00       rrt-03f69eb1091c4a886-c-sy      50.112.119.65:47756
10.10.53.154:8443       10.001  -       -       499     -       422     0
   GET /v1/products HTTP/1.1        -       okhttp/3.9.1    api.acme.org
rrt-03f69eb1091c4a886-c-sy-13001-6496714-1
    50.112.119.65   -       -       -       -       -       -       -       -1      -       -       dc-1  router-pod-1
rt-214-190301-0020137-latest-7d
36       TLSv1.2 gateway-1     dc-1  acme    prod  https   -

    Bu örnek için aşağıdaki bilgiler gösterilir:

    • Toplam yanıt süresi: 10.001 saniye. Bu, istemcinin 10,001 saniye sonra zaman aşımına uğradığını gösterir
    • İstek: GET /v1/products
    • Ana makine:api.acme.org
    • Kullanıcı Aracısı:okhttp/3.9.1
  5. Toplam Yanıt Süresi ve Kullanıcı Aracısı'nın tüm 499 hataları genelinde tutarlı olup olmadığını kontrol edin.

Neden: İstemci bağlantıyı aniden kapattı

Teşhis

  1. Tarayıcı veya mobil uygulamada çalışan tek sayfalık bir uygulamadan API çağrıldığında, son kullanıcı aniden tarayıcıyı kapatır, aynı sekmedeki başka bir web sayfasına gider veya yüklemeyi durdur düğmesini tıklayarak veya dokunarak sayfanın yüklenmesini durdurursa tarayıcı isteği iptal eder.
  2. Böyle bir durumda HTTP 499 durumundaki işlemlerin, genellikle isteklerin her birinin istek işleme süresi (Yanıt Süresi) açısından farklılık gösterir.
  3. Nedenin bu olup olmadığını belirlemek için Yanıt Süresi'ni karşılaştırabilir ve API Monitoring veya NGINX Access günlüklerini kullanarak 499 hatalarının her biri için farklı olup olmadığını Yaygın teşhis adımlarında açıklandığı şekilde doğrulayabilirsiniz.

Çözünürlük

  1. Bu durum normaldir ve HTTP 499 hatalarının küçük miktarlarda meydana gelmesi halinde genellikle endişeye yol açmaz.

  2. Aynı URL yolu için sık sık gerçekleşiyorsa bu durum, söz konusu yolla ilişkilendirilmiş belirli proxy'nin çok yavaş olmasından ve kullanıcıların beklemek istememesinden kaynaklanıyor olabilir.

    Hangi proxy'nin etkilenebileceğini öğrendikten sonra, proxy gecikmesine neyin neden olduğunu daha ayrıntılı bir şekilde incelemek için Gecikme analizi kontrol panelini kullanın.

    1. Bu durumda, Yaygın teşhis adımlarındaki adımları kullanarak etkilenen proxy'yi belirleyin.
    2. Proxy gecikmesine neyin neden olduğunu daha ayrıntılı bir şekilde incelemek ve sorunu düzeltmek için Gecikme analizi kontrol panelini kullanın.
    3. Belirli bir Proxy için gecikmenin beklendiğini tespit ederseniz kullanıcılarınıza bu Proxy'nin yanıt vermesi biraz zaman alacağını bildirmeniz gerekebilir.

Neden: İstemci uygulaması zaman aşımı

Bu, çeşitli senaryolarda gerçekleşebilir.

  1. Bu isteğin normal çalışma koşullarında tamamlanması belirli bir zaman (örneğin 10 saniye) sürer. Ancak istemci uygulaması yanlış bir zaman aşımı değeriyle (örneğin, 5 saniye) ayarlanmış. Bu durum, API isteği tamamlanmadan istemci uygulamasının zaman aşımına uğrayarak 499 olmasına neden olur. Bu durumda, istemci zaman aşımını uygun bir değere ayarlamamız gerekir.
  2. Hedef sunucu veya açıklama metni beklenenden uzun sürüyor. Bu durumda, uygun bileşeni düzeltmeniz ve ayrıca zaman aşımı değerlerini uygun şekilde ayarlamanız gerekir.
  3. İstemci artık yanıta ihtiyaç duymadığından işlemi iptal etti. Bu durum, otomatik tamamlama veya kısa anket gibi yüksek sıklıktaki API'lerde görülebilir.

Teşhis

API Monitoring veya NGINX erişim günlükleri

API Monitoring veya NGINX erişim günlüklerini kullanarak hatayı teşhis edin:

  1. HTTP 499 işlemleri için, Yaygın teşhis adımları bölümünde açıklandığı şekilde API Monitoring günlüklerini veya NGINX erişim günlüklerini kontrol edin.
  2. Yanıt Süresi'nin tüm 499 hataları için tutarlı olup olmadığını belirleyin.
  3. Yanıtınız evetse belirli bir istemci uygulaması kendi tarafında sabit bir zaman aşımı yapılandırmış olabilir. Bir API proxy'si veya hedef sunucu yavaş yanıt veriyorsa proxy zaman aşımına uğramadan önce istemci zaman aşımına uğrar. Bu da aynı URI yolu için büyük miktarda HTTP 499s oluşmasına neden olur. Bu durumda, NGINX erişim günlüklerinden Kullanıcı Aracısı'nı belirleyin. Bu günlük, belirli bir istemci uygulamasını belirlemenize yardımcı olabilir.
  4. Apigee'nin önünde Akamai, F5, AWS ELB gibi bir yük dengeleyicinin bulunması da mümkün olabilir. Apigee özel bir yük dengeleyici arkasında çalışıyorsa yük dengeleyicinin istek zaman aşımı, Apigee API zaman aşımından daha uzun olacak şekilde yapılandırılmalıdır. Varsayılan olarak Apigee Yönlendiricisi 57 saniye sonra zaman aşımına uğrar. Bu nedenle yük dengeleyicide 60 saniyelik bir istek zaman aşımı oluşturmak uygundur.

Trace

Trace'i kullanarak hatayı teşhis edin

Sorun hâlâ devam ediyorsa (499 hata devam ediyorsa) aşağıdaki adımları uygulayın:

  1. Edge kullanıcı arayüzünde, etkilenen API için izleme oturumunu etkinleştirin.
  2. Hatanın oluşmasını bekleyin veya API çağrısı kullanıyorsanız birkaç API çağrısı yapıp hatayı yeniden oluşturun.
  3. Her aşamada geçen süreyi kontrol edin ve zamanın çoğunun harcandığı aşamayı not edin.
  4. Aşağıdaki aşamaların birinden hemen sonra geçen en uzun süre boyunca hata olduğunu gözlemlerseniz bu durum, arka uç sunucusunun yavaş olduğunu veya isteği işlemesinin uzun sürdüğünü gösterir:
    • Hedef sunucuya istek gönderildi
    • Hizmet Çağrısı politikası

    Aşağıda, İstek hedef sunucuya gönderildikten sonra Ağ Geçidi Zaman Aşımı'nı gösteren örnek bir kullanıcı arayüzü izlemesi verilmiştir:

Çözünürlük

  1. Apigee Edge üzerinden API isteği akışına dahil olan farklı bileşenlerde hangi zaman aşımı değerlerinin ayarlanması gerektiğini anlamak için G/Ç zaman aşımını yapılandırmayla ilgili en iyi uygulamalar bölümüne bakın.
  2. İstemci uygulamasında en iyi uygulamalara göre uygun bir zaman aşımı değeri ayarladığınızdan emin olun.

Sorun devam ederse Teşhis bilgileri toplanmalı bölümüne gidin .

Teşhis bilgileri toplanmalıdır

Sorun devam ederse aşağıdaki teşhis bilgilerini toplayıp 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 adı
  • Zaman aşımı hatasını yeniden oluşturmak için kullanılan curl komutunu tamamlayın
  • İstemci zaman aşımı hataları gördüğünüz API istekleri için izleme dosyası

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

  • Başarısız istekler için gözlemlenen tam hata mesajı
  • Ortam adı
  • API Proxy paketi
  • İstemci zaman aşımı hataları gördüğünüz API istekleri için izleme dosyası
  • NGINX erişim günlükleri (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
  • Mesaj İşleyici sistem günlükleri (/opt/apigee/var/log/edge-message-processor/logs/system.log)