Aracılığıyla paylaş

Microsoft Azure Depolama izleme, tanılama ve sorun giderme (klasik)

  • Makale

Bu kılavuzda Azure depolamayla ilgili sorunları tanımlamak, tanılamak ve gidermek için Azure Depolama Analizi, Azure Depolama İstemci Kitaplığı'nda istemci tarafı günlük kaydı ve diğer üçüncü taraf araçları gibi özelliklerin nasıl kullanılacağı gösterilmektedir.

İstemci uygulamaları ile Azure depolama hizmetleri arasındaki bilgi akışını gösteren diyagram.

Bu kılavuzun öncelikli olarak bu tür çevrimiçi hizmetler yönetiminden sorumlu Azure Depolama Hizmetleri ve BT Uzmanlarını kullanan çevrimiçi hizmetler geliştiricileri tarafından okunması amaçlanmıştır. Bu kılavuzun hedefleri şunlardır:

  • Azure Depolama hesaplarınızın sistem durumunu ve performansını korumanıza yardımcı olmak için.
  • Bir uygulamadaki bir sorunun veya sorunun Azure Depolama ile ilgili olup olmadığına karar vermenize yardımcı olacak gerekli işlemleri ve araçları sağlamak için.
  • Azure Depolama ile ilgili sorunları çözmek için size eyleme dönüştürülebilir yönergeler sağlamak için.

Not

Bu makale, Klasik ölçümler ve günlükler olarak adlandırılan Depolama Analizi ölçümleri ve günlükleri kullanmayı temel alır. Depolama Analizi günlükleri yerine Azure depolama ölçümlerini ve günlüklerini Azure İzleyici'de kullanmanızı öneririz. Daha fazla bilgi edinmek için aşağıdaki makalelerden herhangi birine bakın:

Genel Bakış

Bulut ortamında barındırılan dağıtılmış bir uygulamada sorunları tanılama ve giderme, geleneksel ortamlardan daha karmaşık olabilir. Uygulamalar bir PaaS veya IaaS altyapısında, şirket içinde, mobil cihazda veya bu ortamların bir birleşiminde dağıtılabilir. Genellikle, uygulamanızın ağ trafiği genel ve özel ağlardan geçiş yapabilir ve uygulamanız ilişkisel ve belge veritabanları gibi diğer veri depolarına ek olarak Microsoft Azure Depolama Tablolar, Bloblar, Kuyruklar veya Dosyalar gibi birden çok depolama teknolojisi kullanabilir.

Bu tür uygulamaları başarıyla yönetmek için, bunları proaktif olarak izlemeli ve bunların ve bağımlı teknolojilerinin tüm yönlerini tanılamayı ve sorunlarını gidermeyi anlamanız gerekir. Azure Depolama hizmetlerinin kullanıcısı olarak, uygulamanızın davranıştaki beklenmeyen değişiklikler için (normalden daha yavaş yanıt süreleri gibi) kullandığı Depolama hizmetlerini sürekli izlemeli ve daha ayrıntılı veri toplamak ve bir sorunu derinlemesine analiz etmek için günlüğe kaydetmeyi kullanmalısınız. İzleme ve günlük kaydından aldığınız tanılama bilgileri, uygulamanızın karşılaştığı sorunun kök nedenini belirlemenize yardımcı olur. Ardından sorunu giderebilir ve düzeltmek için uygun adımları belirleyebilirsiniz. Azure Depolama temel bir Azure hizmetidir ve müşterilerin Azure altyapısına dağıttığı çözümlerin çoğunun önemli bir bölümünü oluşturur. Azure Depolama, bulut tabanlı uygulamalarınızdaki depolama sorunlarını izlemeyi, tanılamayı ve gidermeyi basitleştirmeye yönelik özellikler içerir.

Bu kılavuz nasıl düzenlenir?

Depolama hizmetinizi izleme bölümünde, Azure Depolama Analizi Ölçümlerini (Depolama Ölçümleri) kullanarak Azure Depolama hizmetlerinizin sistem durumunu ve performansını nasıl izleyeceğiniz açıklanır.

Depolama sorunlarını tanılama bölümü, Azure Depolama Analizi Günlüğü (Depolama Günlüğü) kullanarak sorunları tanılamayı açıklar. Ayrıca, .NET için Depolama İstemci Kitaplığı veya Java için Azure SDK gibi istemci kitaplıklarından birinde yer alan özellikleri kullanarak istemci tarafı günlüğe kaydetmenin nasıl etkinleştirileceği açıklanır.

Uçtan uca izleme bölümünde, çeşitli günlük dosyalarında ve ölçüm verilerinde yer alan bilgileri nasıl ilişkilendirebileceğiniz açıklanır.

Sorun giderme kılavuzu bölümü, karşılaşabileceğiniz depolamayla ilgili yaygın sorunlardan bazıları için sorun giderme kılavuzu sağlar.

Ekler bölümü, ağ paketi verilerini çözümlemek için Wireshark ve Netmon gibi diğer araçları ve HTTP/HTTPS iletilerini çözümlemek için Fiddler'ı kullanma hakkında bilgi içerir.

Depolama hizmetinizi izleme

Windows performans izleme hakkında bilgi sahibiyseniz Depolama Ölçümlerini Windows Performans İzleyicisi sayaçlarının Azure Depolama eşdeğeri olarak düşünebilirsiniz. Depolama Ölçümleri'nde hizmet kullanılabilirliği, hizmete yönelik toplam istek sayısı veya başarılı hizmet isteklerinin yüzdesi gibi kapsamlı bir ölçüm kümesi (Windows Performans İzleyicisi terminolojisindeki sayaçlar) bulacaksınız. Kullanılabilir ölçümlerin tam listesi için bkz. ölçüm tablosu şeması Depolama Analizi. Depolama hizmetinin ölçümleri saatte veya dakikada bir toplamasını isteyip istemediğinizi belirtebilirsiniz. Ölçümleri etkinleştirme ve depolama hesaplarınızı izleme hakkında daha fazla bilgi için bkz . Depolama ölçümlerini etkinleştirme ve ölçüm verilerini görüntüleme.

Azure portal hangi saatlik ölçümleri görüntülemek istediğinizi seçebilir ve saatlik ölçüm belirli bir eşiği aştığında yöneticileri e-postayla bilgilendiren kurallar yapılandırabilirsiniz. Daha fazla bilgi için bkz. Uyarı Bildirimleri Alma.

Depolama için Azure İzleyici'yi (önizleme) incelemenizi öneririz. Azure Depolama hizmetlerinizin performansı, kapasitesi ve kullanılabilirliğiyle ilgili birleşik bir görünüm sunarak Azure Depolama hesaplarınızın kapsamlı bir şekilde izlenmesini sağlayan bir Azure İzleyici özelliğidir. Herhangi bir şeyi etkinleştirmenizi veya yapılandırmanızı gerektirmez ve bu ölçümleri önceden tanımlanmış etkileşimli grafiklerden ve dahil edilen diğer görselleştirmelerden hemen görüntüleyebilirsiniz.

Depolama hizmeti ölçümleri toplamak için elinden gelenin en iyisini yapmaya çalışır ancak her depolama işlemini kaydetmeyebilir.

Azure portal kullanılabilirlik, toplam istek sayısı ve depolama hesabı için ortalama gecikme süresi numaraları gibi ölçümleri görüntüleyebilirsiniz. Kullanılabilirlik belirli bir düzeyin altına düşerse yöneticiyi uyarmak için bir bildirim kuralı da ayarlanmıştır. Bu verileri görüntülerken, araştırma için olası alanlardan biri tablo hizmeti başarı yüzdesinin %100'ün altında olmasıdır (daha fazla bilgi için Ölçümler düşük PercentSuccess değerini gösterir veya analiz günlüğü girdilerinin ClientOtherErrors bölümünün işlem durumuyla işlemleri vardır ) bölümüne bakın.

Azure uygulamalarınızı sürekli izleyerek bunların iyi durumda olduğundan ve beklendiği gibi çalıştığından emin olmanız gerekir:

  • Uygulama için geçerli verileri karşılaştırmanıza ve Azure depolama ile uygulamanızın davranışındaki önemli değişiklikleri belirlemenize olanak tanıyan bazı temel ölçümler oluşturma. Temel ölçümlerinizin değerleri çoğu durumda uygulamaya özgü olur ve uygulamanızın performans testini yaparken bunları oluşturmanız gerekir.
  • Dakika ölçümlerini kaydetme ve hata sayılarındaki ani artışlar veya istek hızları gibi beklenmeyen hataları ve anomalileri etkin bir şekilde izlemek için bunları kullanma.
  • Saatlik ölçümleri kaydetme ve ortalama hata sayısı ve istek oranları gibi ortalama değerleri izlemek için bunları kullanma.
  • Depolama sorunlarını tanılama bölümünde daha sonra açıklandığı gibi tanılama araçlarını kullanarak olası sorunları araştırma.

