Azure depolama hesaplarındaki istemci uygulaması hatalarını giderme

Bu makale Azure İzleyici'de ölçümleri, istemci tarafı günlüklerini ve kaynak günlüklerini kullanarak istemci uygulaması hatalarını araştırmanıza yardımcı olur.

Hataları tanılama

Uygulamanızın kullanıcıları, istemci uygulama tarafından bildirilen hataları size bildirebilir. Azure İzleyici ayrıca NetworkError, ClientTimeoutError veya AuthorizationError gibi depolama hizmetlerinizden farklı yanıt türlerinin (ResponseType boyutları) sayısını kaydeder. Azure İzleyici yalnızca farklı hata türlerinin sayısını kaydederken sunucu tarafı, istemci tarafı ve ağ günlüklerini inceleyerek tek tek istekler hakkında daha fazla ayrıntı edinebilirsiniz. Genellikle, depolama hizmeti tarafından döndürülen HTTP durum kodu isteğin neden başarısız olduğunu gösterir.

Aşağıdaki kaynaklar depolamayla ilgili durumu ve hata kodlarını anlamak için yararlıdır:

• Yaygın REST API hata kodları
• Blob Hizmeti hata kodları
• Kuyruk Hizmeti hata kodları
• Tablo Hizmeti hata kodları
• Dosya Hizmeti hata kodları

İstemci HTTP 403 (Yasak) iletileri alıyor

İstemci uygulamanız HTTP 403 (Yasak) hataları veriyorsa, bunun olası bir nedeni istemcinin depolama isteği gönderirken süresi dolan bir Paylaşılan Erişim İmzası (SAS) kullanıyor olmasıdır (diğer olası nedenler arasında saat dengesizliği, geçersiz anahtarlar ve boş üst bilgiler olsa da).

.NET için Depolama İstemci Kitaplığı, uygulamanız tarafından gerçekleştirilen depolama işlemleriyle ilgili istemci tarafı günlük verilerini toplamanızı sağlar. Daha fazla bilgi için bkz. .NET Depolama İstemci Kitaplığı ile İstemci Tarafı Günlüğü.

Aşağıdaki tabloda, Depolama İstemci Kitaplığı tarafından oluşturulan istemci tarafı günlüğünden bu sorunun oluştuğunu gösteren bir örnek gösterilmektedir:

Bu senaryoda, istemci belirteci sunucuya göndermeden önce SAS belirtecinin süresinin neden dolmakta olduğunu araştırmanız gerekir:

• Genellikle, istemcinin hemen kullanacağı bir SAS oluştururken başlangıç zamanı ayarlamamalısınız. Geçerli saati kullanarak SAS oluşturan konak ile depolama hizmeti arasında küçük saat farkları varsa, depolama hizmetinin henüz geçerli olmayan bir SAS alması mümkündür.

• SAS üzerinde çok kısa bir süre sonu süresi ayarlama. Yine SAS'yi oluşturan konak ile depolama hizmeti arasındaki küçük saat farkları sas süresinin beklenenden erken dolmasına neden olabilir.

• SAS anahtarındaki sürüm parametresi (örneğin, sv=2015-04-05) kullandığınız Depolama İstemci Kitaplığı sürümüyle eşleşmiyor mu? Her zaman depolama istemci kitaplığının en son sürümünü kullanmanızı öneririz.

• Depolama erişim anahtarlarınızı yeniden oluşturursanız, mevcut SAS belirteçleri geçersiz kılınabilir. İstemci uygulamalarının önbelleğe almaları için uzun bir süre sonu süresine sahip SAS belirteçleri oluşturursanız bu sorun ortaya çıkabilir.

SAS belirteçleri oluşturmak için Depolama İstemci Kitaplığı'nı kullanıyorsanız, geçerli bir belirteç oluşturmak kolaydır. Ancak Depolama REST API'sini kullanıyorsanız ve SAS belirteçlerini el ile oluşturursanız bkz. Paylaşılan Erişim İmzası ile Erişim Yetkisi Alma.

İstemci HTTP 404 (Bulunamadı) iletileri alıyor

İstemci uygulaması sunucudan bir HTTP 404 (Bulunamadı) iletisi alırsa bu, istemcinin kullanmaya çalıştığı nesnenin (varlık, tablo, blob, kapsayıcı veya kuyruk gibi) depolama hizmetinde mevcut olmadığını gösterir. Bunun birkaç olası nedeni vardır, örneğin:

• İstemci veya başka bir işlem daha önce nesneyi silmiş.

• Paylaşılan Erişim İmzası (SAS) yetkilendirme sorunu.

• İstemci tarafı JavaScript kodunun nesneye erişme izni yoktur.

• Ağ hatası.

İstemci veya başka bir işlem daha önce nesneyi sildi

İstemcinin bir depolama hizmetindeki verileri okumaya, güncelleştirmeye veya silmeye çalıştığı senaryolarda, depolama kaynağı günlüklerinde söz konusu nesneyi depolama hizmetinden silmiş önceki bir işlemi kolayca belirleyebilirsiniz. Günlük verileri genellikle başka bir kullanıcının veya işlemin nesneyi sildiğini gösterir. Azure İzleyici günlükleri (sunucu tarafı), istemcinin bir nesneyi ne zaman sildiği gösterir.

