500 Dahili Sunucu Hatası

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

Videolar

500 dahili sunucu hatalarını çözme hakkında daha fazla bilgi edinmek için aşağıdaki videoları izleyin.

Belirti

İstemci uygulaması, API çağrılarına yanıt olarak "Dahili Sunucu Hatası" mesajıyla 500 HTTP durum kodunu alır. 500 dahili sunucu hatası, Edge'deki herhangi bir politikanın yürütülmesi sırasında oluşan bir hatadan veya hedef/arka uç sunucusundaki bir hatadan kaynaklanabilir.

HTTP durum kodu 500, genel bir hata yanıtıdır. Bu, sunucunun isteği yerine getirmesini engelleyen beklenmedik bir durumla karşılaştığı anlamına gelir. Bu hata genellikle başka bir hata kodu uygun olmadığında sunucu tarafından döndürülür.

Hata mesajları

Aşağıdaki hata mesajını alabilirsiniz:

HTTP/1.1 500 Internal Server Error

Bazı durumlarda, daha ayrıntılı bilgiler içeren başka bir hata mesajı görebilirsiniz. Aşağıda örnek bir hata mesajı verilmiştir:

{
   "fault":{
      "detail":{
         "errorcode":"steps.servicecallout.ExecutionFailed"
      },
      "faultstring":"Execution of ServiceCallout callWCSAuthServiceCallout failed. Reason: ResponseCode 400 is treated as error"
   }
}

Olası nedenler

500 Dahili Sunucu Hatası, çeşitli nedenlerden kaynaklanabilir. Edge'de nedenler, hatanın oluştuğu yere göre iki ana kategoride sınıflandırılabilir:

Edge politikasında yürütme hatası

API proxy'sindeki bir politika, bazı nedenlerden dolayı başarısız olabilir. Bu bölümde, bir politika yürütülürken 500 Dahili Sunucu Hatası oluşması durumunda sorunun nasıl giderileceği açıklanmaktadır.

Teşhis

Özel ve genel bulut kullanıcıları için teşhis adımları

Hata için izleme kullanıcı arayüzü oturumunuz varsa:

1. Hataya bir politikanın yürütülmesinin neden olduğunu doğrulayın. Ayrıntılar için Sorunun kaynağını belirleme bölümüne bakın.
2. Hata politika yürütme sırasında oluştuysa devam edin. Hata arka uç sunucusundan kaynaklanıyorsa Arka Uç Sunucusunda Hata bölümüne gidin.
3. İzde 500 Dahili Sunucu Hatası ile başarısız olan API isteğini seçin.
4. İsteği inceleyin ve başarısız olan politikayı ya da izlemede başarısız olan politikayı hemen takip eden "Hata" adlı akışı seçin.
5. Özellikler bölümündeki "hata" alanını veya hata içeriğini kontrol ederek hata hakkında daha fazla bilgi edinin.
6. Hata hakkında topladığınız ayrıntıları kullanarak hatanın nedenini belirlemeye çalışın.

Yalnızca Özel Bulut Kullanıcıları İçin Teşhis Adımları

İzleme kullanıcı arayüzü oturumunuz yoksa:

1. Hatayı bir politikanın yürütülmesi sırasında oluştuğunu doğrulayın. Ayrıntılar için Sorunun kaynağını belirleme bölümüne bakın.
2. Hata politika yürütülmesinden kaynaklanıyorsa devam edin. Hata politika yürütme sırasında oluştuysa devam edin. Hata arka uç sunucusundan kaynaklanıyorsa Arka Uç Sunucusunda Hata bölümüne gidin.
3. API proxy'sinde başarısız olan politikayı ve benzersiz istek mesajı kimliğini belirlemek için Sorunun kaynağını belirleme bölümünde açıklandığı şekilde NGINX erişim günlüklerini kullanın.
4. Mesaj İşleyici günlüklerini (/opt/apigee/var/log/edge-message-processor/logs/system.log) kontrol edin ve benzersiz istek mesajı kimliğini arayın.
5. Benzersiz istek mesajı kimliğini bulursanız hatanın nedeni hakkında daha fazla bilgi alıp alamayacağınızı kontrol edin.

Çözünürlük