Aşağıdaki görüntüdeki grafikler saatlik ölçümler için gerçekleşen ortalamanın etkinlikteki ani artışları nasıl gizleyebileceğini göstermektedir. Saatlik ölçümler sabit bir istek oranı gösterirken, dakikadaki ölçümler gerçekten gerçekleşen dalgalanmaları gösterir.

Saatlik ölçümler için gerçekleşen ortalamanın etkinlikteki ani artışları nasıl gizleyebileceğini gösteren grafikler.

Bu bölümün geri kalanında izlemeniz gereken ölçümler ve bunun nedeni açıklanmaktadır.

Hizmet durumunu izleme

Azure portal kullanarak dünyanın dört bir yanındaki tüm Azure bölgelerinde depolama hizmetinin (ve diğer Azure hizmetlerinin) durumunu görüntüleyebilirsiniz. İzleme, denetiminizin dışındaki bir sorunun uygulamanız için kullandığınız bölgedeki Depolama hizmetini etkileyip etkilemediğini hemen görmenizi sağlar.

Azure portal, çeşitli Azure hizmetlerini etkileyen olaylarla ilgili bildirimler de sağlayabilir.

Not

Bu bilgiler daha önce Azure Hizmet Panosu'nda geçmiş verilerle birlikte kullanılabilirdi. Azure DevOps için Application Insights hakkında daha fazla bilgi için bkz. Ek 5: Azure DevOps için Application Insights ile izleme.

İzleme kapasitesi

Depolama Ölçümleri yalnızca blob hizmeti için kapasite ölçümlerini depolar çünkü bloblar genellikle depolanan verilerin en büyük oranını oluşturur (yazma sırasında, tablolarınızın ve kuyruklarınızın kapasitesini izlemek için Depolama Ölçümlerini kullanmak mümkün değildir). Blob hizmeti için izlemeyi etkinleştirdiyseniz bu verileri $MetricsCapacityBlob tabloda bulabilirsiniz. Depolama Ölçümleri bu verileri günde bir kez kaydeder ve satırının RowKey kullanıcı verileriyle (değer) veya analiz verileriyle (değerdataanalytics) ilgili bir varlık içerip içermediğini belirlemek için değerini kullanabilirsiniz. Depolanan her varlık, kullanılan depolama miktarı (Capacity bayt cinsinden ölçülür) ve depolama hesabında kullanılan geçerli kapsayıcı (ContainerCount) ve blob sayısı (ObjectCount) hakkında bilgi içerir. Tabloda depolanan $MetricsCapacityBlob kapasite ölçümleri hakkında daha fazla bilgi için bkz. ölçüm tablosu şemasını Depolama Analizi.

Not

Depolama hesabınızın kapasite sınırlarına yaklaştığınızı belirten erken bir uyarı için bu değerleri izlemeniz gerekir. Azure portal, toplu depolama kullanımı belirttiğiniz eşikleri aşarsa veya bu eşiklerin altına düşerse sizi bilgilendirmek için uyarı kuralları ekleyebilirsiniz.

Bloblar gibi çeşitli depolama nesnelerinin boyutunu tahmin etmek için Azure Depolama Faturalamasını Anlama – Bant Genişliği, İşlemler ve Kapasite blog gönderisine bakın.

Kullanılabilirliği izleme

Saatlik veya dakikalık ölçüm tablolarındaki sütundaki Availability değeri izleyerek depolama hesabınızdaki depolama hizmetlerinin kullanılabilirliğini izlemeniz gerekir: $MetricsHourPrimaryTransactionsBlob, $MetricsHourPrimaryTransactionsTable, $MetricsHourPrimaryTransactionsQueue, $MetricsMinutePrimaryTransactionsBlob, , $MetricsMinutePrimaryTransactionsTable, $MetricsMinutePrimaryTransactionsQueue$MetricsCapacityBlob. sütunu, Availability hizmetin kullanılabilirliğini veya satırın temsil ettiği API işlemini gösteren bir yüzde değeri içerir (satırın RowKey hizmetin bir bütün olarak mı yoksa belirli bir API işlemi için mi ölçümler içerdiğini gösterir).

%100'den küçük bir değer bazı depolama isteklerinin başarısız olduğunu gösterir. ServerTimeoutError gibi farklı hata türlerine sahip isteklerin sayısını gösteren ölçüm verilerindeki diğer sütunları inceleyerek neden başarısız olduklarını görebilirsiniz. Hizmet bölümleri daha iyi yük dengeleme isteklerine Availability taşırken geçici sunucu zaman aşımları gibi nedenlerle geçici olarak %100'in altına düşmeyi beklemeniz gerekir; istemci uygulamanızdaki yeniden deneme mantığı bu aralıklı koşulları işlemelidir. Günlüğe Kaydedilen İşlemler ve Durum İletileri Depolama Analizi makale, Depolama Ölçümlerinin hesaplamasına Availability dahil olduğu işlem türlerini listeler.

Azure portal, bir hizmet için belirttiğiniz eşiğin altına düşerse sizi Availability bilgilendirmek için uyarı kuralları ekleyebilirsiniz.

Bu kılavuzun Sorun giderme kılavuzu bölümünde kullanılabilirlik ile ilgili bazı yaygın depolama hizmeti sorunları açıklanmaktadır.

İzleme performansı

Depolama hizmetlerinin performansını izlemek için saatlik ve dakika ölçüm tablolarındaki aşağıdaki ölçümleri kullanabilirsiniz.

  • ve AverageServerLatency sütunlarındaki AverageE2ELatency değerler, depolama hizmetinin veya API işlem türünün istekleri işlemek için aldığı ortalama süreyi gösterir. AverageE2ELatency , isteği okumak ve isteği işlemek için geçen süreye ek olarak yanıt göndermek için geçen süreyi (dolayısıyla istek depolama hizmetine ulaştığında ağ gecikme süresini içerir) içeren uçtan uca gecikme süresi ölçüsüdür; AverageServerLatency yalnızca işlem süresinin ölçüsüdür ve bu nedenle istemciyle iletişim kurmayla ilgili ağ gecikme süresini dışlar. Bu kılavuzun devamında yer alan Yüksek AverageE2ELatency ve düşük AverageServerLatency değerlerini gösteren Ölçümler bölümüne göz atarak bu iki değer arasında neden önemli bir fark olabileceğine ilişkin bir tartışma bulabilirsiniz.
  • ve TotalEgress sütunlarındaki TotalIngress değerler, depolama hizmetinize veya belirli bir API işlem türü aracılığıyla gelen ve giden toplam veri miktarını bayt cinsinden gösterir.
  • Sütundaki TotalRequests değerler, API işleminin depolama hizmetinin aldığı toplam istek sayısını gösterir. TotalRequests depolama hizmetinin aldığı toplam istek sayısıdır.

Genellikle, bu değerlerden herhangi birinde beklenmeyen değişiklikler olup olmadığını izlersiniz, bu da araştırma gerektiren bir sorun olduğunu gösterir.

Azure portal, bu hizmet için performans ölçümlerinin belirttiğiniz eşiğin altına düşmesi veya aşması durumunda sizi bilgilendirmek için uyarı kuralları ekleyebilirsiniz.

Bu kılavuzun Sorun giderme kılavuzu bölümünde performansla ilgili bazı yaygın depolama hizmeti sorunları açıklanmaktadır.

Depolama sorunlarını tanılama

Uygulamanızdaki bir sorunu veya sorunu fark etmenin çeşitli yolları vardır, örneğin:

  • Uygulamanın kilitlenmesine veya çalışmayı durdurmasına neden olan önemli bir hata.
  • Önceki depolama hizmetinizi izleme bölümünde açıklandığı gibi izlediğiniz ölçümlerdeki temel değerlerden önemli değişiklikler.
  • Uygulamanızın kullanıcılarından belirli bir işlemin beklendiği gibi tamamlanmadığını veya bazı özelliklerin çalışmadığını bildirir.
  • Uygulamanız içinde günlük dosyalarında veya başka bir bildirim yöntemiyle görüntülenen hatalar.

Genellikle, Azure depolama hizmetleriyle ilgili sorunlar dört geniş kategoriden birine girer:

  • Uygulamanızda, kullanıcılarınız tarafından bildirilen veya performans ölçümlerindeki değişikliklerle ortaya çıkarılan bir performans sorunu var.
  • Bir veya daha fazla bölgede Azure Depolama altyapısıyla ilgili bir sorun var.
  • Uygulamanız, kullanıcılarınız tarafından bildirilen veya izlediğiniz hata sayısı ölçümlerinden birinde bir artışla ortaya konan bir hatayla karşılaşıyor.
  • Geliştirme ve test sırasında yerel depolama öykünücüsü kullanıyor olabilirsiniz; özellikle depolama öykünücüsünün kullanımıyla ilgili bazı sorunlarla karşılaşabilirsiniz.