İstemcinin nesne eklemeye çalıştığı senaryoda, istemcinin yeni bir nesne oluşturduğu göz önünde bulundurulduğunda bunun neden http 404 (bulunamadı) yanıtıyla sonuçlandığı hemen açık olmayabilir. Ancak istemci bir blob oluşturuyorsa blob kapsayıcısını bulabilmesi gerekir. İstemci bir ileti oluşturuyorsa bir kuyruk bulabilmesi gerekir. İstemci bir satır ekliyorsa tabloyu bulabilmesi gerekir.

İstemcinin depolama hizmetine belirli istekleri ne zaman gönderdiğini daha iyi anlamak için Depolama İstemci Kitaplığı'ndan istemci tarafı günlüğünü kullanabilirsiniz.

Depolama İstemcisi kitaplığı tarafından oluşturulan aşağıdaki istemci tarafı günlüğü, istemcinin oluşturduğu blob için kapsayıcıyı bulamama sorununu gösterir. Bu günlük aşağıdaki depolama işlemlerinin ayrıntılarını içerir:

Günlük girdileri:

Bu örnekte günlük, istemcinin yöntemden gelen CreateIfNotExists istekleri (istek kimliği e2d06d78...) yönteminden gelen UploadFromStream isteklerle (de8b1c3c-...) birleştirdiğini gösterir. Bu araya ekleme, istemci uygulamasının bu yöntemleri zaman uyumsuz olarak çağırması nedeniyle gerçekleşir. Herhangi bir veriyi bu kapsayıcıdaki bir bloba yüklemeyi denemeden önce kapsayıcıyı oluşturduğundan emin olmak için istemcideki zaman uyumsuz kodu değiştirin. İdeal olarak, tüm kapsayıcılarınızı önceden oluşturmanız gerekir.

Paylaşılan Erişim İmzası (SAS) yetkilendirme sorunu

İstemci uygulaması işlem için gerekli izinleri içermeyen bir SAS anahtarı kullanmayı denerse, depolama hizmeti istemciye bir HTTP 404 (Bulunamadı) iletisi döndürür. Aynı zamanda Azure İzleyici ölçümlerinde, ResponseType boyutu için bir AuthorizationError da görürsünüz.

İstemci uygulamanızın kendisine izin verilmemiş bir işlemi neden gerçekleştirmeye çalıştığına bakın.

İstemci tarafı JavaScript kodunun nesneye erişme izni yok

JavaScript istemcisi kullanıyorsanız ve depolama hizmeti HTTP 404 iletileri döndüriyorsa, tarayıcıda aşağıdaki JavaScript hatalarını denetleyin:

SEC7120: Kaynak http://localhost:56309 Access-Control-Allow-Origin üst bilgisinde bulunamadı.
SCRIPT7002: XMLHttpRequest: Ağ Hatası 0x80070005, Erişim reddedildi.

Bu hatalar, web tarayıcısının bir web sayfasının sayfanın geldiği etki alanından farklı bir etki alanındaki API'yi çağırmasını engelleyen kaynak ilkesi güvenlik kısıtlamasını uyguladığından oluşur.

JavaScript sorununu geçici olarak çözmek için istemcinin eriştiği depolama hizmeti için Çıkış Noktaları Arası Kaynak Paylaşımı'nı (CORS) yapılandırabilirsiniz. Daha fazla bilgi için bkz. Azure Depolama Hizmetleri için Çıkış Noktaları Arası Kaynak Paylaşımı (CORS) Desteği.

Aşağıdaki kod örneği, blob hizmetinizi Contoso etki alanında çalışan JavaScript'in blob depolama hizmetinizdeki bir bloba erişmesine izin verecek şekilde yapılandırmayı gösterir:

var connectionString = Constants.connectionString;

 BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);

 BlobServiceProperties sp = blobServiceClient.GetProperties();

 // Set the service properties.
 sp.DefaultServiceVersion = "2013-08-15";
 BlobCorsRule bcr = new BlobCorsRule();
 bcr.AllowedHeaders = "*";

 bcr.AllowedMethods = "GET,POST";
 bcr.AllowedOrigins = "http://www.contoso.com";
 bcr.ExposedHeaders = "x-ms-*";
 bcr.MaxAgeInSeconds = 5;
 sp.Cors.Clear();
 sp.Cors.Add(bcr);
 blobServiceClient.SetProperties(sp);

Ağ hatası

Bazı durumlarda, kayıp ağ paketleri depolama hizmetinin istemciye HTTP 404 iletileri döndürmesine neden olabilir. Örneğin, istemci uygulamanız tablo hizmetinden bir varlığı silerken, istemcinin tablo hizmetinden "HTTP 404 (Bulunamadı)" durum iletisini bildiren bir depolama özel durumu oluşturdığını görürsünüz. Tablo depolama hizmetindeki tabloyu araştırdığınızda, hizmetin varlığı istenen şekilde sildiğini görürsünüz.

