500 Dahili Sunucu Hatası - Akış etkin

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

Belirti

İstemci uygulaması, API çağrıları için Dahili Sunucu Hatası mesajıyla birlikte, 500 HTTP yanıt durum kodunu alır.

Hata mesajları

İstemci uygulamalar aşağıdaki gibi bir hata yanıtı alabilir: 

HTTP/1.1 500 Internal Server Error

Bu ifadenin ardından aşağıdakine benzer bir hata mesajı gösterilebilir: 

{
   "fault":{
      "faultstring":"Expecting } at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

OR

{
   "fault":{
      "faultstring":"Expecting ] at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

Olası nedenler

500 Dahili Sunucu Hatası, birkaç farklı nedenden kaynaklanabilir. Bu başucu kitabı, akış etkinken istek/yanıt yüküne erişimden kaynaklanan 500 Dahili Sunucu Hatasına odaklanmaktadır.

Neden Açıklama Sorun giderme adımlarını kimler uygulayabilir?
Akış Etkin durumdayken Yüke Erişim Akış etkinleştirildiğinde istek/yanıt yüküne erişildiği için bir hata oluştu. Edge'de Özel ve Herkese Açık Bulut Kullanıcıları

Neden: Akış Etkin durumdayken Yüke Erişme

Teşhis

1. Prosedür: Trace'i Kullanma

  1. İzleme oturumunu etkinleştirin ve sorunu yeniden oluşturmak için API çağrısını yapın: 500 Dahili Sunucu Hatası.
  2. Başarısız isteklerden birini seçip izi inceleyin.
  3. İzin çeşitli aşamaları arasında gezinin ve hatanın nerede gerçekleştiğini bulun.
  4. Bir politika istek/yanıt yükünü ayrıştırırken bu hata oluşmuş olabilir.
  5. Aşağıda, JSONThreatProtection politikasının "1. satırda } bekleniyor" hatasıyla başarısız olduğunu gösteren örnek bir iz ekran görüntüsü verilmiştir:

    alt_text

    Yukarıdaki ekran görüntüsünde gösterildiği gibi iz çıkışındaki aşağıdaki bilgileri not edin:

    Başarısız Politika: JSONThreatProtection

    Akış: Proxy İsteği

  6. Başarısız politika tanımını inceleyin ve ayrıştırılan yükü kontrol edin.

    Örnek senaryoda, başarısız olan JSON-Threat-Protection adlı JSONThreatProtection politikasını inceleyip <Source> öğesini kontrol edin. 

    <JSONThreatProtection async="false" continueOnError="false" enabled="true" name="JSON-Threat-Protection">
   <DisplayName>JSON Threat Protection</DisplayName>
   <ArrayElementCount>20</ArrayElementCount>
   <ContainerDepth>10</ContainerDepth>
   <ObjectEntryCount>15</ObjectEntryCount>
   <ObjectEntryNameLength>50</ObjectEntryNameLength>
   <Source>request</Source>
   <StringValueLength>1000</StringValueLength>
</JSONThreatProtection>

    <Source> öğesinin request. öğesine işaret ettiğine dikkat edin. Bu, hatanın istek yükü ayrıştırılırken oluştuğu anlamına gelir.

  7. API isteğini kontrol ederek ayrıştırılan yükün türünü belirleyin.

    8. API isteğinde istek yükünün içeriğini ve Content-Type başlığını kontrol edebilirsiniz. Aşağıdaki örnek curl komutunda bir JSON yükü kullanılmıştır. 

    curl -i https://VIRTUAL_HOST_ALIAS/BASEPATH -H "Content-Type: application/json" \
-X POST -d @request-payload.json

    Ayrıca, başarısız olan politikayı kontrol edebilir ve ayrıştırılan yükün türünü belirleyebilirsiniz. Yukarıdaki örnek senaryoda, JSON-Threat-Protection politikası başarısız olmuştur. Bu, yükün JSON biçiminde olması gerektiğini gösterir.

  8. Yükün uygun biçimde olup olmadığını doğrulayın. Yük geçerli değilse bu hatayı alabilirsiniz.

  9. Yük geçerliyse ancak Hata Mesajları bölümünde listelenen hataları almaya devam ediyorsanız bu hataların nedeni, akış etkinleştirildiğinde yüke erişiliyor olmasıdır.

    Politika tarafından ayrıştırılan yüke bağlı olarak (6. adımda belirtildiği gibi), İzleme aracındaki yük içeriğini uygun aşamada inceleyin.

    Örnek senaryoda, istek yükü ayrıştırılıyor. Bu nedenle izdeki "İstekten Alınan İstek" aşamasını ve İçerik İsteği

    alt_text

    Geçerli bir yük göndermiş olsanız bile, İstek İçeriği'nin yukarıdaki ekran görüntüsünde gösterildiği gibi boş olduğu tespit edilirse bu sorunun olası nedeni, akış isteğinin etkin olmasından kaynaklanmaktadır.

    Bunun nedeni, akış etkinleştirildiğinde istek yükünün izde görünmemesidir.

    Benzer şekilde, hata oluştuğunda yanıt yükü ayrıştırılıyorsa "Hedef sunucudan alınan yanıt" aşamasındaki yanıt içeriğini kontrol edin.

  10. Ardından, başarısız olan politikanın API Proxy akışında nerede kullanıldığına bağlı olarak Proxy ve Hedef Uç Nokta tanımlarını inceleyin. Akışın etkinleştirilip etkinleştirilmediğini doğrulayın.

    Örnek senaryoda, başarısız olan politika Proxy istek akışında yürütülmüştür (yukarıdaki 5. adımda belirtildiği gibi). Bu nedenle, Proxy Uç Noktası'nı inceleyin: 

    <ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
    <Properties>
      <Property name="response.streaming.enabled">true</Property>
      <Property name="request.streaming.enabled">true</Property>
    </Properties>
  </HTTPProxyConnection>
</ProxyEndpoint>

    Yukarıdaki örnekte görüldüğü gibi istek akışı, "request.streaming.enabled" özelliğinin doğru değerine ayarlanmış olarak gösterildiği şekilde etkinleştirildi.

    Bu nedenle, hatanın nedeni API proxy'sinde, akış etkinleştirildiğinde istek yüküne erişen JSONThreatProtection politikasını kullanmaktır. Bu durum, API Proxy'sinde arabelleğe almayı tetiklediği ve Apigee Edge'de akış kullanma amacını ortadan kaldırdığı için hatalara neden olur.

    Bu hata, daha küçük yüklerde görünmeyebilir ancak daha büyük yük kullandığınızda bu hataları görebilirsiniz.

  11. 500 hatasının politikadan kaynaklandığını doğrulamak için izlemedeki "AX" (Analytics Verileri Kaydedildi) aşamasında "X-Apigee-fault-source" değerinin değerini kontrol edebilirsiniz. Bunun için aşağıdaki adımları uygulayın:
    1. Aşağıdaki ekran görüntüsünde gösterildiği gibi "AX" (Analytics Data Recorded) Stage (Analytics Verileri Kaydedilen) Aşaması'nı tıklayın.

      alt_text

    2. Aşama Ayrıntıları'nı aşağı kaydırarak "Hata Başlıkları" bölümüne gidin ve aşağıda gösterildiği gibi "X-Apigee-fault-code", "X-Apigee-fault-source" ve "X-Apigee-fault-policy" değerlerini belirleyin:

      alt_text

    3. "X-Apigee-fault-source" değerinin yukarıdaki resimde gösterildiği gibi "policy" olması, hatanın akış etkin durumdayken yüke erişen politikadan kaynaklandığını belirtir.

Çözünürlük

Akış etkinken yüke erişmek, Anti Kalıp: Akış etkinken istek/yanıt yüküne erişme bölümünde açıklandığı gibi bir anti kalıptır.

  1. Yükü işlemek istiyorsanız Proxy/Hedef Uç Noktası'nda akışı devre dışı bırakmanız gerekir. Bunu yapmak için aşağıdaki örnekte ProxyEndpoint'te gösterildiği gibi "request.streaming.enabled" and "response.streaming.enabled" özellikleri kaldırın: 
    <ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>

    VEYA

  2. API Proxy'leriniz için akış kullanmak istiyorsanız API Proxy'sinde, istek/yanıt yüküne erişen politikaları kullanmayın.

Not:

  • Bu başucu kitabında, örnek senaryoda akış etkinken istek yükünü işlemek için JSONThreatProtection politikası kullanılmıştır. Bu durum, farklı hatalara sahip 500 Dahili Sunucu Hatası'na yol açtı.
  • Bu hatalar, akış etkinleştirildiğinde istek veya yanıt yüklerini işleyen JSONToXML ve XMLToJSON gibi politikalarda da görülebilir.
  • Akış etkinleştirildiğinde yüklere erişim gerektiren proxy'lerde bu tür politikaları kullanmamanızı önemle tavsiye ederiz.
  • Bunu yapmak, Antipattern: Akış etkinleştirildiğinde istek/yanıt yüküne erişme bölümünde açıklandığı gibi bir antipattern işlemini gerçekleştirir.

API Monitoring'i kullanarak sorunları teşhis etme

Private Cloud kullanıcısıysanız bu prosedürü atlayın.

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ızla ayırmanızı sağlar.

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

Politikadan bir 500 hata yanıtı atıldığında bildirim almak isterseniz, 500 durum kodu için bir uyarı oluşturmanız ve hata kaynağı değerini Proxy olarak ayarlamanız gerekir.

Teşhis Bilgileri Toplanmalı

Yukarıdaki talimatları uygulamanıza rağmen sorun devam ederse lütfen aşağıdaki teşhis bilgilerini toplayın. Apigee Desteği ile iletişime geçin ve paylaşın.

Herkese Açık Bulut kullanıcısıysanız aşağıdaki bilgileri sağlayın:

  • Kuruluş Adı
  • Ortam Adı
  • API Proxy Adı
  • 500 hatasını yeniden oluşturmak için curl komutunu (varsa) istek yüküyle birlikte tamamlayın
  • 500 Dahili Sunucu Hatası olan istekleri içeren izleme dosyası
  • 500 hataları şu anda ortaya çıkmıyorsa, geçmişte 500 hatalarının oluştuğu zaman dilimiyle ilgili zaman dilimi bilgisini sağlayın.

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ı
  • 500 hatası gördüğünüz Kuruluş, Ortam Adı ve API Proxy Adı
  • API Proxy Paketi
  • İstekte kullanılan yük (varsa)
  • 500 Dahili Sunucu Hatası olan istekleri içeren izleme dosyası
  • NGINX erişim günlükleri (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
  • Mesaj İşleyici günlükleri (/opt/apigee/var/log/edge-message-processor/logs/system.log)
  • 500 hatalarının oluştuğu saat dilimi bilgilerinin yer aldığı dönem.