Aşağıdaki bölümlerde, bu dört kategorinin her birinde sorunları tanılamak ve gidermek için izlemeniz gereken adımlar özetlenmiştir. Bu kılavuzun devamında yer alan Sorun giderme kılavuzu bölümü, karşılaşabileceğiniz bazı yaygın sorunlar için daha fazla ayrıntı sağlar.

Hizmet durumu sorunları

Hizmet durumu sorunlar genellikle denetiminizin dışındadır. Azure portal, depolama hizmetleri de dahil olmak üzere Azure hizmetleriyle ilgili devam eden sorunlar hakkında bilgi sağlar. Depolama hesabınızı oluştururken Read-Access Geo-Redundant Depolama'yı seçtiyseniz, verileriniz birincil konumda kullanılamaz duruma gelirse, uygulamanız geçici olarak ikincil konumdaki salt okunur kopyaya geçiş yapabilir. İkincilden okumak için uygulamanızın birincil ve ikincil depolama konumlarını kullanma arasında geçiş yapabilmesi ve salt okunur verilerle sınırlı işlevsellik modunda çalışabilmesi gerekir. Azure Depolama İstemcisi kitaplıkları, birincil depolamadan okumanın başarısız olması durumunda ikincil depolamadan okuyabilen bir yeniden deneme ilkesi tanımlamanıza olanak sağlar. Uygulamanızın ayrıca ikincil konumdaki verilerin sonunda tutarlı olduğunu da bilmesi gerekir. Daha fazla bilgi için Azure Depolama Yedeklilik Seçenekleri ve Okuma Erişimi Coğrafi Olarak Yedekli Depolama blog gönderisine bakın.

Performans sorunları

Bir uygulamanın performansı, özellikle kullanıcı açısından öznel olabilir. Bu nedenle, performans sorununun nerede olabileceğini belirlemenize yardımcı olmak için temel ölçümlerin kullanılabilir olması önemlidir. İstemci uygulaması açısından bir Azure depolama hizmetinin performansını birçok faktör etkileyebilir. Bu faktörler depolama hizmetinde, istemcide veya ağ altyapısında çalışabilir; Bu nedenle, performans sorununun kaynağını belirlemeye yönelik bir stratejiye sahip olmak önemlidir.

Ölçümlerden performans sorununun nedeninin olası konumunu belirledikten sonra, sorunu tanılamak ve gidermek için ayrıntılı bilgileri bulmak için günlük dosyalarını kullanabilirsiniz.

Bu kılavuzun devamında yer alan Sorun giderme kılavuzu bölümü, karşılaşabileceğiniz performansla ilgili bazı yaygın sorunlar hakkında daha fazla bilgi sağlar.

Hataları tanılama

Uygulamanızın kullanıcıları, istemci uygulama tarafından bildirilen hataları size bildirebilir. Depolama Ölçümleri ayrıca NetworkError, ClientTimeoutError veya AuthorizationError gibi depolama hizmetlerinizden farklı hata türlerinin sayısını kaydeder. Depolama Ölçümleri 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ı elde edebilirsiniz. Genellikle, depolama hizmeti tarafından döndürülen HTTP durum kodu isteğin neden başarısız olduğunu gösterir.

Not

Aralıklı hatalar görmeyi beklemeniz gerektiğini unutmayın: örneğin, geçici ağ koşullarından kaynaklanan hatalar veya uygulama hataları.

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

Depolama öykünücüsü sorunları

Azure SDK, geliştirme iş istasyonunda çalıştırabileceğiniz bir depolama öykünücüsü içerir. Bu öykünücü, Azure depolama hizmetlerinin davranışının çoğunu simüle eder ve geliştirme ve test sırasında yararlıdır; bu sayede Azure aboneliğine ve Azure depolama hesabına gerek kalmadan Azure depolama hizmetlerini kullanan uygulamaları çalıştırabilirsiniz.

Bu kılavuzun Sorun giderme kılavuzu bölümünde, depolama öykünücüsü kullanılarak karşılaşılan bazı yaygın sorunlar açıklanmaktadır.

Depolama günlüğü araçları

Depolama Günlüğü, Azure depolama hesabınızdaki depolama isteklerinin sunucu tarafında günlüğe kaydedilmesini sağlar. Sunucu tarafı günlüğünü etkinleştirme ve günlük verilerine erişme hakkında daha fazla bilgi için bkz. Depolama Günlüğünü Etkinleştirme ve Günlük Verilerine Erişme.

.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üğü.

Not

Bazı durumlarda (SAS yetkilendirme hataları gibi), bir kullanıcı sunucu tarafı Depolama günlüklerinde istek verilerini bulamadığınız bir hata bildirebilir. Sorunun nedeninin istemcide olup olmadığını araştırmak için Depolama İstemci Kitaplığı'nın günlük özelliklerini kullanabilir veya ağı araştırmak için ağ izleme araçlarını kullanabilirsiniz.

Ağ günlüğü araçlarını kullanma

İstemci ve sunucunun alışverişte olduğu veriler ve temel alınan ağ koşulları hakkında ayrıntılı bilgi sağlamak için istemci ile sunucu arasındaki trafiği yakalayabilirsiniz. Yararlı ağ günlüğü araçları şunlardır:

Çoğu durumda, Depolama Günlüğü ve Depolama İstemci Kitaplığı'ndaki günlük verileri bir sorunu tanılamak için yeterli olur, ancak bazı senaryolarda, bu ağ günlüğü araçlarının sağlayabilecekleri daha ayrıntılı bilgilere ihtiyacınız olabilir. Örneğin, HTTP ve HTTPS iletilerini görüntülemek için Fiddler'ı kullanmak, depolama hizmetlerine gönderilen ve depolama hizmetlerinden gönderilen üst bilgi ve yük verilerini görüntülemenizi sağlar ve bu da istemci uygulamasının depolama işlemlerini nasıl yeniden denemesini incelemenizi sağlar. Wireshark gibi protokol çözümleyicileri paket düzeyinde çalışır ve TCP verilerini görüntülemenizi sağlar ve bu da kayıp paketleri ve bağlantı sorunlarını gidermenizi sağlar.

Uçtan uca izleme

Çeşitli günlük dosyalarının kullanıldığı uçtan uca izleme, olası sorunları araştırmak için kullanışlı bir tekniktir. Sorunu gidermenize yardımcı olacak ayrıntılı bilgiler için günlük dosyalarına nereden bakabileceğinizi belirtmek için ölçüm verilerinizden tarih/saat bilgilerini kullanabilirsiniz.

Günlük verilerini ilişkilendirme

İstemci uygulamalarından, ağ izlemelerinden ve sunucu tarafı depolama günlüğünden günlükleri görüntülerken, istekleri farklı günlük dosyaları arasında ilişkilendirmek kritik önem taşır. Günlük dosyaları, bağıntı tanımlayıcıları olarak yararlı olan bir dizi farklı alan içerir. İstemci isteği kimliği, farklı günlüklerdeki girişleri ilişkilendirmek için kullanılacak en kullanışlı alandır. Ancak, bazen sunucu isteği kimliğini veya zaman damgalarını kullanmak yararlı olabilir. Aşağıdaki bölümlerde bu seçenekler hakkında daha fazla ayrıntı sağlanır.

İstemci isteği kimliği

Depolama İstemci Kitaplığı her istek için otomatik olarak benzersiz bir istemci istek kimliği oluşturur.

  • Depolama İstemci Kitaplığı'nın oluşturduğu istemci tarafı günlüğünde Client Request ID , istemci istek kimliği istekle ilgili her günlük girdisinin alanında görünür.
  • Fiddler tarafından yakalanan bir ağ izlemesinde, istemci istek kimliği istek iletilerinde HTTP üst bilgi değeri olarak x-ms-client-request-id görünür.
  • Sunucu tarafı Depolama Günlüğü günlüğünde, istemci isteği kimliği İstemci isteği kimliği sütununda görünür.

Not

İstemci bu değeri atayabildiği için birden çok isteğin aynı istemci istek kimliğini paylaşması mümkündür (Depolama İstemci Kitaplığı otomatik olarak yeni bir değer atasa da). İstemci yeniden denediğinde, tüm girişimler aynı istemci istek kimliğini paylaşır. İstemciden gönderilen bir toplu iş söz konusu olduğunda, toplu işlemin tek bir istemci istek kimliği vardır.

Sunucu isteği kimliği

Depolama hizmeti otomatik olarak sunucu isteği kimlikleri oluşturur.

  • Sunucu tarafı Depolama Günlüğü günlüğünde, sunucu isteği kimliği sütunda Request ID header görünür.
  • Fiddler tarafından yakalanan bir ağ izlemesinde, sunucu istek kimliği yanıt iletilerinde HTTP üst bilgi değeri olarak x-ms-request-id görünür.
  • Depolama İstemci Kitaplığı'nın oluşturduğu istemci tarafı günlüğünde Operation Text sunucu isteği kimliği, sunucu yanıtının ayrıntılarını gösteren günlük girdisinin sütununda görünür.

