500 Dahili Sunucu Hatası

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

Videolar

500 Dahili Sunucu Hatasının çözümü hakkında daha fazla bilgi edinmek için aşağıdaki videoları izleyin.

Video Açıklama
Giriş 500 Dahili Sunucu Hatası ve olası nedenleri hakkında giriş niteliğinde bir tanıtım sunar. Ayrıca, hatayı giderme ve düzeltme adımlarıyla birlikte gerçek zamanlı bir 500 Dahili Sunucu hatası gösterir.
Hizmet Çağrısı ve Değişken Ayıklama hatalarını işleme Hizmet Çağrısı ve Değişken Ayıklama politikalarının neden olduğu iki adet 500 Dahili Sunucu Hatası gösterir ve bu hataların nasıl giderilip giderileceğini gösterir.
JavaScript politikası hatalarını işleme Bir JavaScript politikasının neden olduğu 500 Dahili Sunucu Hatası ile bu hatayı giderme ve çözümleme adımlarını gösterir.
Arka uç sunuculardan gelen hataları işleme Arka uç sunucusundaki bir hatadan kaynaklanan 500 Dahili Sunucu Hatası örneğini ve hataları düzeltme adımlarını gösterir.

Belirti

İstemci uygulaması, API çağrılarına yanıt olarak "Dahili Sunucu Hatası" mesajıyla birlikte 500 HTTP durum kodunu alır. 500 Dahili Sunucu hatası, Edge'de herhangi bir politikanın yürütülmesi sırasında oluşan bir hata 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 beklenmeyen 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 fazla ayrıntı 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ı, birçok farklı nedenden ötürü ortaya çıkabilir. Edge'de nedenler, hatanın ortaya çıktığı yere göre iki ana kategoriye ayrılabilir:

Neden Ayrıntılar Aşağıdakiler İçin Ayrıntılı Sorun Giderme Adımları:
Edge Politikasında Yürütme Hatası API proxy'sindeki politika bir nedenle başarısız olabilir. Edge Özel ve Genel Bulut kullanıcıları
Arka Uç Sunucusunda Hata Arka uç sunucusu bir nedenden ötürü başarısız olabilir. Edge Özel ve Genel Bulut kullanıcıları

Edge Politikasında Yürütme Hatası

API proxy'sindeki politika bir nedenle başarısız olabilir. Bu bölümde, bir politikanın yürütülmesi sırasında 500 Dahili Sunucu Hatası oluşursa sorunun nasıl giderileceği açıklanmaktadır.

Teşhis

Özel ve Herkese Açık Bulut Kullanıcıları İçin Teşhis Adımları

Hatayla ilgili izleme kullanıcı arayüzü oturumunuz varsa:

  1. Hatanın bir politikanın yürütülmesinden kaynaklandığını doğrulayın. Ayrıntılar için Sorunun kaynağını belirleme bölümüne bakın.
  2. Politika yürütülürken hata oluştuysa devam edin. Hata arka uç sunucusundan kaynaklanıyorsa Arka Uç Sunucusu'nda Hata bölümüne gidin.
  3. İzlemede 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ı veya izlemedeki başarısız 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 hatayla ilgili daha fazla bilgi edinin.
  6. Hatayla ilgili topladığınız ayrıntıları kullanarak nedenini belirlemeye çalışın.

Yalnızca Private Cloud Kullanıcıları İçin Teşhis Adımları

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

  1. Hatanın bir politika yürütülürken oluştuğunu doğrulayın. Ayrıntılar için Sorunun kaynağını belirleme bölümüne bakın.
  2. Hata, politikanın yürütülmesinden kaynaklanıyorsa devam edin. Politika yürütülürken hata oluştuysa devam edin. Hata arka uç sunucusundan kaynaklanıyorsa Arka Uç Sunucuda 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 kontrol edin (/opt/apigee/var/log/edge-message-processor/logs/system.log) ve içindeki 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 alamadığınıza bakın.