Politikayla ilgili sorunun nedenini belirlediyseniz politikayı düzelterek ve proxy'yi yeniden dağıtarak sorunu düzeltmeyi deneyin.

Aşağıdaki örneklerde, farklı türlerdeki sorunların nedeninin ve çözümünün nasıl belirleneceği gösterilmektedir.

500 Dahili Sunucu Hatası'nı giderme konusunda daha fazla yardıma ihtiyacınız varsa veya bunun Edge'de bir sorun olduğunu düşünüyorsanız Apigee Destek Ekibi ile iletişime geçin.

1. örnek: Arka uç sunucusundaki bir hata nedeniyle hizmet çağrısı politikasında hata oluşması

Arka uç sunucusuna yapılan çağrı, 4XX veya 5XX gibi bir hatayla Hizmet Çağrısı politikası kapsamında başarısız olursa 500 Dahili Sunucu Hatası olarak değerlendirilir.

1. Arka uç hizmetinin, Service Callout politikasında 404 hatasıyla başarısız olduğu bir örneği burada bulabilirsiniz. Son kullanıcıya aşağıdaki hata mesajı gönderilir:

   {
   "fault":
        { "detail":
              { "errorcode":"steps.servicecallout.ExecutionFailed"
              },"faultstring":"Execution of ServiceCallout service_callout_v3_store_by_lat_lon
    failed. Reason: ResponseCode 404 is treated as error"
             }
        }
   }

2. Aşağıdaki izleme kullanıcı arayüzü oturumunda, Service Callout politikasındaki bir hata nedeniyle 500 durum kodu oluştuğu gösterilmektedir:

   

3. Bu örnekte, "error" özelliği, Hizmet Çağrısı politikasının başarısız olma nedenini "ResponseCode 404 is treated as error" (Yanıt kodu 404 hata olarak değerlendirilir) olarak listeler. Bu hata, Hizmet Çağrısı politikasındaki arka uç sunucusu URL'si üzerinden erişilen kaynak kullanılamıyorsa meydana gelebilir.
4. Kaynağın arka uç sunucusunda kullanılabilirliğini kontrol edin. Geçici veya kalıcı olarak kullanılamıyor ya da farklı bir konuma taşınmış olabilir.

1. Örnek Çözümü

1. Kaynağın arka uç sunucusunda kullanılabilirliğini kontrol edin. Geçici veya kalıcı olarak kullanılamıyor ya da farklı bir konuma taşınmış olabilir.
2. Geçerli ve mevcut bir kaynağa yönlendirmek için Hizmet Çağrısı politikasındaki arka uç sunucusu URL'sini düzeltin.
3. Kaynak yalnızca geçici olarak kullanılamıyorsa kaynak kullanılabilir hale geldiğinde API isteğini göndermeyi deneyin.

2. örnek: Değişkenleri Çıkarma Politikası'nda hata

Şimdi de Değişkenleri Ayıklama politikasındaki bir hatadan kaynaklanan 500 Dahili Sunucu Hatası'nın nasıl giderileceğini ve sorunun nasıl çözüleceğini gösteren başka bir örneğe bakalım.

1. Kullanıcı arayüzü oturumundaki aşağıdaki izleme, Değişkenleri Çıkar politikasındaki bir hata nedeniyle 500 durum kodunu gösteriyor:

   

2. Başarısız olan Değişkenleri Çıkar politikasını seçin, aşağı kaydırın ve daha fazla ayrıntı için "Hata İçeriği" bölümüne bakın:
   
   
3. Hata İçeriği, "serviceCallout.oamCookieValidationResponse" değişkeninin Değişkenleri Çıkar politikası içinde kullanılamadığını gösterir. Değişkenin adından da anlaşılacağı gibi, önceki hizmet çağrısı politikasının yanıtını içermelidir.
4. İzleme işleminde hizmet açıklama metni politikasını seçtiğinizde "serviceCallout.oamCookieValidationResponse" değişkeninin ayarlanmadığını görebilirsiniz. Bu, arka uç hizmetine yapılan çağrının başarısız olduğunu ve boş bir yanıt değişkeniyle sonuçlandığını gösterir.
5. Hizmet açıklama metni politikası başarısız olsa da Hizmet açıklama metni politikasından sonraki politikaların yürütülmesi devam eder. Bunun nedeni, Hizmet açıklama metni politikasındaki "continueOnError" işaretinin aşağıda gösterildiği gibi doğru olarak ayarlanmış olmasıdır:
   
   

   <ServiceCallout async="false" continueOnError="true" enabled="true" name="Callout.OamCookieValidation">
     <DisplayName>Callout.OamCookieValidation</DisplayName>
     <Properties />
     <Request clearPayload="true" variable="serviceCallout.oamCookieValidationRequest">
       <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
     </Request>
     <Response>serviceCallout.oamCookieValidationResponse</Response>
     <HTTPTargetConnection>
       <Properties />
       <URL>http://{Url}</URL>
     </HTTPTargetConnection>
   </ServiceCallout>