Not

Depolama hizmeti her zaman aldığı her isteğe benzersiz bir sunucu istek kimliği atar, bu nedenle istemciden yapılan her yeniden deneme girişimi ve toplu işleme dahil edilen her işlem benzersiz bir sunucu istek kimliğine sahiptir.

Aşağıdaki kod örneğinde özel istemci istek kimliğinin nasıl kullanılacağı gösterilmektedir.

var connectionString = Constants.connectionString;

BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);

BlobContainerClient blobContainerClient = blobServiceClient.GetBlobContainerClient("demcontainer");

BlobClient blobClient = blobContainerClient.GetBlobClient("testImage.jpg");

string clientRequestID = String.Format("{0} {1} {2} {3}", HOSTNAME, APPNAME, USERID, Guid.NewGuid().ToString());

using (HttpPipeline.CreateClientRequestIdScope(clientRequestID))
{
    BlobDownloadInfo download = blobClient.Download();

    using (FileStream downloadFileStream = File.OpenWrite("C:\\testImage.jpg"))
    {
        download.Content.CopyTo(downloadFileStream);
        downloadFileStream.Close();
    }
}

Zaman damga -ları

ayrıca, ilgili günlük girdilerini bulmak için zaman damgalarını da kullanabilirsiniz, ancak istemci ile sunucu arasında var olabilecek saat dengesizliklerine dikkat edin. İstemcideki zaman damgasına göre eşleşen sunucu tarafı girdileri için artı veya eksi 15 dakika Arama. Ölçümleri içeren blobların blob meta verilerinin blobda depolanan ölçümlerin zaman aralığını gösterdiğini unutmayın. Bu zaman aralığı, aynı dakika veya saat için çok sayıda ölçüm blob'larınız varsa kullanışlıdır.

Sorun giderme kılavuzu

Bu bölüm, uygulamanızın Azure depolama hizmetlerini kullanırken karşılaşabileceği yaygın sorunlardan bazılarının tanılaması ve sorunlarını giderme konusunda size yardımcı olacaktır. Sorununuzla ilgili bilgileri bulmak için aşağıdaki listeyi kullanın.

Karar ağacı sorunlarını giderme

Sorununuz depolama hizmetlerinden birinin performansıyla ilgili mi?

Sorununuz depolama hizmetlerinden birinin kullanılabilirliğiyle ilgili mi?

İstemci uygulamanız bir depolama hizmetinden HTTP 4XX (404 gibi) yanıtı mı alıyor?

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

Kapasite ölçümleri, depolama kapasitesi kullanımında beklenmeyen bir artış olduğunu gösterir.

Sorununuz, geliştirme veya test için depolama öykünücüsün kullanılmasından kaynak alır.

.NET için Azure SDK'sını yüklerken sorunlarla karşılaşabilirsiniz.

Depolama hizmetiyle ilgili farklı bir sorununuz var.

Ölçümler yüksek AverageE2ELatency ve düşük AverageServerLatency gösterir

Azure portal izleme aracındaki aşağıdaki çizimde AverageE2ELatency değerinin AverageServerLatency değerinden önemli ölçüde yüksek olduğu bir örnek gösterilmektedir.

AverageE2ELatency değerinin AverageServerLatency değerinden önemli ölçüde yüksek olduğu bir örneği gösteren Azure portal çizim.

Depolama hizmeti yalnızca başarılı istekler için AverageE2ELatency ölçümünü hesaplar ve AverageServerLatency'in aksine, istemcinin verileri göndermek ve depolama hizmetinden onay almak için aldığı süreyi içerir. Bu nedenle AverageE2ELatency ile AverageServerLatency arasındaki fark, istemci uygulamasının yanıt verme hızının yavaş olmasından veya ağdaki koşullardan kaynaklanıyor olabilir.

Not

Depolama Günlüğü günlük verilerinde tek tek depolama işlemleri için E2ELatency ve ServerLatency'ı da görüntüleyebilirsiniz.

İstemci performansı sorunlarını araştırma

İstemcinin yavaş yanıt vermesinin olası nedenleri arasında sınırlı sayıda kullanılabilir bağlantı veya iş parçacığı olması veya CPU, bellek veya ağ bant genişliği gibi kaynakların yetersiz olması sayılabilir. İstemci kodunu daha verimli olacak şekilde değiştirerek (örneğin, depolama hizmetine zaman uyumsuz çağrılar kullanarak) veya daha büyük bir Sanal Makine (daha fazla çekirdek ve daha fazla belleğe sahip) kullanarak sorunu çözebilirsiniz.

Tablo ve kuyruk hizmetleri için Nagle algoritması, AverageServerLatency ile karşılaştırıldığında yüksek AverageE2ELatency'a da neden olabilir. Daha fazla bilgi için bkz. Nagle Algoritması Küçük İsteklere Karşı Kolay Değil. Ad alanında sınıfını kullanarak kodda Nagle algoritmasını ServicePointManagerSystem.Net devre dışı bırakabilirsiniz. Zaten açık olan bağlantıları etkilemediğinden, uygulamanızdaki tablo veya kuyruk hizmetlerine herhangi bir çağrı yapmadan önce bunu yapmalısınız. Aşağıdaki örnek, çalışan rolündeki Application_Start yönteminden gelir.

var connectionString = Constants.connectionString;

QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);

ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(queueServiceClient.Uri);
queueServicePoint.UseNagleAlgorithm = false;

İstemci uygulamanızın kaç istek gönderdiğini görmek için istemci tarafı günlüklerini denetlemeniz ve genel olup olmadığını denetlemeniz gerekir. İstemcinizde CPU, .NET çöp toplama, ağ kullanımı veya bellek gibi NET ile ilgili performans sorunları. .NET istemci uygulamalarında sorun gidermeye yönelik bir başlangıç noktası olarak bkz. Hata Ayıklama, İzleme ve Profil Oluşturma.

Ağ gecikmesi sorunlarını araştırma

Genellikle, ağın neden olduğu uçtan uca yüksek gecikme süresi geçici koşullardan kaynaklanır. Wireshark gibi araçları kullanarak bırakılan paketler gibi hem geçici hem de kalıcı ağ sorunlarını araştırabilirsiniz.

Ağ sorunlarını gidermek için Wireshark kullanma hakkında daha fazla bilgi için bkz . Ek 2: Ağ trafiğini yakalamak için Wireshark kullanma.

Ölçümler düşük AverageE2ELatency ve düşük AverageServerLatency gösteriyor ancak istemcide yüksek gecikme süresi yaşanıyor

Bu senaryoda, en olası neden depolama isteklerinin depolama hizmetine ulaşmasındaki gecikmedir. İstemciden gelen isteklerin neden blob hizmetine iletilmediğini araştırmanız gerekir.

İstemcinin istekleri göndermeyi geciktirmesinin olası nedenlerinden biri, sınırlı sayıda kullanılabilir bağlantı veya iş parçacığı olmasıdır.

Ayrıca, istemcinin birden çok yeniden deneme yapıp yapmadığını denetleyin ve bunun nedenini araştırın. İstemcinin birden çok yeniden deneme yapıp yapmadığını belirlemek için şunları yapabilirsiniz:

  • Depolama Analizi günlüklerini inceleyin. Birden çok yeniden deneme gerçekleştiriliyorsa, aynı istemci isteği kimliğine sahip ancak farklı sunucu isteği kimliklerine sahip birden çok işlem görürsünüz.
  • İstemci günlüklerini inceleyin. Ayrıntılı günlük kaydı, yeniden denemenin gerçekleştiğini gösterir.
  • Kodunuzun hatalarını ayıklayın ve istekle ilişkili nesnenin OperationContext özelliklerini denetleyin. İşlem yeniden denendiyse, RequestResults özelliği birden çok benzersiz sunucu isteği kimlikleri içerir. Ayrıca her isteğin başlangıç ve bitiş saatlerini de de kontrol edebilirsiniz. Daha fazla bilgi için Sunucu isteği kimliği bölümündeki kod örneğine bakın.

İstemcide sorun yoksa paket kaybı gibi olası ağ sorunlarını araştırmanız gerekir. Ağ sorunlarını araştırmak için Wireshark gibi araçları kullanabilirsiniz.

Ağ sorunlarını gidermek için Wireshark kullanma hakkında daha fazla bilgi için bkz . Ek 2: Ağ trafiğini yakalamak için Wireshark kullanma.

Ölçümler yüksek AverageServerLatency gösteriyor

Blob indirme istekleri için yüksek AverageServerLatency olması durumunda, aynı blob (veya blob kümesi) için yinelenen istekler olup olmadığını görmek için Depolama Günlüğü günlüklerini kullanmanız gerekir. Blob karşıya yükleme isteklerinde istemcinin hangi blok boyutunu kullandığını araştırmanız gerekir (örneğin, okumalar 64 K'den küçük öbekler içinde olmadığı sürece 64 K'den küçük bloklar ek yüklere neden olabilir) ve birden çok istemci blokları paralel olarak aynı bloba yüklüyorsa. Saniye başına ölçeklenebilirlik hedeflerinin aşılmasıyla sonuçlanır istek sayısındaki ani artışlar için dakika başına ölçümleri de denetlemeniz gerekir. Daha fazla bilgi için bkz . Ölçümler PercentTimeoutError'da artış gösteriyor.

