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 zaman aşımı hatası alıyor veya API isteği Apigee'de yürütülmeye devam ederken istek aniden sonlandırılıyor.

Bu tür API istekleri için API İzleme ve NGINX erişim günlüklerinde 499 durum kodunu görürsünüz. API Analytics, Mesaj İşleyici tarafından döndürülen durum kodunu gösterdiğinden bazen farklı durum kodları görürsünüz.

Hata mesajı

İstemci uygulamaları şu gibi hatalar görebilir: 

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

İstemci zaman aşımlarına ne neden olur?

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

Apigee Edge platformundaki yönlendiriciler ve mesaj işlemciler, API isteklerinin tamamlanmasının çok uzun sürmemesi için 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 istemcilerde, 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, bir API isteği Edge'de alındıktan sonra arka uç yanıtı ve yürütülen tüm politikalar da dahil olmak üzere API proxy'sinin yanıt geri gönderilene kadar yürütebileceğ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önlendiricilerde ve sanal ana makinelerde geçersiz kılınabilir.

Mesaj işleyicilerde zaman aşımı

Message Processor'larda yapılandırılan varsayılan zaman aşımı 55 saniyedir. Bu, arka uç sunucusunun isteği işleyip Mesaj İşleyici'ye yanıt vermesi için gereken maksimum süredir. Varsayılan zaman aşımı, Mesaj İşleyicilerde G/Ç zaman aşımını yapılandırma bölümünde açıklandığı gibi Mesaj İşleyicilerde veya API proxy'sinde geçersiz kılınabilir.

İstemci, API proxy'si zaman aşımına uğramadan önce Router ile bağlantıyı kapatırsa belirli API isteği için zaman aşımı hatası görürsünüz. Bu tür istekler için durum kodu 499 Client Closed Connection, yönlendiriciye kaydedilir. Bu durum, API izleme ve NGINX erişim günlüklerinde gözlemlenebilir.

Olası nedenler

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

Neden Açıklama Aşağıdaki ürünler için geçerli sorun giderme talimatları
İstemci bağlantıyı aniden kapattı Bu durum, son kullanıcının tamamlanmadan önce isteği iptal etmesi nedeniyle istemci bağlantıyı kapattığında meydana gelir. Herkese açık ve özel bulut kullanıcıları
İstemci uygulaması zaman aşımı Bu durum, API proxy'sinin yanıtı işleyip göndermesi için yeterli süre geçmeden istemci uygulamasının zaman aşımına uğraması durumunda meydana gelir. Bu durum genellikle istemci zaman aşımı, yönlendirici zaman aşımından daha kısa olduğunda meydana gelir. Herkese açık ve özel bulut kullanıcıları

Sık karşılaşılan 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 İzleme'yi kullanarak hatayı teşhis etmek için:

  1. Analyze > API Monitoring > Investigate (Analiz > API İzleme > İnceleme) 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 hataları olan bir hücre seçin:

  5. Sağdaki bölmede 499 hatasıyla ilgili bilgileri aşağıdaki gibi 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:Bu, aramaları yapmak için kullanılan istek yöntemini ve URI'yi sağlar.
    • Yanıt Süresi:Bu metrik, istek için geçen toplam süreyi gösterir.

    API İzleme GET logs 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şlemlere ait tüm günlükleri indirebilirsiniz.

    API İzleme, HTTP - hataları için proxy'yi 499 olarak ayarladığından, sanal ana makine ve yolla ilişkili proxy'yi almak için API'yi (Günlükler API'si) 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. Ek 499 hata için Yanıt Süresi'ni inceleyin ve Yanıt Süresi'nin tüm 499 hatalarda 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. Özel bulut kullanıcısıysanız HTTP 499 hatalarıyla ilgili temel 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. 499 Belirli bir süre boyunca hatalar (sorun geçmişte yaşandıysa) olup olmadığını veya 499 ile hâlâ başarısız olan istekler olup olmadığını kontrol etmek 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 örnekte aşağıdaki bilgileri görüyoruz:

    • 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
    • Düzenleyen:api.acme.org
    • Kullanıcı aracısı:okhttp/3.9.1
  5. Tüm 499 hatalarında Toplam Yanıt Süresi ve Kullanıcı Aracısı değerlerinin tutarlı olup olmadığını kontrol edin.

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

