500 Dahili Sunucu Hatası - Akış etkin

Apigee Edge belgelerini görüntülüyorsunuz.
. Git: Apigee X belgeleri. bilgi

Belirti

İstemci uygulaması 500 HTTP yanıt durum kodunu API çağrıları için Dahili Sunucu Hatası mesajını görürsünüz.

Hata mesajları

İstemci uygulamaları aşağıda gösterildiği gibi bir hata yanıtı alabilir: 

HTTP/1.1 500 Internal Server Error

Bu hatanın ardından şuna 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ı, birçok farklı nedenden kaynaklanabilir. Bu başucu kitabı İsteğe/yanıta erişimden kaynaklanan 500 Dahili Sunucu Hatası'na odaklanır akış sırasındaki yük etkin olduğundan emin olun.

Neden Açıklama Sorun giderme adımlarını kimler gerçekleştirebilir?
Yüke erişmek için kullanılan Akış Etkin Akış etkinleştirildiğinde istek/yanıt yüküne erişildiği için bir hata oluştu. Edge Ö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. İzlemeyi etkinleştir oturumu tıklayın 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çin ve izini inceleyin.
  3. İzlemenin çeşitli aşamaları arasında gezinin ve hatanın nerede oluştuğunu bulun.
  4. Bir politika istek/yanıt yükünü ayrıştırırken bu hata oluşmuş olabilir.
  5. JSONThreatProtection etiketini gösteren örnek bir izleme ekran görüntüsünü burada bulabilirsiniz. politikası "Expecting } at line 1" (1. satırda bekleniyor):

    alt_text

    Yukarıdaki örnekte gösterildiği gibi, iz çıkışında bulunan aşağıdaki bilgileri not edin ekran görüntüsü:

    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, adlı JSONThreatProtection politikasını inceleyin. Başarısız olan JSON-Threat-Protection öğesini seçin ve <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, istek yükü ayrıştırılırken hata oluştu.

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

    8. İstek yükünün ve Content-Type başlığının içeriğini API isteği. 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 ederek yükün türünü belirleyebilirsiniz. ayrıştırılır. Yukarıdaki örnek senaryoda JSON-Threat-Protection politikası başarısızdır. Bu, yükün JSON biçiminde olması gerektiğini belirtir.

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

  9. Yük geçerliyse ancak Error Messages (Hata Mesajları) bölümü ve bu hataların nedeni akış etkinleştirildiğinde yüke erişiliyor olması.

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

    Örnek senaryoda istek yükü ayrıştırılmaktadır. Bu nedenle, İzlemedeki "İstek İstemciden Alındı" aşamasını inceleyip İçerik İsteyin.

    alt_text

    Yukarıdaki ekran görüntüsünde gösterildiği gibi İstek İçeriği boş bulunursa, geçerli bir yük gönderirseniz bu, sorunun olası nedeninin etkin olduğundan emin olun.

    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 şunu kontrol edin: "Hedef sunucudan yanıt alındı" aşamasındaki yanıt içeriğini gösterir.

  10. Ardından, hatalı taramanın nerede olduğuna bağlı olarak Proxy ve Hedef Uç Nokta tanımlarını politikası da API Proxy akışında kullanılır. 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 şekilde); 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ği doğru değerine ayarlandı.

    Bu nedenle, hatanın nedeni API Proxy'sinde JSONThreatProtection politikasını kullanmaktır akış etkinleştirildiğinde istek yüküne erişen bir veri kümesi kullanır. Bu durum, API Proxy'de arabelleğe almayı tetikler ve Apigee Edge'de akış işlevini ortadan kaldırır.

    Bu hata daha küçük yüklerde görülmeyebilir ancak daha büyük yükler kullandığınızda bu hataları görebilir.

  11. Değeri kontrol ederek 500 hatasının politikadan kaynaklandığını doğrulayabilirsiniz &quot;X-Apigee-fault-source&quot; (Analytics Verileri Kaydedildi) Aşağıda verilen adımları kullanarak izleme aşamasında aşamayı tamamlayın:
    1. "AX" (Analytics Verileri Kaydı) Aşaması'nı tıklayın aşağıdaki ekran görüntüsünde gösterildiği gibi:

      alt_text

    2. Aşama Ayrıntıları'nda "Error Headers" (Hata Başlıkları) bölümüne gidin bölümüne ve "X-Apigee-fault-code" değerlerini belirleyin, &quot;X-Apigee-fault-source&quot; ve "X-Apigee-fault-policy" Aşağıda gösterildiği gibi:

      alt_text

    3. &quot;X-Apigee-fault-source&quot; değeri "policy" ise gösterildiği gibi bu, hatanın ek yük oluşturabilirsiniz.

Çözünürlük

Akış etkinken yüke erişmek, Antipattern: Akış etkinleştirildiğinde istek/yanıt yüküne erişin.

  1. Yükü işlemek isterseniz Proxy/Target (Proxy/Hedef) bölümünde akışı devre dışı bırakmanız gerekir Aşağıdaki örnek ProxyEndpoint'te gösterildiği gibi "request.streaming.enabled" and "response.streaming.enabled" özelliklerini kaldırarak uç nokta: 
    <ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>

    VEYA

  2. API Proxy'leriniz için akış kullanmak istiyorsanız şu bölümünde herhangi bir politika kullanmayın: İstek/yanıt yüküne erişen API Proxy'si.

Not:

  • Bu başucu kitabında, istek yükünü aktarmanın etkinleştirildiğinden emin olun. Bu durum, farklı hatalar içeren 500 Dahili Sunucu Hatası'na yol açmıştır.
  • Bu hatalar, JSON3 veya XMLToJSON gibi politikalarla da görülebilir. istek veya yanıt yüklerini görebilirsiniz.
  • Erişim gerektiren proxy'lerde bu tür politikaların kullanılmamasını önemle tavsiye ederiz. yük yükleme işlemidir.
  • Bu, aşağıda açıklandığı gibi bir anti kalıp Antipattern: Akış etkinleştirildiğinde istek/yanıt yüküne erişin.

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ızlı bir şekilde izole 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, 500 Hata sayısı belirli bir eşiği aştığında bildirim almak için bir uyarı oluşturmak isteyebilirsiniz.

Politikadan 500 hata yanıtı atıldığında bildirim almak istiyorsanız uyarıyı 500 durum kodu için ayarlamanız ve hata kaynağını Proxy olarak ayarlamanız gerekir.

Teşhis Bilgileri Toplanmalıdır

Yukarıdaki talimatları uygulamanıza rağmen sorun devam ederse lütfen aşağıdaki teşhis bilgilerini toplayın. Apigee Destek Ekibi ile iletişime geçip 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 ve istek yükü (varsa) tamamlayın
  • 500 Dahili Sunucu Hatası'na sahip istekleri içeren izleme dosyası
  • Şu anda 500 hataları görünmüyorsa, geçmişte 500 hatanın oluştuğu zaman dilimi bilgilerini saat dilimi bilgileriyle sağlayın.

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

  • Başarısız istekler için tam hata mesajı gözlemlendi
  • 500 hatalarını gözlemlediğiniz Kuruluş, Ortam Adı ve API Proxy Adı
  • API Proxy Paketi
  • İstekte kullanılan yük (varsa)
  • 500 Dahili Sunucu Hatası'na sahip 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 ortaya çıktığı saat dilimi bilgilerini içeren dönem.