Aynı blob veya blob kümesi için yinelenen istekler olduğunda blob indirme istekleri için yüksek AverageServerLatency görüyorsanız bu blobları Azure Cache veya Azure Content Delivery Network (CDN) kullanarak önbelleğe almayı göz önünde bulundurun. Karşıya yükleme istekleri için daha büyük bir blok boyutu kullanarak aktarım hızını geliştirebilirsiniz. Tablolara yönelik sorgular için, aynı sorgu işlemlerini gerçekleştiren ve verilerin sık değişmediği istemcilerde istemci tarafı önbelleğe alma da uygulanabilir.

Yüksek AverageServerLatency değerleri, tarama işlemleriyle sonuçlanan veya ekleme/önceden eklenen anti-deseni izleyen kötü tasarlanmış tabloların veya sorguların belirtisi de olabilir. Daha fazla bilgi için bkz . Ölçümler PercentThrottlingError'da artış gösteriyor.

Not

Kapsamlı bir performans denetim listesini burada bulabilirsiniz: Microsoft Azure Depolama Performans ve Ölçeklenebilirlik Denetim Listesi.

Kuyrukta ileti tesliminde beklenmeyen gecikmeler yaşıyorsunuz

Uygulamanın kuyruğa ileti eklemesi ile kuyruktan okunmaya uygun hale gelmesi arasında bir gecikmeyle karşılaşıyorsanız, sorunu tanılamak için aşağıdaki adımları izleyin:

  • Uygulamanın iletileri kuyruğa başarıyla eklediğini doğrulayın. Uygulamanın başarılı olmadan önce yöntemi birkaç kez yeniden denemediğini AddMessage denetleyin. Depolama İstemci Kitaplığı günlükleri, depolama işlemlerinin yinelenen yeniden denemelerini gösterir.
  • İletiyi kuyruğa ekleyen çalışan rolü ile iletiyi kuyruktan okuyan çalışan rolü arasında saat dengesizliği olmadığını doğrulayın. Saat dengesizliği, işlemede gecikme varmış gibi görünmesini sağlar.
  • Kuyruktan iletileri okuyan çalışan rolünün başarısız olup olmadığını denetleyin. Bir kuyruk istemcisi yöntemini çağırır GetMessage ancak bir bildirimle yanıt vermezse, süre dolana kadar invisibilityTimeout ileti kuyrukta görünmez durumda kalır. Bu noktada, ileti yeniden işlenmek üzere kullanılabilir hale gelir.
  • Kuyruk uzunluğunun zaman içinde artıp artmadığını denetleyin. Diğer çalışanların kuyruğa yerleştirmiş olduğu tüm iletileri işlemek için yeterli çalışan yoksa bu durum oluşabilir. Ayrıca silme isteklerinin başarısız olup olmadığını görmek için ölçümleri denetleyin ve iletilerin sıralamasını kaldırın; bu da iletiyi silme girişimlerinin tekrar tekrar başarısız olduğunu gösterebilir.
  • Beklenenden daha uzun bir süre boyunca beklenenden daha yüksek E2ELatency ve ServerLatency değerlerine sahip tüm kuyruk işlemleri için Depolama Günlüğü günlüklerini inceleyin.

Ölçümler PercentThrottlingError'da artış gösteriyor

Bir depolama hizmetinin ölçeklenebilirlik hedeflerini aştığınızda azaltma hataları oluşur. Depolama hizmeti, tek bir istemcinin veya kiracının hizmeti başkalarının pahasına kullanabilmesini sağlamak için kısıtlar. Daha fazla bilgi için depolama hesapları için ölçeklenebilirlik hedefleri ve depolama hesapları içindeki bölümler için performans hedefleri hakkında ayrıntılı bilgi için bkz. Standart depolama hesapları için ölçeklenebilirlik ve performans hedefleri.

PercentThrottlingError ölçümü azaltma hatasıyla başarısız olan isteklerin yüzdesinde artış gösteriyorsa, iki senaryodan birini araştırmanız gerekir:

PercentThrottlingError'daki artış genellikle depolama isteği sayısındaki artışla veya başlangıçta uygulamanızın yük testi sırasında meydana gelir. Bu, istemcide depolama işlemlerinden "503 Sunucu Meşgul" veya "500 İşlem Zaman Aşımı" HTTP durum iletileri olarak da kendini gösterebilir.

PercentThrottlingError'da geçici artış

PercentThrottlingError değerinde uygulama için yüksek etkinlik dönemleriyle çakışan ani artışlar görüyorsanız, istemcinizdeki yeniden denemeler için üstel (doğrusal değil) bir geri çekilme stratejisi uygulayabilirsiniz. Geri alma yeniden denemeleri, bölümdeki anında yükü azaltır ve uygulamanızın trafikteki ani artışları düzeltmesine yardımcı olur. Depolama İstemci Kitaplığı'nı kullanarak yeniden deneme ilkelerini uygulama hakkında daha fazla bilgi için bkz. Microsoft.Azure.Storage.RetryPolicies ad alanı.

Not

PercentThrottlingError değerinde uygulama için yüksek etkinlik dönemleriyle çakışmayan ani artışlar da görebilirsiniz. Bunun en olası nedeni depolama hizmetinin yük dengelemeyi geliştirmek için bölümleri taşımasıdır.

PercentThrottlingError'da kalıcı artış

İşlem birimlerinizde kalıcı bir artış sonrasında PercentThrottlingError için tutarlı olarak yüksek bir değer görüyorsanız veya uygulamanızda ilk yük testlerinizi yapıyorsanız, uygulamanızın depolama bölümlerini nasıl kullandığını ve bir depolama hesabı için ölçeklenebilirlik hedeflerine yaklaşıp yaklaşmadığını değerlendirmeniz gerekir. Örneğin, bir kuyrukta azaltma hataları görüyorsanız (tek bir bölüm olarak sayılır), işlemleri birden çok bölüme yaymak için ek kuyruklar kullanmayı göz önünde bulundurun. Tabloda azaltma hataları görüyorsanız, daha geniş bir bölüm anahtarı değeri aralığı kullanarak işlemlerinizi birden çok bölüme yaymak için farklı bir bölümleme düzeni kullanmayı göz önünde bulundurmanız gerekir. Bu sorunun yaygın nedenlerinden biri, bölüm anahtarı olarak tarihi seçtiğiniz ve ardından belirli bir gündeki tüm verilerin tek bir bölüme yazıldığı ön ek/ekleme anti-desenidir: yük altında bu durum yazma sorununa neden olabilir. Farklı bir bölümleme tasarımını göz önünde bulundurun veya blob depolama kullanmanın daha iyi bir çözüm olup olmadığını değerlendirin. Ayrıca trafiğinizdeki ani artışlar nedeniyle azaltmanın gerçekleşip gerçekleşmediğini denetleyin ve istek deseninizi düzeltmenin yollarını araştırın.

İşlemlerinizi birden çok bölüme dağıtırsanız, depolama hesabı için ayarlanan ölçeklenebilirlik sınırlarının farkında olmanız gerekir. Örneğin, her biri saniyede en fazla 2.000 1 KB ileti işleyen on kuyruk kullandıysanız depolama hesabı için saniyede toplam 20.000 ileti sınırında olursunuz. Saniyede 20.000'den fazla varlığı işlemeniz gerekiyorsa, birden çok depolama hesabı kullanmayı göz önünde bulundurun. Ayrıca, isteklerinizin ve varlıklarınızın boyutunun, depolama hizmetinin istemcilerinizi azaltması üzerinde bir etkisi olduğunu da unutmayın. Daha büyük istekleriniz ve varlıklarınız varsa, daha erken kısıtlanabilirsiniz.

Verimsiz sorgu tasarımı, tablo bölümleri için ölçeklenebilirlik sınırlarına ulaşmanıza da neden olabilir. Örneğin, bir bölümdeki varlıkların yalnızca yüzde birini seçen ancak bir bölümdeki tüm varlıkları tarayan filtreye sahip bir sorgunun her varlığa erişmesi gerekir. Okunan her varlık, bu bölümdeki toplam işlem sayısına göre sayılır; bu nedenle, ölçeklenebilirlik hedeflerine kolayca ulaşabilirsiniz.

Not

Performans testinizde uygulamanızdaki verimsiz sorgu tasarımları gösterilmelidir.

Ölçümler PercentTimeoutError'da artış gösteriyor

Ölçümleriniz, depolama hizmetlerinizden biri için PercentTimeoutError'da bir artış gösteriyor. Aynı zamanda istemci, depolama işlemlerinden yüksek hacimli "500 İşlem Zaman Aşımı" HTTP durum iletisi alır.