6. İzden, bu API isteği için benzersiz ileti kimliğini "X-Apigee.Message-ID" olarak not edin:
   1. İstekten "Analytics Verileri Kaydedildi" aşamasını seçin.
   2. Aşağı kaydırın ve X-Apigee.Message-ID değerini not edin.

   

7. Mesaj İşleyici günlüğünü (/opt/apigee/var/log/edge-message-processor/system.log) görüntüleyin ve 6. adımda not edilen benzersiz ileti kimliğini arayın. Belirli API isteği için aşağıdaki hata mesajı gözlemlendi:

   2017-05-05 07:48:18,653 org:myorg env:prod api:myapi rev:834 messageid:rrt-04984fed9e5ad3551-c-wo-32168-77563  NIOThread@5 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@149081 useCount=1 bytesRead=0 bytesWritten=0 age=3002ms lastIO=3002ms .onConnectTimeout connectAddress=mybackend.domain.com/XX.XX.XX.XX:443 resolvedAddress=mybackend.domain.com/XX.XX.XX.XX

   Yukarıdaki hata, arka uç sunucusuna bağlanırken bağlantı zaman aşımı hatası nedeniyle hizmet çağrısı politikasının başarısız olduğunu gösterir.

8. Bağlantı zaman aşımı hatasının nedenini belirlemek için Mesaj İşleyici'den arka uç sunucusuna telnet komutunu çalıştırın. Telnet komutu, aşağıda gösterildiği gibi "Bağlantı zaman aşımına uğradı" hatası verdi:

   telnet mybackend.domain.com 443
   Trying XX.XX.XX.XX...
   telnet: connect to address XX.XX.XX.XX: Connection timed out

   Bu hata genellikle aşağıdaki durumlarda görülür:

   • Arka uç sunucusu, Edge Message Processors'dan gelen trafiğe izin verecek şekilde yapılandırılmadığında.
   • Arka uç sunucusu belirli bir bağlantı noktasını dinlemiyorsa.

   Yukarıdaki örnekte, Değişkenleri Çıkar politikası başarısız olmasına rağmen asıl neden, Edge'in Hizmet Çağrısı politikasındaki arka uç sunucusuna bağlanamamasıdır. Bu hatanın nedeni, arka uç sunucusunun Edge Message Processors'dan gelen trafiğe izin verecek şekilde yapılandırılmamış olmasıydı.

   Kendi Değişkenleri Ayıkla politikanız farklı şekilde davranır ve farklı bir nedenle başarısız olabilir. Hata mülkündeki mesajı kontrol ederek Değişkenleri Çıkar politikanızın başarısız olma nedenine bağlı olarak sorunu uygun şekilde giderebilirsiniz.

2. örnek çözümü

1. Değişkenleri Ayıkla politikasındaki hata veya başarısızlık nedenini uygun şekilde düzeltin.
2. Yukarıdaki örnekte, çözüm olarak ağ yapılandırması düzeltilerek Edge Message Processors'dan gelen trafiğin arka uç sunucunuza ulaşması sağlandı. Bu işlem, Mesaj İşleyicilerin IP adreslerinin belirli arka uç sunucusunda izin verilenler listesine eklenmesiyle yapıldı. Örneğin, Linux'ta arka uç sunucusunda İleti İşleyici'nin IP adreslerinden gelen trafiğe izin vermek için iptables'ı kullanabilirsiniz.