İstemcideki özel durum ayrıntıları, istek için tablo hizmeti tarafından atanan istek kimliğini (7e84f12d...) içerir: Günlük girdilerinde işlemin kimliğinin nasıl doğrulandığını açıklayan Alanlar'da arama yaparak Azure İzleyici'deki depolama kaynak günlüklerinde istek ayrıntılarını bulmak için bu bilgileri kullanabilirsiniz. Ayrıca bu tür hataların ne zaman ortaya çıktığını belirlemek ve ardından ölçümlerin bu hatayı kaydettiği zamana göre günlük dosyalarında arama yapmak için ölçümleri kullanabilirsiniz. Bu günlük girdisi silme işleminin "HTTP (404) İstemci diğer hatası" durum iletisiyle başarısız olduğunu gösterir. Aynı günlük girdisi, istemci tarafından sütunda client-request-id (813ea74f...) oluşturulan istek kimliğini de içerir.

Sunucu tarafı günlüğü, aynı varlık için ve aynı istemciden başarılı bir silme işlemi için aynı client-request-id değere (813ea74f...) sahip başka bir giriş de içerir. Bu başarılı silme işlemi başarısız silme isteğinden kısa süre önce gerçekleşti.

Bu senaryonun en olası nedeni, istemcinin varlık için tablo hizmetine bir silme isteği göndermesi ve bu isteğin başarılı olması ancak sunucudan onay almamış olmasıdır (belki de geçici bir ağ sorunundan dolayı). ardından istemci işlemi otomatik olarak yeniden denendi (aynı client-request-idkullanılarak) ve varlık zaten silinmiş olduğundan bu yeniden deneme başarısız oldu.

Bu sorun sık sık oluşuyorsa, istemcinin neden tablo hizmetinden onay almada başarısız olduğunu araştırmanız gerekir. Sorun aralıklı olarak oluşuyorsa, "HTTP (404) Bulunamadı" hatasını yakalamalı ve istemcide günlüğe kaydetmeli, ancak istemcinin devam etmesine izin vermelisiniz.

İstemci HTTP 409 (Çakışma) iletileri alıyor

İstemci blob kapsayıcılarını, tablolarını veya kuyruklarını sildiğinde, adın yeniden kullanılabilir duruma gelmesi için kısa bir süre vardır. İstemci uygulamanızdaki kod silinir ve aynı adı kullanarak bir blob kapsayıcısını hemen yeniden oluşturursa, CreateIfNotExists yöntem sonunda HTTP 409 (Çakışma) hatasıyla başarısız olur.

Silme/yeniden oluşturma deseni yaygınsa istemci uygulaması yeni kapsayıcılar oluşturduğunda benzersiz kapsayıcı adları kullanmalıdır.

Ölçümler düşük PercentSuccess veya analiz günlüğü girişlerinin ClientOtherErrors işlem durumuna sahip işlemleri olduğunu gösterir

Başarı değerine eşit bir ResponseType boyutu, HTTP Durum Koduna göre başarılı olan işlemlerin yüzdesini yakalar. Durum kodları 2XX olan işlemler başarılı sayılırken, 3XX, 4XX ve 5XX aralıklarında durum kodları olan işlemler başarısız olarak sayılır ve Başarı ölçüm değerini düşürür. Depolama kaynak günlüklerinde bu işlemler ClientOtherError işlem durumuyla kaydedilir.

Bu işlemler başarıyla tamamlandı ve bu nedenle kullanılabilirlik gibi diğer ölçümleri etkilemez. Başarıyla yürütülen ancak başarısız HTTP durum kodlarıyla sonuçlanabilir işlemlere örnek olarak şunlar verilebilir:

• ResourceNotFound (Bulunamadı 404), örneğin, get isteğinden var olmayan bir bloba.
• Örneğin kaynağın zaten var olduğu bir CreateIfNotExist işlemden ResourceAlreadyExists (Çakışma 409).
• ConditionNotMet (Değiştirilmedi 304), örneğin, bir istemcinin bir değer gönderdiğinde olduğu gibi koşullu bir ETag işlemden ve bir HTTP If-None-Match üst bilgisinden yalnızca son işlemden bu yana güncelleştirilmişse bir görüntü istemek için.

Depolama hizmetlerinin döndüreceği yaygın REST API hata kodlarının listesini Ortak REST API Hata Kodları sayfasında bulabilirsiniz.

Ayrıca bkz.

• İzleme Azure Blob Depolama
• İzleme Azure Dosyalar
• Azure Kuyruk Depolama'yı izleme
• Azure Tablo depolamayı izleme
• Performans sorunlarını giderin
• Kullanılabilirlik sorunlarını giderme
• Azure Depolama'nızı izleme, tanılama ve sorun giderme

Yardım için bize ulaşın

Sorularınız veya yardıma ihtiyacınız varsa bir destek isteği oluşturun veya Azure topluluk desteği isteyin. Ürün geri bildirimini Azure geri bildirim topluluğuna da gönderebilirsiniz.