Not

Depolama hizmeti bir bölümü yeni bir sunucuya taşıyarak isteklerin yükünü dengelediğinden geçici olarak zaman aşımı hataları görebilirsiniz.

PercentTimeoutError ölçümü şu ölçümlerin bir toplamıdır: ClientTimeoutError, AnonymousClientTimeoutError, SASClientTimeoutError, ServerTimeoutError, AnonymousServerTimeoutError ve SASServerTimeoutError.

Sunucu zaman aşımlarına sunucudaki bir hata neden olur. sunucudaki bir işlem istemci tarafından belirtilen zaman aşımını aştığından istemci zaman aşımları gerçekleşir; örneğin, Depolama İstemci Kitaplığı'nı kullanan bir istemci, sınıfın ServerTimeoutQueueRequestOptions özelliğini kullanarak bir işlem için zaman aşımı ayarlayabilir.

Sunucu zaman aşımları, daha fazla araştırma gerektiren depolama hizmetiyle ilgili bir sorun olduğunu gösterir. Hizmetin ölçeklenebilirlik sınırlarına ulaşıp ulaşılmadığını görmek ve trafikte bu soruna neden olabilecek ani artışları belirlemek için ölçümleri kullanabilirsiniz. Sorun aralıklı olarak oluşuyorsa, hizmetteki yük dengeleme etkinliğinden kaynaklanıyor olabilir. Sorun kalıcıysa ve uygulamanız hizmetin ölçeklenebilirlik sınırlarına ulaşıyorsa bir destek sorunu oluşturmalısınız. İstemci zaman aşımları için, zaman aşımının istemcide uygun bir değere ayarlanıp ayarlanmadığını belirlemeniz ve istemcide ayarlanan zaman aşımı değerini değiştirmeniz veya depolama hizmetindeki işlemlerin performansını nasıl geliştirebileceğinizi araştırmanız gerekir( örneğin, tablo sorgularınızı iyileştirerek veya iletilerinizin boyutunu azaltarak).

Ölçümler PercentNetworkError'da artış gösteriyor

Ölçümleriniz, depolama hizmetlerinizden biri için PercentNetworkError'da bir artış gösteriyor. PercentNetworkError ölçümü şu ölçümlerin bir toplamıdır: NetworkError, AnonymousNetworkError ve SASNetworkError. Bunlar, depolama hizmeti istemci bir depolama isteği yaptığında bir ağ hatası algıladığında oluşur.

Bu hatanın en yaygın nedeni, depolama hizmetinde zaman aşımı süresi dolmadan önce istemcinin bağlantısının kesilmesidir. İstemcinin depolama hizmetiyle bağlantısının neden ve ne zaman kesiliyor olduğunu anlamak için istemcinizdeki kodu araştırın. İstemciden gelen ağ bağlantısı sorunlarını araştırmak için Wireshark veya Tcping'i de kullanabilirsiniz. Bu araçlar Eklerde açıklanmıştır.

İ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). Nedeni süresi dolmuş bir SAS anahtarıysa, sunucu tarafı Depolama Günlüğü günlük verilerinde hiçbir girdi görmezsiniz. 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:

Kaynak Ayrıntı Ayrıntı İstemci isteği kimliği İşlem metni
Microsoft.Azure.Storage Bilgi 3 85d077ab-... Starting operation with location Primary per location mode PrimaryOnly.
Microsoft.Azure.Storage Bilgi 3 85d077ab -... Starting synchronous request to https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests#Synchronous_request.
Microsoft.Azure.Storage Bilgi 3 85d077ab -... Waiting for response.
Microsoft.Azure.Storage Uyarı 2 85d077ab -... Exception thrown while waiting for response: The remote server returned an error: (403) Forbidden.
Microsoft.Azure.Storage Bilgi 3 85d077ab -... Response received. Status code = 403, Request ID = <Request ID>, Content-MD5 = , ETag = .
Microsoft.Azure.Storage Uyarı 2 85d077ab -... Exception thrown during the operation: The remote server returned an error: (403) Forbidden..
Microsoft.Azure.Storage Bilgi 3 85d077ab -... Checking if the operation should be retried. Retry count = 0, HTTP status code = 403, Exception = The remote server returned an error: (403) Forbidden..
Microsoft.Azure.Storage Bilgi 3 85d077ab -... The next location has been set to Primary, based on the location mode.
Microsoft.Azure.Storage Error 1 85d077ab -... Retry policy did not allow for a retry. Failing with The remote server returned an error: (403) Forbidden.

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'nin beklenenden daha önce sona ermesine yol açabilir.
  • 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şiyor mu? Her zaman Depolama İstemci 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 sildi

İstemcinin bir depolama hizmetindeki verileri okumaya, güncelleştirmeye veya silmeye çalıştığı senaryolarda, sunucu tarafı günlüklerinde söz konusu nesneyi depolama hizmetinden silmiş önceki bir işlemi tanımlamak genellikle kolaydır. Günlük verileri genellikle başka bir kullanıcının veya işlemin nesneyi sildiğini gösterir. Sunucu tarafı Depolama Günlüğü günlüğünde, bir istemci bir nesneyi sildiğinde işlem türü ve requested-object-key sütunları gösterilir.

İ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 ayrıntılı bir şekilde 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:

İstek Kimliği Işlem
07b26a5d-... DeleteIfExists blob kapsayıcısını silme yöntemi. Bu işlemin kapsayıcının varlığını denetleme isteği içerdiğini HEAD unutmayın.
e2d06d78... CreateIfNotExists yöntemiyle blob kapsayıcısını oluşturabilirsiniz. Bu işlemin kapsayıcının varlığını denetleen bir HEAD istek içerdiğini unutmayın. HEAD 404 iletisini döndürür ancak devam eder.
de8b1c3c-... UploadFromStream yöntemini kullanarak blobu oluşturun. İstek PUT 404 iletisiyle başarısız oluyor.

Günlük girdileri:

İstek Kimliği İşlem metni
07b26a5d-... Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.
07b26a5d-... StringToSign = HEAD............x-ms-client-request-id:07b26a5d-....x-ms-date:Tue, 03 Jun 2014 10:33:11 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.
07b26a5d-... Waiting for response.
07b26a5d-... Response received. Status code = 200, Request ID = eeead849-...Content-MD5 = , ETag = &quot;0x8D14D2DC63D059B&quot;.
07b26a5d-... Response headers were processed successfully, proceeding with the rest of the operation.
07b26a5d-... Downloading response body.
07b26a5d-... Operation completed successfully.
07b26a5d-... Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.
07b26a5d-... StringToSign = DELETE............x-ms-client-request-id:07b26a5d-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.
07b26a5d-... Waiting for response.
07b26a5d-... Response received. Status code = 202, Request ID = 6ab2a4cf-..., Content-MD5 = , ETag = .
07b26a5d-... Response headers were processed successfully, proceeding with the rest of the operation.
07b26a5d-... Downloading response body.
07b26a5d-... Operation completed successfully.
e2d06d78-... Starting asynchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.
e2d06d78-... StringToSign = HEAD............x-ms-client-request-id:e2d06d78-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.
e2d06d78-... Waiting for response.
de8b1c3c-... Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer/blobCreated.txt.
de8b1c3c-... StringToSign = PUT...64.qCmF+TQLPhq/YYK50mP9ZQ==........x-ms-blob-type:BlockBlob.x-ms-client-request-id:de8b1c3c-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer/blobCreated.txt.
de8b1c3c-... Preparing to write request data.
e2d06d78-... Exception thrown while waiting for response: The remote server returned an error: (404) Not Found..
e2d06d78-... Response received. Status code = 404, Request ID = 353ae3bc-..., Content-MD5 = , ETag = .
e2d06d78-... Response headers were processed successfully, proceeding with the rest of the operation.
e2d06d78-... Downloading response body.
e2d06d78-... Operation completed successfully.
e2d06d78-... Starting asynchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.
e2d06d78-... StringToSign = PUT...0.........x-ms-client-request-id:e2d06d78-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.
e2d06d78-... Waiting for response.
de8b1c3c-... Writing request data.
de8b1c3c-... Waiting for response.
e2d06d78-... Exception thrown while waiting for response: The remote server returned an error: (409) Conflict..
e2d06d78-... Response received. Status code = 409, Request ID = c27da20e-..., Content-MD5 = , ETag = .
e2d06d78-... Downloading error response body.
de8b1c3c-... Exception thrown while waiting for response: The remote server returned an error: (404) Not Found..
de8b1c3c-... Response received. Status code = 404, Request ID = 0eaeab3e-..., Content-MD5 = , ETag = .
de8b1c3c-... Exception thrown during the operation: The remote server returned an error: (404) Not Found..
de8b1c3c-... Retry policy did not allow for a retry. Failing with The remote server returned an error: (404) Not Found..
e2d06d78-... Retry policy did not allow for a retry. Failing with The remote server returned an error: (409) Conflict..

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 ölçümlerde için SASAuthorizationError sıfır olmayan bir değer de görürsünüz.