Çö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ı sorun türlerinin nedeninin ve çözümünün nasıl belirleneceği gösterilmektedir.

500 Dahili Sunucu Hatası giderme konusunda daha fazla yardıma ihtiyacınız varsa veya bu sorunun Edge'de olduğundan şüpheleniyorsanız Apigee Destek Ekibi ile iletişime geçin.

1. Örnek: Arka uç sunucusundaki bir hata nedeniyle Hizmet Açıklama Metni politikasında hata

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

  1. Aşağıda, arka uç hizmetinin Hizmet Çağrı Politikası içinde 404 hatasıyla başarısız olduğu bir örnek verilmiştir. Son kullanıcıya aşağıdaki hata mesajı gönderildi: 
    {
"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 iz kullanıcı arayüzü oturumunda, hizmet açıklama metni politikasındaki bir hatadan kaynaklanan 500 durum kodu gösterilmektedir:

  3. Bu örnekte "error" özelliği, Hizmet Çağrı Politikası politika hatasının nedenini "ResponseCode 404 hata olarak değerlendiriliyor" olarak listeler. Bu hata, Hizmet Açıklaması politikasındaki arka uç sunucu URL'si aracılığıyla erişilen kaynak mevcut değilse ortaya çıkabilir.
  4. Arka uç sunucusunda kaynağın kullanılabilirliğini kontrol edin. Geçici/kalıcı olarak kullanılamıyor veya farklı bir konuma taşınmış olabilir.

1. Örnek Çözüm

  1. Arka uç sunucusunda kaynağın kullanılabilirliğini kontrol edin. Geçici/kalıcı olarak kullanılamıyor veya farklı bir konuma taşınmış olabilir.
  2. Hizmet Açıklama Metni politikasındaki arka uç sunucu URL'sini, geçerli ve mevcut bir kaynağa işaret edecek şekilde düzeltin.
  3. Kaynak yalnızca geçici olarak kullanılamıyorsa kaynak kullanılabilir olduğunda API isteğini göndermeyi deneyin.

2. Örnek: Değişkenleri Ayıklama Politikası'nda Hata

Şimdi de Değişken Ayıklama politikasındaki bir hatadan kaynaklanan 500 Dahili Sunucu Hatası'nın oluştuğu başka bir örneği inceleyelim ve sorunun nasıl giderilip çözüleceğini görelim.

  1. Kullanıcı arayüzü oturumunda aşağıdaki iz, Değişkenleri Ayıklama politikasındaki bir hata nedeniyle 500 durum kodu gösterir:

  2. Hatalı Değişkenleri Ayıklama 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, Değişken Ayıklama politikasında "service callout.oamCookieValidationResponse" değişkeninin kullanılamadığını belirtir. Değişkenin adının belirtildiği gibi, önceki Hizmet Çağrısı politikasının yanıtını içermesi gerekir.
  4. İzdeki Hizmet Çağrısı 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 bunun sonucunda boş bir yanıt değişkeni olduğunu gösterir.
  5. Hizmet Çağrısı politikası başarısız olmuş olsa da Hizmet Çağrısı politikasındaki "continueOnError" işareti aşağıda gösterildiği gibi doğru değerine ayarlandığından Hizmet Çağrısı politikasından sonra politikaların yürütülmesi devam eder:

    <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. İzlemedeki bu özel API isteği için "X-Apigee.Message-ID" benzersiz mesaj kimliğini aşağıdaki gibi 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 mesaj kimliğini arayın. İlgili API isteği için şu 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çıklama Metni politikasının başarısız olduğunu belirtir.

  8. Bağlantı zaman aşımı hatasının nedenini belirlemek için Mesaj İşleyicilerinden arka uç sunucusuna telnet komutunu yürütü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

    Genellikle bu hata aşağıdaki durumlarda görülür:

    • Arka uç sunucusu, Edge Mesaj İşleyicilerinden gelen trafiğe izin verecek şekilde yapılandırılmadığında.
    • Arka uç sunucusu belirli bağlantı noktasını dinlemiyorsa.

    Yukarıdaki örnekte, Değişkenleri Ayıklama politikası başarısız olsa da asıl neden, Edge'in Hizmet Açıklaması politikasında arka uç sunucusuna bağlanamamasıydı. Bu hatanın nedeni, arka uç son sunucusunun Uç Mesaj İşlemcilerinden gelen trafiğe izin verecek şekilde yapılandırılmamış olmasıydı.

    Kendi Değişkenleri Çıkar politikanız farklı davranır ve farklı bir nedenle başarısız olabilir. Değişkenleri Ayıklama politikanızın hata nedenine bağlı olarak, error özelliğindeki mesajı kontrol ederek sorunu uygun şekilde giderebilirsiniz.

2. Örnek Çözüm

  1. Değişkenleri Ayıklama politikasında hatanın veya hatanın nedenini uygun şekilde düzeltin.
  2. Yukarıdaki örnekteki çözüm, Edge Mesaj İşleyicilerinden arka uç sunucunuza giden trafiğe izin vermek için ağ yapılandırmasını düzeltmekti. Bu işlem, Mesaj İşleyenlerin IP adreslerini belirli bir arka uç sunucusunda izin verilenler listesine ekleyerek gerçekleştirildi. Örneğin, Linux'ta, arka uç sunucusundaki İleti İşleyici IP adreslerinden gelen trafiğe izin vermek için iptables kullanabilirsiniz.

3. Örnek: JavaScript politikasında hata

Şimdi, 500 Dahili Sunucu Hatasının Java Çağrı Politikası'ndaki bir hatadan kaynaklandığı bir örneği daha inceleyelim ve sorunun nasıl giderilip çözüleceğini görelim.

  1. Aşağıdaki kullanıcı arayüzü izlemesinde, Java Açıklama Politikası'ndaki 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" (Hata) adlı Akış'ı ve ardından başarısız Java Açıklama Metni Politikası'nı seçin:

  3. Bu örnekte, Özellikler bölümündeki "error" özelliği, hatanın Oracle Veritabanına bağlanırken JavaCallout politikasının içinden, süresi dolmuş şifreden kaynaklandığını ortaya koyar. Kendi Java açıklama metniniz farklı davranır ve error özelliğinde farklı bir mesaj doldurur.
  4. JavaScript politika kodunu kontrol edin ve kullanılması gereken doğru yapılandırmayı onaylayın.

3. Örnek Çözüm

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

Arka Uç Sunucusunda Hata

500 Dahili Sunucu Hatası da arka uç sunucudan kaynaklanıyor olabilir. Bu bölümde, hatanın arka uç sunucusundan gelmesi durumunda sorunun nasıl giderileceği açıklanmaktadır.

Teşhis

Tüm Kullanıcılar İçin Teşhis Adımları

Diğer arka uç hatalarının nedeni büyük ölçüde farklılık gösterebilir. 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ç sunucudan kaynaklanıyorsa devam edin. Politika yürütülürken hata oluştuysa Edge Politikası'nda Yürütme Hatası bölümüne gidin.
  3. Başarısız API için izleme oturumuna erişiminizin olup olmamasına veya arka ucun Node.js sunucusu olup olmamasına bağlı olarak aşağıdaki adımları uygulayın:

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

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

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

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

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

  3. Hatayla ilgili ayrıntıları almak için "Yanıt İçeriği" bölümünü kontrol edin.

  4. Bu örnekte, bir SOAP Zarfı olan Yanıt İçeriği, hata dizesini "Yetkilendirilmemiş" mesajı olarak göstermektedir. Bu sorunun en olası nedeni uygun kimlik bilgilerinin (kullanıcı adı/şifre, erişim jetonu vb.) kullanıcı tarafından arka uç sunucuya iletilmemesidir. Bu sorun, arka uç sunucusuna doğru kimlik bilgilerinin iletilmesi yoluyla düzeltilebilir.

Arka uç bir Node.js sunucusuysa:

  1. Arka uç bir Node.js Arka Uç Sunucusu ise Edge kullanıcı arayüzünde ilgili API Proxy'si için Node.js günlüklerini kontrol edin (hem Herkese Açık hem de Private Cloud 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 Message Processor 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. Hatanın nedenini belirledikten sonra, sorunu arka uç sunucunuzda düzeltin.
  2. Node.js arka uç sunucusuysa:
    1. Özel kodunuzdan kaynaklanan hata olup olmadığını kontrol edin ve mümkünse sorunu düzeltin.
    2. Özel kodunuz bu hatadan kaynaklanmıyorsa veya yardıma ihtiyacınız varsa Apigee Desteği ile iletişime geçin.

500 Dahili Sunucu Hatası giderme konusunda daha fazla yardıma ihtiyacınız varsa veya bu sorunun Edge'de olduğundan şüpheleniyorsanız Apigee Destek Ekibi ile iletişime geçin.

Sorunun kaynağını belirleme

Bir politikanın API proxy'sinde veya arka uç sunucusu tarafından yürütülmesi sırasında 500 Dahili Sunucu Hatası'nın atılıp atanmadığını 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 Herkese Açık hem de Private Cloud kullanıcıları tarafından uygulanabilir.

  1. Sorun hâlâ devam ediyorsa kullanıcı arayüzünde izlemeyi etkilenen API için etkinleştirin.
  2. İzi yakaladıktan sonra yanıt kodunu 500 olarak gösteren API isteğini seçin.
  3. Başarısız API isteğinin tüm aşamalarının üzerinden geçin ve hangi aşamanın 500 Dahili Sunucu Hatası döndürdüğünü kontrol edin:
    1. Bir politika yürütülürken hata verilirse Edge Politikasında Yürütme Hatası bölümüne gidin.
    2. Arka uç sunucusu 500 Dahili Sunucu ile yanıt verdiyse Arka Uç Sunucuda Hata bölümüne gidin.

API Monitoring'i kullanma

Not: Bu bölümdeki adımlar yalnızca Herkese Açık Bulut kullanıcıları tarafından uygulanabilir.

API Monitoring; 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 izole etmenize olanak tanır.

API Monitoring'i kullanarak API'lerinizle ilgili 5xx sorunlarını nasıl gidereceğinizi gösteren örnek bir senaryoyu inceleyin. Örneğin, 500 durum kodu veya steps.servicecallout.ExecutionFailed hatası belirli bir eşiği aştığında bilgilendirilmek için bir uyarı ayarlamak isteyebilirsiniz.

NGINX Erişim Günlüklerini Kullanma

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

500 durum kodunun API proxy'si içinde bir politika yürütülürken mi yoksa arka uç sunucusu tarafından mı atıldığını belirlemek için NGINX Access günlüklerine de bakabilirsiniz. Bu, özellikle sorun geçmişte oluşmuşsa veya ara sıra ortaya çıkıyorsa ve kullanıcı arayüzünde izleri yakalayamıyorsanız faydalıdır. Bu bilgileri NGINX erişim günlüklerinden belirlemek için aşağıdaki adımları uygulayın:

  1. NGINX erişim günlüklerini kontrol edin (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log).
  2. Belirli bir süre içinde belirli bir API proxy'si için 500 Hata olup olmadığını arayın.
  3. 500 Hata varsa aşağıda gösterildiği gibi hatanın bir politika mı yoksa hedef sunucu hatası mı olduğunu kontrol edin:

    Politika hatası gösteren örnek giriş

    Hedef Sunucu Hatası gösteren Örnek Giriş

  4. Sorunun bir politika 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 ile devam edin.