3. örnek: JavaCallout politikasında hata

Şimdi de Java Callout politikasındaki bir hata nedeniyle 500 Dahili Sunucu Hatası'nın oluştuğu bir örneğe daha bakalım ve sorunu nasıl gidereceğimizi ve çözeceğimizi görelim.

1. Aşağıdaki kullanıcı arayüzü izinde, Java Callout Policy'deki bir hata nedeniyle 500 durum kodu gösterilmektedir:

   

2. Aşağıdaki şekilde gösterildiği gibi hata ayrıntılarını almak için "Error" adlı akışı ve ardından başarısız olan Java Callout Policy'yi seçin:

   

3. Bu örnekte, Özellikler bölümündeki "error" özelliği, hatanın JavaCallout politikası içinden Oracle veritabanına bağlanırken süresi dolmuş şifrenin kullanılmasından kaynaklandığını gösteriyor. Kendi Java çağrınız farklı şekilde davranır ve hata özelliğine farklı bir mesaj yerleştirir.
4. JavaCallout politika kodunu kontrol edin ve kullanılması gereken doğru yapılandırmayı onaylayın.

3. Örnek Çözümü

Çalışma zamanı istisnasını önlemek için Java çağrı kodu veya yapılandırmasını uygun şekilde düzeltin. Yukarıdaki Java açıklama metni hatası örneğinde, sorunu çözmek için Oracle veritabanına bağlanırken doğru şifrenin kullanılması gerekir.

Arka uç sunucusunda hata

500 dahili sunucu hatası, arka uç sunucusundan da kaynaklanabilir. Bu bölümde, hata arka uç sunucusundan kaynaklanıyorsa sorunun nasıl giderileceği açıklanmaktadır.

Teşhis

Tüm kullanıcılar için teşhis adımları

Diğer arka uç hatalarının nedeni büyük ölçüde değişebilir. Her durumu ayrı ayrı teşhis etmeniz gerekir.

1. Hatanın arka uç sunucusundan kaynaklandığını doğrulayın. Ayrıntılar için Sorunun kaynağını belirleme bölümüne bakın.
2. Hata arka uç sunucusundan kaynaklanıyorsa devam edin. Hata politika yürütme sırasında oluştuysa Execution Error in Edge Policy (Edge politikasında yürütme hatası) başlıklı makaleye gidin.
3. Başarısız API için bir İzleme oturumuna erişiminizin olup olmadığına veya arka ucun bir Node.js sunucusu olup olmadığına bağlı olarak aşağıdaki adımları uygulayın:

Başarısız API çağrısı için izleme oturumunuz yoksa:

1. Başarısız olan istek için kullanıcı arayüzü izi kullanılamıyorsa hatayla ilgili ayrıntıları almak için arka uç sunucu günlüklerini kontrol edin.
2. Mümkünse hatayla ve nedeni hakkında daha fazla bilgi edinmek için arka uç sunucusunda hata ayıklama modunu etkinleştirin.

Başarısız API çağrısı için bir İzleme oturumunuz varsa:

İzleme oturumunuz varsa aşağıdaki adımlar sorunu teşhis etmenize yardımcı olur.

1. İzleme aracında, 500 Dahili Sunucu Hatası ile başarısız olan API isteğini seçin.
2. Başarısız olan API isteğinden "Hedef sunucudan yanıt alındı" aşamasını seçin (aşağıdaki şekilde gösterildiği gibi):

   

3. Hata hakkında ayrıntılı bilgi edinmek için "Yanıt İçeriği" bölümünü inceleyin.

   

4. Bu örnekte, SOAP zarfı olan yanıt içeriğinde hata dizesi "Yetkili Değil" mesajı olarak gösterilmektedir. Bu sorunun en olası nedeni, kullanıcının uygun kimlik bilgilerini (kullanıcı adı/şifre, erişim jetonu vb.) arka uç sunucusuna iletmemesidir. Bu sorun, arka uç sunucusuna doğru kimlik bilgilerini ileterek düzeltilebilir.

Arka uç bir Node.js sunucusuyse:

1. Arka uç Node.js arka uç sunucusu ise Edge kullanıcı arayüzünde belirli API proxy'si için Node.js günlüklerini kontrol edin (hem herkese açık hem de özel bulut kullanıcıları Node.js günlüklerini kontrol edebilir). Edge Private Cloud kullanıcısıysanız hatayla ilgili daha fazla ayrıntı için Mesaj İşleyici günlüklerinizi (/opt/apigee/var/log/edge-message-processor/logs/system.log) de kontrol edebilirsiniz.
   
   

   Edge kullanıcı arayüzündeki NodeJS günlükleri seçeneği - API proxy'sinin Genel Bakış sekmesi

   

Çözüm

1. Hataya neden olan durumu belirledikten sonra arka uç sunucunuzdaki sorunu düzeltin.
2. Node.js arka uç sunucusuysa:
   1. Hatayı özel kodunuzun verip vermediğini kontrol edin ve mümkünse sorunu düzeltin.
   2. Hata özel kodunuzdan kaynaklanmıyorsa veya yardıma ihtiyacınız varsa Apigee Destek Ekibi ile iletişime geçin.

500 Dahili Sunucu Hatası'nı giderme konusunda daha fazla yardıma ihtiyacınız varsa veya bunun Edge'de bir sorun olduğunu düşünüyorsanız Apigee Destek Ekibi ile iletişime geçin.

Sorunun kaynağını belirleme

API proxy'sindeki bir politikanın yürütülmesi sırasında veya arka uç sunucusu tarafından 500 Dahili Sunucu Hatası'nın verilip verilmediğini belirlemek için aşağıdaki prosedürlerden birini kullanın.

Kullanıcı arayüzünde Trace'i kullanma

Not: Bu bölümdeki adımlar hem genel hem de özel bulut kullanıcıları tarafından gerçekleştirilebilir.

1. Sorun devam ediyorsa etkilenen API için kullanıcı arayüzünde izlemeyi etkinleştirin.
2. İzlemeyi yakaladıktan sonra yanıt kodunu 500 olarak gösteren API isteğini seçin.
3. Başarısız olan API isteğinin tüm aşamalarında ilerleyin ve hangi aşamada 500 Dahili Sunucu Hatası döndürüldüğünü kontrol edin:
   1. Hata, bir politikanın yürütülmesi sırasında oluşursa Edge politikasında yürütme hatası bölümüne gidin.
   2. Arka uç sunucusu 500 Dahili Sunucu Hatası ile yanıt verdiyse Arka Uç Sunucusunda Hata bölümüne gidin.

API İzleme'yi kullanma

Not: Bu bölümdeki adımlar yalnızca genel bulut kullanıcıları tarafından gerçekleştirilebilir.

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 durum kodlarının veya steps.servicecallout.ExecutionFailed hatalarının sayısı belirli bir eşiği aştığında bildirim almak için uyarı ayarlayabilirsiniz.

NGINX Erişim Günlüklerini Kullanma

Not: Bu bölümdeki adımlar yalnızca Edge Private Cloud kullanıcıları içindir.

Ayrıca, API proxy'sindeki bir politikanın yürütülmesi sırasında veya arka uç sunucusu tarafından 500 durum kodunun verilip verilmediğini belirlemek için NGINX erişim günlüklerine de başvurabilirsiniz. Bu, özellikle sorun geçmişte yaşandıysa veya aralıklı olarak yaşanıyorsa ve kullanıcı arayüzünde izlemeyi yakalayamıyorsanız yararlıdır. NGINX erişim günlüklerinden bu bilgileri belirlemek için aşağıdaki adımları uygulayın:

1. NGINX erişim günlüklerini (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log ) kontrol edin.
2. Belirli bir API proxy'sinde belirli bir süre boyunca 500 hatası olup olmadığını arayın.
3. 500 hatası varsa hatanın politika veya hedef sunucu hatası olup olmadığını aşağıdaki gibi kontrol edin:

   Politika hatası gösteren örnek giriş

   

   Hedef sunucu hatası gösteren örnek giriş

   

4. Politika hatası mı yoksa hedef sunucu hatası mı olduğunu belirledikten sonra:
   1. Politika hatasıysa Edge politikasında yürütme hatası bölümüne gidin.
   2. Hedef sunucu hatasıysa Arka Uç Sunucusunda Hata bölümüne gidin.