Aşağıdaki tabloda Depolama Günlüğü günlük dosyasından örnek bir sunucu tarafı günlük iletisi gösterilmektedir:

Name Değer
İstek başlangıç zamanı 2014-05-30T06:17:48.4473697Z
İşlem türü GetBlobProperties
İstek durumu SASAuthorizationError
HTTP durum kodu 404
Kimlik doğrulama türü Sas
Hizmet türü Blob
İstek URL'si https://domemaildist.blob.core.windows.net/azureimblobcontainer/blobCreatedViaSAS.txt
  ?sv=2014-02-14&sr=c&si=mypolicy&sig=XXXXX&; api-version=2014-02-14
İstek Kimliği üst bilgisi <İstek Kimliği üst bilgisi>
İstemci isteği kimliği <İstemci isteği kimliği>

İ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ı denetlersiniz:

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

Not

İstemci tarafı JavaScript sorunlarını giderirken tarayıcı ile depolama hizmeti arasında gönderilen iletileri izlemek için Internet Explorer'daki F12 Geliştirici Araçları'nı kullanabilirsiniz.

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 dosyasındaki sütunda arama request-id-header yaparak sunucu tarafı depolama günlüklerindeki 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 çok kısa bir 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 almamasıdır (belki de geçici bir ağ sorunu nedeniyle). 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

Aşağıdaki tabloda iki istemci işlemi için sunucu tarafı günlüğünden bir ayıklama gösterilmektedir: DeleteIfExists ardından hemen CreateIfNotExists aynı blob kapsayıcı adı kullanılır. Her istemci işlemi sunucuya gönderilen iki istekle sonuçlanırsa, önce GetContainerProperties kapsayıcının var olup olmadığını denetleme isteği ve ardından DeleteContainer veya CreateContainer isteği olur.

Zaman damgası Işlem Sonuç Kapsayıcı adı İstemci isteği kimliği
05:10:13.7167225 GetContainerProperties 200 mmcont c9f52c89-...
05:10:13.8167325 DeleteContainer 202 mmcont c9f52c89-...
05:10:13.8987407 GetContainerProperties 404 mmcont bc881924-...
05:10:14.2147723 CreateContainer 409 mmcont bc881924-...

İstemci uygulamasındaki kod, aynı adı kullanarak bir blob kapsayıcısını siler ve hemen yeniden oluşturur: CreateIfNotExists yöntemi (İstemci isteği kimliği bc881924-...) sonunda HTTP 409 (Çakışma) hatasıyla başarısız olur. İ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.

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

PercentSuccess ölçümü, 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ındaki durum kodları olan işlemler başarısız olarak sayılır ve PercentSuccess ölçüm değerini düşürür. Sunucu tarafı depolama günlüğü dosyalarında bu işlemler ClientOtherErrors işlem durumuyla kaydedilir.

Bu işlemlerin başarıyla tamamlandığını ve bu nedenle kullanılabilirlik gibi diğer ölçümleri etkilemediğini unutmayın. 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 bir istekten GET 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.

Kapasite ölçümleri depolama kapasitesi kullanımında beklenmeyen bir artış gösteriyor

Depolama hesabınızda kapasite kullanımında ani ve beklenmeyen değişiklikler görürseniz, önce kullanılabilirlik ölçümlerinize bakarak nedenleri araştırabilirsiniz; örneğin, başarısız silme isteklerinin sayısındaki artış, uygulamaya özgü temizleme işlemleri olarak kullandığınız blob depolama miktarının artmasına yol açabilir ve alan boşaltmayı beklemiş olabileceğiniz gibi çalışmayabilir (örneğin, yer açmak için kullanılan SAS belirteçlerinin süresi dolduğundan).

Sorununuz, geliştirme veya test için depolama öykünücüsün kullanılmasından kaynaklanmalı

Azure depolama hesabı gereksinimini önlemek için genellikle geliştirme ve test sırasında depolama öykünücüsü kullanırsınız. Depolama öykünücüsü kullanırken oluşabilecek yaygın sorunlar şunlardır:

"X" özelliği depolama öykünücüsunda çalışmıyor

Depolama öykünücüsü, dosya hizmeti gibi Azure depolama hizmetlerinin tüm özelliklerini desteklemez. Daha fazla bilgi için bkz. Geliştirme ve Test için Azure Depolama Öykünücüsü'ni kullanma.

Depolama öykünücüsunun desteklemediği özellikler için bulutta Azure depolama hizmetini kullanın.

Depolama öykünücüsü kullanılırken "HTTP üst bilgilerinden birinin değeri doğru biçimde değil" hatası

Depolama İstemci Kitaplığı'nı kullanan uygulamanızı yerel depolama öykünücüsüyle test ediyor ve "HTTP üst bilgilerinden birinin değeri doğru biçimde değil" hata iletisiyle başarısız oluyor gibi CreateIfNotExists yöntem çağrıları. Bu, kullandığınız depolama öykünücüsünün sürümünün kullandığınız depolama istemci kitaplığının sürümünü desteklemediğini gösterir. Depolama İstemci Kitaplığı, üst bilgiyi x-ms-version yaptığı tüm isteklere ekler. Depolama öykünücüsü üst bilgideki x-ms-version değeri tanımıyorsa isteği reddeder.

Depolama Kitaplığı İstemci günlüklerini kullanarak gönderdiği değeri x-ms-version header görebilirsiniz. İstemci uygulamanızdan gelen istekleri izlemek için Fiddler kullanıyorsanız değerini x-ms-version header de görebilirsiniz.

Bu senaryo genellikle depolama öykünücüsünün güncelleştirilmesi gerekmeden Depolama İstemci Kitaplığı'nın en son sürümünü yükler ve kullanırsanız oluşur. Depolama öykünücüsünün en son sürümünü yüklemeniz veya geliştirme ve test için öykünücü yerine bulut depolamayı kullanmanız gerekir.

Depolama öykünücüsunun çalıştırılması için yönetim ayrıcalıkları gerekir

Depolama öykünücüsü çalıştırıldığında yönetici kimlik bilgileri istenir. Bu durum yalnızca depolama öykünücüsü ilk kez başlatılırken oluşur. Depolama öykünücüsü başlatıldıktan sonra yeniden çalıştırmak için yönetici ayrıcalıklarına ihtiyacınız olmaz.

Daha fazla bilgi için bkz. Geliştirme ve Test için Azure Depolama Öykünücüsü'ni kullanma. Ayrıca, yönetim ayrıcalıkları da gerektiren Visual Studio'da depolama öykünücüsü başlatabilirsiniz.

.NET için Azure SDK'sını yüklerken sorunlarla karşılaşabilirsiniz

SDK'yı yüklemeye çalıştığınızda, yerel makinenize depolama öykünücüsü yüklenmeye çalışıldığında başarısız olur. Yükleme günlüğü aşağıdaki iletilerden birini içerir:

  • CAQuietExec: Hata: SQL örneğine erişilemiyor
  • CAQuietExec: Hata: Veritabanı oluşturulamıyor

Bunun nedeni, mevcut LocalDB yüklemesiyle ilgili bir sorundur. Varsayılan olarak, depolama öykünücüsü, Azure depolama hizmetlerinin benzetimini yaparken verileri kalıcı hale getirmek için LocalDB kullanır. SDK'yı yüklemeye çalışmadan önce bir komut istemi penceresinde aşağıdaki komutları çalıştırarak LocalDB örneğinizi sıfırlayabilirsiniz.

sqllocaldb stop v11.0
sqllocaldb delete v11.0
delete %USERPROFILE%\WAStorageEmulatorDb3*.*
sqllocaldb create v11.0

komutu, delete depolama öykünücüsünün önceki yüklemelerinden tüm eski veritabanı dosyalarını kaldırır.

Depolama hizmetiyle ilgili farklı bir sorununuz var

Önceki sorun giderme bölümleri bir depolama hizmetinde yaşadığınız sorunu içermiyorsa, sorununuzu tanılamak ve gidermek için aşağıdaki yaklaşımı benimsemeniz gerekir.

  • Beklenen temel davranışınızdan herhangi bir değişiklik olup olmadığını görmek için ölçümlerinizi denetleyin. Ölçümlerden, sorunun geçici mi yoksa kalıcı mı olduğunu ve sorunun hangi depolama işlemlerini etkilediğini belirleyebilirsiniz.
  • Oluşan hatalar hakkında daha ayrıntılı bilgi için sunucu tarafı günlük verilerinizi aramanıza yardımcı olması için ölçüm bilgilerini kullanabilirsiniz. Bu bilgiler sorunu gidermenize ve çözmenize yardımcı olabilir.
  • Sunucu tarafı günlüklerindeki bilgiler sorunu başarıyla gidermek için yeterli değilse, ağınızı araştırmak için istemci uygulamanızın ve Fiddler ve Wireshark gibi araçların davranışını araştırmak için Depolama İstemci Kitaplığı istemci tarafı günlüklerini kullanabilirsiniz.

