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 Internal Server Error (Dahili Sunucu Hatası) mesajıyla birlikte bir HTTP yanıt durum kodu 500 alır.

Hata mesajları

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

HTTP/1.1 500 Internal Server Error

Bunun ardından şu gibi 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ı, çeşitli nedenlerden kaynaklanabilir. Bu oyun kitabı, akış etkinleştirildiğinde istek/yanıt yüküne erişilmesi nedeniyle oluşan 500 dahili sunucu hatasına odaklanmaktadır.

Neden: Akış etkinleştirilmişken yüke erişme

Teşhis

1. Prosedür: Trace'i kullanma

1. İzleme oturumunu etkinleştirin ve sorunu (500 Dahili Sunucu Hatası) yeniden oluşturmak için API çağrısı yapın.
2. Başarısız olan isteklerden birini seçip izlemeyi inceleyin.
3. İzlemenin çeşitli aşamalarında gezinin ve hatanın nerede oluştuğunu bulun.
4. Bu hata, bir politika isteği/yanıt yükünü ayrıştırırken oluşmuş olabilir.
5. JSONThreatProtection politikasının "1. satırda } bekleniyor" hatasıyla başarısız olduğunu gösteren örnek bir izleme ekran görüntüsü:

   

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

   Başarısız olan politika: JSONThreatProtection

   Akış: Proxy İsteği

6. Başarısız olan 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ı inceleyin 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. işaret ettiğini unutmayın. Bu, isteğin yükü ayrıştırılırken hata oluştuğu anlamına gelir.

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

İstek yükünün içeriğini ve Content-Type başlığını API isteğinde kontrol edebilirsiniz. Aşağıdaki örnek curl komutunda bir JSON yükü kullanılmaktadı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 oluyor. 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çersizse 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, yayın etkinleştirilmişken yükün erişilebilir olmasıdır.

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

   Örnek senaryoda, istek yükü ayrıştırılıyor. Bu nedenle, izlemedeki "Request Received from Client" (İstemciden Alınan İstek) aşamasını inceleyin ve Request Content (İstek İçeriği) bölümünü kontrol edin.

   

   Geçerli bir yük göndermiş olmanıza rağmen yukarıdaki ekran görüntüsünde gösterildiği gibi İstek İçeriği'nin boş olduğu tespit edilirse bu sorunun olası nedeninin istek akışının etkinleştirilmiş olması olduğu anlaşılır.

   Bunun nedeni, akış etkinleştirildiğinde istek yükünün izlemede 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 kullanıldığı yere bağlı olarak Proxy ve Hedef Uç Nokta tanımlarını inceleyin. Yayın özelliğinin etkinleştirilip etkinleştirilmediğini doğrulayın.

    Örnek senaryoda, başarısız olan politika Proxy isteği akışında yürütülmüştür (yukarıdaki 5. adımda belirlendiğ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, "request.streaming.enabled" özelliği true olarak ayarlandığı için istek akışı etkinleştirilmiştir.

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

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

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

       

    2. Aşama Ayrıntıları'nda "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:

       

    3. Yukarıdaki resimde gösterildiği gibi "X-Apigee-fault-source" değeri "policy" ise bu, hatanın, akış etkinleştirildiğinde politikanın yük erişiminden kaynaklandığını gösterir.

Çözünürlük

Akış etkinleştirilmişken yüke erişmek, Antipattern: Access the request/response payload when streaming is enabled (Antipatern: Akış etkinleştirilmişken istek/yanıt yüküne erişme) başlıklı makalede açıklandığı gibi bir antipaterndir.

1. Yükü işlemek istiyorsanız Proxy/Hedef uç noktasında akışı devre dışı bırakmanız gerekir. Bunun için aşağıdaki örnek ProxyEndpoint'te gösterildiği gibi "request.streaming.enabled" and "response.streaming.enabled" özelliklerini kaldırın:

   <ProxyEndpoint name="default">
   ...
     <HTTPProxyConnection>
       <BasePath>/v1/weather</BasePath>
       <VirtualHost>secure</VirtualHost>
     </HTTPProxyConnection>
   </ProxyEndpoint>

   VEYA

2. API proxy'lerinizde akış kullanmak istiyorsanız API proxy'de istek/yanıt yüküne erişen politikalar kullanmayın.

Not:

• Bu oyun kitabında, örnek senaryoda akış etkinleştirilmişken istek yükünü işlemek için JSONThreatProtection politikası kullanılmıştır. Bu durum, farklı hatalarla birlikte 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.
• Yayın etkinleştirildiğinde yük erişimi gerektiren proxy'lerde bu tür politikaların kullanılmaması kesinlikle önerilir.
• Bu işlem, Antipattern: Access the request/response payload when streaming is enabled (Antipatern: Akış etkinleştirildiğinde istek/yanıt yüküne erişme) başlıklı makalede belirtildiği gibi bir antipaterndir.

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

Özel bulut kullanıcısıysanız bu prosedürü atlayın.

API Monitoring, hata, performans ve gecikme sorunlarını ve bunların kaynağı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 İzleme'yi kullanarak API'lerinizdeki 5xx sorunlarını nasıl gidereceğinizi gösteren örnek bir senaryoyu adım adım inceleyin. Örneğin, 500 hatalarının sayısı belirli bir eşiği aştığında bildirim almak için uyarı ayarlamak isteyebilirsiniz.

Politikadan 500 hata yanıtı gönderildiğinde bildirim almak istiyorsanız 500 durum kodu için uyarıyı hata kaynağı olarak Proxy ile ayarlamanız gerekir.

Toplanması Gereken Teşhis Bilgileri

Yukarıdaki talimatları uyguladıktan sonra sorun devam ederse lütfen aşağıdaki teşhis bilgilerini toplayın. Bunları Apigee Destek Ekibi ile iletişime geçerek paylaşın.

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

• Kuruluş Adı
• Ortam adı
• API Proxy'sinin Adı
• 500 hatasını yeniden oluşturmak için istek yüküyle (varsa) birlikte curl komutunu tamamlayın.
• 500 dahili sunucu hatası içeren istekleri içeren izleme dosyası
• 500 hataları şu anda oluşmuyorsa geçmişte 500 hatalarının oluştuğu zaman aralığını saat dilimi bilgisiyle birlikte belirtin.

Özel bulut 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ı
• 500 hatası gözlemlediğiniz kuruluş, ortam adı ve API proxy adı
• API Proxy Paketi
• İstekte kullanılan yük (varsa)
• 500 dahili sunucu hatası içeren 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 hatasının oluştuğu saat dilimi bilgisine sahip zaman aralığı.