Teşhis

  1. Bir tarayıcıda veya mobil uygulamada çalışan tek sayfalık bir uygulamadan bir API çağrıldığında, son kullanıcı tarayıcıyı aniden kapatırsa, aynı sekmede başka bir web sayfasına giderse veya yüklemeyi durdur'u tıklayarak ya da dokunarak sayfanın yüklenmesini durdurursa tarayıcı isteği iptal eder.
  2. Bu durumda, HTTP 499 durumuna sahip işlemlerin istek işleme süresi (Yanıt Süresi) genellikle her istek için farklılık gösterir.
  3. Bunun nedeni olup olmadığını belirlemek için Yanıt Süresi'ni karşılaştırabilir ve Genel teşhis adımları bölümünde açıklandığı gibi API izleme veya NGINX erişim günlüklerini kullanarak 499 hataların her biri için farklı olup olmadığını doğrulayabilirsiniz.

Çözünürlük

  1. Bu durum normaldir ve HTTP 499 hataları az sayıda gerçekleşiyorsa genellikle endişelenmenize gerek yoktur.

  2. Aynı URL yolu için sık sık yaşanıyorsa bu durum, söz konusu yolla ilişkili belirli bir proxy'nin çok yavaş olmasından ve kullanıcıların beklemek istememesinden kaynaklanabilir.

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

    1. Bu durumda, Ortak 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 paneli'ni kullanın.
    3. Gecikmenin belirli bir proxy için beklendiğini düşünüyorsanız kullanıcılarınızı bu proxy'nin yanıt vermesinin biraz zaman alacağı konusunda bilgilendirmeniz gerekebilir.

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

Bu durum, çeşitli senaryolarda yaşanabilir.

  1. İsteğin normal çalışma koşullarında tamamlanmasının belirli bir süre (örneğin 10 saniye) sürmesi beklenir. Ancak istemci uygulaması yanlış bir zaman aşımı değeriyle (örneğin 5 saniye) ayarlanır. Bu durum, API isteği tamamlanmadan önce istemci uygulamasının zaman aşımına uğramasına ve 499'ya yol açar. Bu durumda, istemci zaman aşımını uygun bir değere ayarlamamız gerekir.
  2. Bir hedef sunucu veya geri çağırma işlemi beklenenden uzun sürüyor. Bu durumda, uygun bileşeni düzeltmeniz ve zaman aşımı değerlerini de uygun şekilde ayarlamanız gerekir.
  3. İstemci artık yanıta ihtiyaç duymadığı için işlemi iptal etti. Bu durum, otomatik tamamlama veya kısa süreli yoklama gibi yüksek sıklıklı API'lerde görülebilir.

Teşhis

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

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

  1. Genel teşhis adımları başlıklı makalede açıklandığı gibi HTTP 499 işlemleri için API izleme günlüklerini veya NGINX erişim günlüklerini kontrol edin.
  2. 499 hatalarının tümünde Yanıt Süresi'nin tutarlı olup olmadığını belirleyin.
  3. 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 istemcinin zaman aşımı, proxy'nin zaman aşımına uğramasından önce gerçekleşir. Bu da aynı URI yolu için büyük miktarda HTTP 499s ile sonuçlanır. Bu durumda, belirli bir istemci uygulamasını belirlemenize yardımcı olabilecek NGINX erişim günlüklerinden Kullanıcı Aracısı'nı belirleyin.
  4. Ayrıca Apigee'nin önünde Akamai, F5, AWS ELB gibi bir yük dengeleyici de olabilir. Apigee, özel bir yük dengeleyicinin 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önlendiricinin zaman aşımı süresi 57 saniyedir. Bu nedenle, yük dengeleyicide 60 saniyelik bir istek zaman aşımı yapılandırmak uygundur.

Trace

Trace'i kullanarak hatayı teşhis etme

Sorun devam ediyorsa (499 hataları 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. Hatayı bekleyin veya API çağrınız varsa bazı API çağrıları yapıp hatayı yeniden oluşturun.
  3. Her aşamada geçen süreyi kontrol edin ve en çok zamanın harcandığı aşamayı not alın.
  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ı

    Hedef sunucuya İstek gönderildikten sonra Ağ Geçidi Zaman Aşımı'nı gösteren örnek bir kullanıcı arayüzü izi aşağıda 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ırma ile ilgili en iyi uygulamalar başlıklı makaleyi inceleyin.
  2. En iyi uygulamalara uygun olarak istemci uygulamasında uygun bir zaman aşımı değeri ayarladığınızdan emin olun.

Sorun devam ederse Toplanması gereken teşhis bilgileri bölümüne gidin .

Teşhis bilgilerini toplamalıdır

Sorun devam ederse aşağıdaki teşhis bilgilerini toplayın ve 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'si adı
  • Zaman aşımı hatasını yeniden oluşturmak için kullanılan curl komutunu tamamlayın.
  • İstemci zaman aşımı hataları aldığınız API isteklerinin izleme dosyası

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

  • Başarısız olan istekler için gözlemlenen hata mesajının tamamı
  • Ortam adı
  • API proxy paketi
  • İstemci zaman aşımı hataları aldığınız API isteklerinin 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)