Fiddler kullanma hakkında daha fazla bilgi için bkz. Ek 1: HTTP ve HTTPS trafiğini yakalamak için Fiddler kullanma.

Wireshark kullanma hakkında daha fazla bilgi için bkz . Ek 2: Ağ trafiğini yakalamak için Wireshark kullanma.

Ekler

Eklerde, Azure Depolama (ve diğer hizmetler) ile ilgili sorunları tanılarken ve giderirken yararlı bulabileceğiniz çeşitli araçlar açıklanmaktadır. Bu araçlar Azure Depolama'nın bir parçası değildir ve bazıları üçüncü taraf ürünlerdir. Bu nedenle, bu eklerde açıklanan araçlar, Microsoft Azure veya Azure Depolama ile sahip olabileceğiniz herhangi bir destek sözleşmesi kapsamında değildir. Bu nedenle değerlendirme sürecinizin bir parçası olarak, bu araçların sağlayıcıları tarafından sağlanan lisanslama ve destek seçeneklerini incelemeniz gerekir.

Ek 1: HTTP ve HTTPS trafiğini yakalamak için Fiddler kullanma

Fiddler , istemci uygulamanızla kullandığınız Azure depolama hizmeti arasındaki HTTP ve HTTPS trafiğini analiz etmek için kullanışlı bir araçtır.

Not

Fiddler, HTTPS trafiğinin kodunu çözebilir. Fiddler'ın bunu nasıl yaptığını ve güvenlik üzerindeki etkilerini anlamak için Fiddler belgelerini dikkatle okumalısınız.

Bu ek, Fiddler'ı Fiddler'ı yüklediğiniz yerel makine ile Azure depolama hizmetleri arasındaki trafiği yakalamak için fiddler'ın nasıl yapılandırıldığına ilişkin kısa bir kılavuz sağlar.

Fiddler'ı başlattıktan sonra yerel makinenizde HTTP ve HTTPS trafiğini yakalamaya başlar. Fiddler'ı denetlemeye yönelik bazı yararlı komutlar aşağıdadır:

  • Trafiği durdurup yakalamaya başlayın. Ana menüde Dosya'ya gidin ve yakalamayı açıp kapatmak için Trafiği Yakala'yı seçin.
  • Yakalanan trafik verilerini kaydedin. Ana menüde Dosya'ya gidin, Kaydet'i ve ardından Tüm Oturumlar'ı seçin. Bu, trafiği bir Oturum Arşivi dosyasına kaydetmenizi sağlar. Bir Oturum Arşivi'nin daha sonra analiz için yeniden yüklenmesini sağlayabilir veya istenirse Microsoft desteğine gönderebilirsiniz.

Fiddler'ın yakaladığı trafik miktarını sınırlamak için Filtreler sekmesinde yapılandırdığınız filtreleri kullanabilirsiniz. Aşağıdaki ekran görüntüsünde yalnızca depolama uç noktasına gönderilen contosoemaildist.table.core.windows.net trafiği yakalayan bir filtre gösterilmektedir:

Yalnızca contosoemaildist.table.core.windows.net depolama uç noktasına gönderilen trafiği yakalayan bir filtreyi gösteren ekran görüntüsü.

Ek 2: Ağ trafiğini yakalamak için Wireshark kullanma

Wireshark , çok çeşitli ağ protokolleri için ayrıntılı paket bilgilerini görüntülemenizi sağlayan bir ağ protokolü çözümleyicisidir.

Aşağıdaki yordamda Wireshark'ı Yüklediğiniz yerel makineden Azure depolama hesabınızdaki tablo hizmetine gelen trafik için ayrıntılı paket bilgilerini nasıl yakalayabileceğiniz gösterilmektedir.

  1. Yerel makinenizde Wireshark'ı başlatın.

  2. Başlangıç bölümünde yerel ağ arabirimini veya İnternet'e bağlı arabirimleri seçin.

  3. Yakalama Seçenekleri'ni seçin.

  4. Yakalama Filtresi metin kutusuna bir filtre ekleyin. Örneğin, host contosoemaildist.table.core.windows.net Wireshark'ı yalnızca contosoemaildist depolama hesabındaki tablo hizmeti uç noktasına gönderilen veya bu uç noktadan gönderilen paketleri yakalayacak şekilde yapılandırır. Yakalama Filtreleri'nin tam listesine göz atın.

    Yakalama Filtresi metin kutusuna filtre eklemeyi gösteren ekran görüntüsü.

  5. Başlat'ı seçin. Wireshark artık istemci uygulamanızı yerel makinenizde kullanırken tablo hizmeti uç noktasına veya uç noktasından gönderilen tüm paketleri yakalar.

  6. İşiniz bittiğinde ana menüde Yakalama>Durağı'nı seçin.

  7. Yakalanan verileri Wireshark Capture dosyasına kaydetmek için ana menüden Dosya>Kaydet'i seçin.

WireShark , paket listesi penceresinde var olan hataları vurgular. Hata ve uyarıların özetini görüntülemek için Uzman Bilgileri penceresini de kullanabilirsiniz (Uzman BilgileriniÇözümle'yi> seçin).

Hata ve uyarıların özetini görüntüleyebileceğiniz Uzman Bilgileri penceresini gösteren ekran görüntüsü.

Ayrıca, uygulama katmanı tcp verilerine sağ tıklayıp TCP Stream takip et'i seçerek TCP verilerini görüntülemeyi de seçebilirsiniz. Dökümünüzü yakalama filtresi olmadan yakaladıysanız bu yararlı olur. Daha fazla bilgi için bkz . Takip Edilen TCP Akışları.

Uygulama katmanında tcp verilerinin nasıl görüntülendiğini gösteren ekran görüntüsü.

Not

Wireshark kullanma hakkında daha fazla bilgi için bkz. Wireshark Kullanıcıları Kılavuzu.

Ek 4: Ölçümleri ve günlük verilerini görüntülemek için Excel'i kullanma

Birçok araç, Depolama Ölçümleri verilerini Azure tablo depolama alanından sınırlandırılmış biçimde indirmenize olanak tanır ve bu sayede verileri görüntülemek ve analiz etmek için Excel'e kolayca yükleyebilirsiniz. Azure Blob Depolama depolama günlüğü verileri zaten Excel'e yükleyebileceğiniz sınırlandırılmış bir biçimdedir. Ancak, Depolama Analizi Günlük Biçimi ve Depolama Analizi Ölçümler Tablosu Şeması'ndaki bilgilere göre uygun sütun başlıkları eklemeniz gerekir.

Depolama Günlüğü verilerinizi blob depolamadan indirdikten sonra Excel'e aktarmak için:

  • Veri menüsünde Metinden'i seçin.
  • Görüntülemek istediğiniz günlük dosyasına gidin ve İçeri Aktar'ı seçin.
  • Metin İçeri Aktarma Sihirbazı'nın 1. adımında Sınırlandırılmış'ı seçin.

Metin İçeri Aktarma Sihirbazı'nın 1. adımında, tek sınırlayıcı olarak Noktalı Virgül'e tıklayın ve Metin niteleyicisi olarak çift tırnak seçin. Ardından Son'u seçin ve verilerin çalışma kitabınıza yerleştirileceği yeri seçin.

Ek 5: Azure DevOps için Application Insights ile izleme

Performans ve kullanılabilirlik izlemenizin bir parçası olarak Azure DevOps için Application Insights özelliğini de kullanabilirsiniz. Bu araç:

  • Web hizmetinizin kullanılabilir ve duyarlı olduğundan emin olun. Uygulamanız ister bir web sitesi ister web hizmeti kullanan bir cihaz uygulaması olsun, URL'nizi dünya çapındaki konumlardan birkaç dakikada bir test edebilir ve bir sorun olup olmadığını size bildirebilir.
  • Web hizmetinizdeki performans sorunlarını veya özel durumları hızla tanılayın. CPU veya diğer kaynakların esnetilip genişletilmediğini öğrenin, özel durumlardan yığın izlemeleri alın ve günlük izlemeleri arasında kolayca arama yapın. Uygulamanın performansı kabul edilebilir sınırların altına düşerse Microsoft size bir e-posta gönderebilir. Hem .NET hem de Java web hizmetlerini izleyebilirsiniz.

Application Insights nedir? bölümünde daha fazla bilgi bulabilirsiniz.

Sonraki adımlar

Azure Depolama'daki analiz hakkında daha fazla bilgi için şu kaynaklara bakın:

Üçüncü taraf bilgileri hakkında yasal uyarı

Bu makalede adı geçen üçüncü taraf ürünleri Microsoft'tan bağımsız şirketler tarafından üretilmektedir. Microsoft, bu ürünlerin performansı veya güvenilirliği ile ilgili örtük veya başka türlü hiçbir garanti vermez.

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.