NoSQL hesapları için API ile Azure Cosmos DB Java SDK v4 kullanırken karşılaşılan sorunları giderme

UYGULANANLAR: NoSQL

Bu makale, NoSQL hesapları için Azure Cosmos DB ile Azure Cosmos DB Java SDK v4 kullanırken karşılaşılan yaygın sorunları, geçici çözümleri, tanılama adımlarını ve araçları kapsar. Azure Cosmos DB Java SDK v4, NoSQL için Azure Cosmos DB'ye erişmek için istemci tarafı mantıksal gösterimi sağlar. Bu makalede, sorunla karşılaştığınızda size yardımcı olacak araçlar ve yaklaşımlar açıklanır.

Şu listeyle başlayın:

• Bu makaledeki Yaygın sorunlar ve geçici çözümler bölümüne göz atın.
• GitHub'da açık kaynak kullanılabilen Azure Cosmos DB merkezi deposundaki Java SDK'sını inceleyin. Etkin olarak izlenen bir sorunlar bölümü vardır. Geçici çözümle ilgili benzer bir sorunun zaten dosyalanmış olup olmadığını denetleyin. Yararlı bir ipucu, sorunları etikete göre filtrelemektir *cosmos:v4-item* .
• Azure Cosmos DB Java SDK v4 için performans ipuçlarını gözden geçirin ve önerilen uygulamaları izleyin.
• Çözüm bulamadıysanız bu makalenin geri kalanını okuyun. Ardından bir GitHub sorunu oluşturun. GitHub sorununuza etiket ekleme seçeneği varsa etiket *cosmos:v4-item* ekleyin.

Tanılamayı yakalama

Java V4 SDK’sındaki veritabanı, kapsayıcı, öğe ve sorgu yanıtlarında Tanılama özelliği vardır. Bu özellik, yeniden denemeler veya geçici hatalar olup olmadığı dahil olmak üzere tek istekle ilgili tüm bilgileri kaydeder.

Tanılama bir dize olarak döndürülür. Farklı senaryolarda daha iyi sorun gidermeye yönelik iyileştirildiğinden, dize her sürümde değişir. SDK'nın her sürümünde dize biçimini bozabilir. Hataya neden olan değişiklikleri önlemek için dizeyi ayrıştırmayın.

Aşağıdaki kod örneğinde Java V4 SDK'sını kullanarak tanılama günlüklerinin nasıl okunduğu gösterilmektedir:

CosmosDatabaseResponse databaseResponse = client.createDatabaseIfNotExists(databaseName);
CosmosDiagnostics diagnostics = databaseResponse.getDiagnostics();
logger.info("Create database diagnostics : {}", diagnostics); 

CosmosContainerResponse containerResponse = database.createContainerIfNotExists(containerProperties,
                  throughputProperties);
CosmosDiagnostics diagnostics = containerResponse.getDiagnostics();
logger.info("Create container diagnostics : {}", diagnostics);

// Write Item
CosmosItemResponse<Family> item = container.createItem(family, new PartitionKey(family.getLastName()),
                    new CosmosItemRequestOptions());
        
CosmosDiagnostics diagnostics = item.getDiagnostics();
logger.info("Create item diagnostics : {}", diagnostics);
        
// Read Item
CosmosItemResponse<Family> familyCosmosItemResponse = container.readItem(documentId,
                    new PartitionKey(documentLastName), Family.class);
        
CosmosDiagnostics diagnostics = familyCosmosItemResponse.getDiagnostics();
logger.info("Read item diagnostics : {}", diagnostics);

String sql = "SELECT * FROM c WHERE c.lastName = 'Witherspoon'";
        
CosmosPagedIterable<Family> filteredFamilies = container.queryItems(sql, new CosmosQueryRequestOptions(),
                    Family.class);
        
//  Add handler to capture diagnostics
filteredFamilies = filteredFamilies.handle(familyFeedResponse -> {
    logger.info("Query Item diagnostics through handle : {}", 
    familyFeedResponse.getCosmosDiagnostics());
});
        
//  Or capture diagnostics through iterableByPage() APIs.
filteredFamilies.iterableByPage().forEach(familyFeedResponse -> {
    logger.info("Query item diagnostics through iterableByPage : {}",
    familyFeedResponse.getCosmosDiagnostics());
});

try {
  CosmosItemResponse<Family> familyCosmosItemResponse = container.readItem(documentId,
                    new PartitionKey(documentLastName), Family.class);
} catch (CosmosException ex) {
  CosmosDiagnostics diagnostics = ex.getDiagnostics();
  logger.error("Read item failure diagnostics : {}", diagnostics);
}

Mono<CosmosDatabaseResponse> databaseResponseMono = client.createDatabaseIfNotExists(databaseName);
databaseResponseMono.map(databaseResponse -> {
  CosmosDiagnostics diagnostics = databaseResponse.getDiagnostics();
  logger.info("Create database diagnostics : {}", diagnostics);
}).subscribe();

Mono<CosmosContainerResponse> containerResponseMono = database.createContainerIfNotExists(containerProperties,
                    throughputProperties);
containerResponseMono.map(containerResponse -> {
  CosmosDiagnostics diagnostics = containerResponse.getDiagnostics();
  logger.info("Create container diagnostics : {}", diagnostics);
}).subscribe();

// Write Item
Mono<CosmosItemResponse<Family>> itemResponseMono = container.createItem(family,
                    new PartitionKey(family.getLastName()),
                    new CosmosItemRequestOptions());
        
itemResponseMono.map(itemResponse -> {
  CosmosDiagnostics diagnostics = itemResponse.getDiagnostics();
  logger.info("Create item diagnostics : {}", diagnostics);
}).subscribe();
        
// Read Item
Mono<CosmosItemResponse<Family>> itemResponseMono = container.readItem(documentId,
                    new PartitionKey(documentLastName), Family.class);

itemResponseMono.map(itemResponse -> {
  CosmosDiagnostics diagnostics = itemResponse.getDiagnostics();
  logger.info("Read item diagnostics : {}", diagnostics);
}).subscribe();

String sql = "SELECT * FROM c WHERE c.lastName = 'Witherspoon'";
CosmosPagedFlux<Family> filteredFamilies = container.queryItems(sql, new CosmosQueryRequestOptions(),
                    Family.class);
//  Add handler to capture diagnostics
filteredFamilies = filteredFamilies.handle(familyFeedResponse -> {
  logger.info("Query Item diagnostics through handle : {}",
  familyFeedResponse.getCosmosDiagnostics());
});
        
//  Or capture diagnostics through byPage() APIs.
filteredFamilies.byPage().map(familyFeedResponse -> {
  logger.info("Query item diagnostics through byPage : {}",
  familyFeedResponse.getCosmosDiagnostics());
}).subscribe();

Mono<CosmosItemResponse<Family>> itemResponseMono = container.readItem(documentId,
                    new PartitionKey(documentLastName), Family.class);

itemResponseMono.onErrorResume(throwable -> {
  if (throwable instanceof CosmosException) {
    CosmosException cosmosException = (CosmosException) throwable;
    CosmosDiagnostics diagnostics = cosmosException.getDiagnostics();
    logger.error("Read item failure diagnostics : {}", diagnostics);
  }
  return Mono.error(throwable);
}).subscribe();

Tanılamayı günlüğe kaydetme

Java V4 SDK'sı v4.43.0 ve üzeri sürümleri, belirli ölçütleri karşılıyorsa tüm istekler veya hatalar için Cosmos Tanılama'nın otomatik olarak günlüğe kaydedilmesini destekler. Uygulama geliştiricileri gecikme süresi (nokta (oluşturma, okuma, değiştirme, yükseltme, düzeltme eki uygulama) veya nokta dışı işlemler (sorgu, değişiklik akışı, toplu ve toplu işlem) için eşikler tanımlayabilir, ücret ve yük boyutu isteyebilir. İstekler bu tanımlı eşikleri aşarsa, bu istekler için cosmos tanılaması otomatik olarak gönderilir.

Varsayılan olarak, Java v4 SDK'sı bu tanılamaları otomatik olarak belirli bir biçimde günlüğe kaydeder. Ancak bu, arabirim uygulanarak CosmosDiagnosticsHandler ve kendi özel Tanılama İşleyiciniz sağlanarak değiştirilebilir.

Bunlar CosmosDiagnosticsThresholds ve CosmosDiagnosticsHandler daha sonra, eşitleme veya zaman uyumsuz istemci oluşturulurken içine CosmosClientBuilder geçirilmesi gereken nesnede CosmosClientTelemetryConfig kullanılabilir.

NOT: Bu tanılama eşikleri günlüğe kaydetme, izleme ve istemci telemetrisi gibi farklı tanılama türlerine uygulanır.

Aşağıdaki kod örnekleri tanılama eşiklerinin, özel tanılama günlükçüsunun nasıl tanımlanacağı ve istemci telemetri yapılandırması aracılığıyla bunların nasıl kullanılacağı gösterilmektedir:

//  Create diagnostics threshold
CosmosDiagnosticsThresholds cosmosDiagnosticsThresholds = new CosmosDiagnosticsThresholds();
//  These thresholds are for demo purposes
//  NOTE: Do not use the same thresholds for production
cosmosDiagnosticsThresholds.setPayloadSizeThreshold(100_00);
cosmosDiagnosticsThresholds.setPointOperationLatencyThreshold(Duration.ofSeconds(1));
cosmosDiagnosticsThresholds.setNonPointOperationLatencyThreshold(Duration.ofSeconds(5));
cosmosDiagnosticsThresholds.setRequestChargeThreshold(100f);

//  By default, DEFAULT_LOGGING_HANDLER can be used
CosmosDiagnosticsHandler cosmosDiagnosticsHandler = CosmosDiagnosticsHandler.DEFAULT_LOGGING_HANDLER;

//  App developers can also define their own diagnostics handler
cosmosDiagnosticsHandler = new CosmosDiagnosticsHandler() {
    @Override
    public void handleDiagnostics(CosmosDiagnosticsContext diagnosticsContext, Context traceContext) {
        logger.info("This is custom diagnostics handler: {}", diagnosticsContext.toJson());
    }
};

//  Create Client Telemetry Config
CosmosClientTelemetryConfig cosmosClientTelemetryConfig =
    new CosmosClientTelemetryConfig();
cosmosClientTelemetryConfig.diagnosticsHandler(cosmosDiagnosticsHandler);
cosmosClientTelemetryConfig.diagnosticsThresholds(cosmosDiagnosticsThresholds);

//  Create sync client
CosmosClient client = new CosmosClientBuilder()
    .endpoint(AccountSettings.HOST)
    .key(AccountSettings.MASTER_KEY)
    .clientTelemetryConfig(cosmosClientTelemetryConfig)
    .buildClient();

//  Create diagnostics threshold
CosmosDiagnosticsThresholds cosmosDiagnosticsThresholds = new CosmosDiagnosticsThresholds();
//  These thresholds are for demo purposes
//  NOTE: Do not use the same thresholds for production
cosmosDiagnosticsThresholds.setPayloadSizeThreshold(100_00);
cosmosDiagnosticsThresholds.setPointOperationLatencyThreshold(Duration.ofSeconds(1));
cosmosDiagnosticsThresholds.setNonPointOperationLatencyThreshold(Duration.ofSeconds(5));
cosmosDiagnosticsThresholds.setRequestChargeThreshold(100f);

//  By default, DEFAULT_LOGGING_HANDLER can be used
CosmosDiagnosticsHandler cosmosDiagnosticsHandler = CosmosDiagnosticsHandler.DEFAULT_LOGGING_HANDLER;

//  App developers can also define their own diagnostics handler
cosmosDiagnosticsHandler = new CosmosDiagnosticsHandler() {
    @Override
    public void handleDiagnostics(CosmosDiagnosticsContext diagnosticsContext, Context traceContext) {
        logger.info("This is custom diagnostics handler: {}", diagnosticsContext.toJson());
    }
};

//  Create Client Telemetry Config
CosmosClientTelemetryConfig cosmosClientTelemetryConfig =
    new CosmosClientTelemetryConfig();
cosmosClientTelemetryConfig.diagnosticsHandler(cosmosDiagnosticsHandler);
cosmosClientTelemetryConfig.diagnosticsThresholds(cosmosDiagnosticsThresholds);

//  Create async client
CosmosAsyncClient client = new CosmosClientBuilder()
    .endpoint(AccountSettings.HOST)
    .key(AccountSettings.MASTER_KEY)
    .clientTelemetryConfig(cosmosClientTelemetryConfig)
    .buildAsyncClient();

Tasarımı yeniden deneyin

Dayanıklı uygulamalar tasarlama ve SDK'nın yeniden deneme semantiğinin hangisi olduğunu öğrenmek için Azure Cosmos DB SDK'ları ile dayanıklı uygulamalar tasarlama kılavuzumuzu inceleyin.

Yaygın sorunlar ve geçici çözümler

Portal ölçümlerini denetleme

Portal ölçümlerini denetlemek, bunun istemci tarafı bir sorun olup olmadığını veya hizmetle ilgili bir sorun olup olmadığını belirlemenize yardımcı olur. Örneğin, ölçümler yüksek oranda sınırlı istekler (HTTP durum kodu 429) içeriyorsa ve bu da isteğin kısıtlandığı anlamına geliyorsa İstek oranı çok büyük bölümünü denetleyin.

Ağ sorunları, Netty okuma zaman aşımı hatası, düşük aktarım hızı, yüksek gecikme süresi

Genel öneriler

En iyi performans için:

• Uygulamanın Azure Cosmos DB hesabınızla aynı bölgede çalıştığından emin olun.
• Uygulamanın çalıştığı konakta CPU kullanımını denetleyin. CPU kullanımı yüzde 50 veya daha fazlaysa uygulamanızı daha yüksek yapılandırmaya sahip bir konakta çalıştırın. Veya yükü daha fazla makineye dağıtabilirsiniz.
  • Uygulamanızı Azure Kubernetes Service'te çalıştırıyorsanız, CPU kullanımını izlemek için Azure İzleyici'yi kullanabilirsiniz.

Bağlantı azaltma

Bağlantı azaltma, konak makinedeki bağlantı sınırı veya Azure SNAT (PAT) bağlantı noktası tükenmesi nedeniyle oluşabilir.

Konak makinede bağlantı sınırı

Red Hat gibi bazı Linux sistemlerinin toplam açık dosya sayısı üst sınırı vardır. Linux'taki yuvalar dosya olarak uygulandığından, bu sayı toplam bağlantı sayısını da sınırlar. Aşağıdaki komutu çalıştırın.

ulimit -a

"Nofile" olarak tanımlanan izin verilen en fazla açık dosya sayısı, bağlantı havuzu boyutunuzun en az iki katı olmalıdır. Daha fazla bilgi için bkz. Azure Cosmos DB Java SDK v4 performans ipuçları.

Azure SNAT (PAT) bağlantı noktası tükenmesi

Uygulamanız azure Sanal Makineler genel IP adresi olmadan dağıtılıyorsa, varsayılan olarak Azure SNAT bağlantı noktaları VM'nizin dışındaki herhangi bir uç noktaya bağlantı kurar. VM'den Azure Cosmos DB uç noktasına izin verilen bağlantı sayısı, Azure SNAT yapılandırmasıyla sınırlıdır.

Azure SNAT bağlantı noktaları yalnızca VM'nizin özel ip adresi olduğunda ve VM'den bir işlem genel IP adresine bağlanmaya çalıştığında kullanılır. Azure SNAT sınırlamasını önlemeye yönelik iki geçici çözüm vardır:

• Azure Cosmos DB hizmet uç noktanızı Azure Sanal Makineler sanal ağınızın alt ağına ekleyin. Daha fazla bilgi için bkz. Azure Sanal Ağ hizmet uç noktaları.

  Hizmet uç noktası etkinleştirildiğinde, istekler artık genel IP'den Azure Cosmos DB'ye gönderilmez. Bunun yerine sanal ağ ve alt ağ kimliği gönderilir. Bu değişiklik, yalnızca genel IP'lere izin veriliyorsa güvenlik duvarının düşmesine neden olabilir. Güvenlik duvarı kullanıyorsanız, hizmet uç noktasını etkinleştirdiğinizde Sanal Ağ ACL'leri kullanarak güvenlik duvarına bir alt ağ ekleyin.

• Azure VM'nize genel IP atayın.

Hizmete ulaşılamıyor - güvenlik duvarı

ConnectTimeoutException SDK'nın hizmete erişemezseniz gösterir. Doğrudan modu kullanırken aşağıdakine benzer bir hata alabilirsiniz:

GoneException{error=null, resourceAddress='https://cdb-ms-prod-westus-fd4.documents.azure.com:14940/apps/e41242a5-2d71-5acb-2e00-5e5f744b12de/services/d8aa21a5-340b-21d4-b1a2-4a5333e7ed8a/partitions/ed028254-b613-4c2a-bf3c-14bd5eb64500/replicas/131298754052060051p//', statusCode=410, message=Message: The requested resource is no longer available at the server., getCauseInfo=[class: class io.netty.channel.ConnectTimeoutException, message: connection timed out: cdb-ms-prod-westus-fd4.documents.azure.com/101.13.12.5:14940]

Uygulama makinenizde çalışan bir güvenlik duvarınız varsa, doğrudan mod tarafından kullanılan 10.000 ile 20.000 arasında bir bağlantı noktası aralığını açın. Ayrıca bir konak makinedeki Bağlantı sınırını da izleyin.

UnknownHostException

UnknownHostException, Java çerçevesinin etkilenen makinedeki Azure Cosmos DB uç noktası için DNS girişini çözümleyemiyor olduğu anlamına gelir. Makinenin DNS girdisini çözümleyebildiğini veya herhangi bir özel DNS çözümleme yazılımınız (VPN veya Proxy veya özel bir çözüm gibi) varsa, hatanın çözümlenemediğini iddia eden DNS uç noktası için doğru yapılandırmayı içerdiğinden emin olmanız gerekir. Hata sabitse, hatada açıklanan uç noktaya bir curl komut aracılığıyla makinenin DNS çözümlemesini doğrulayabilirsiniz.

HTTP proxy'si

HTTP ara sunucusu kullanıyorsanız, SDK'da ConnectionPolicyyapılandırılan bağlantı sayısını destekleyebilendiğinden emin olun. Aksi takdirde bağlantı sorunlarıyla karşılaşırsınız.

Geçersiz kodlama düzeni: Netty GÇ iş parçacığını engelleme

SDK, Azure Cosmos DB ile iletişim kurmak için Netty GÇ kitaplığını kullanır. SDK bir Zaman Uyumsuz API'ye sahiptir ve Netty'nin engelleyici olmayan GÇ API'lerini kullanır. SDK'nın GÇ çalışması GÇ Netty iş parçacıklarında gerçekleştirilir. GÇ Netty iş parçacığı sayısı, uygulama makinesinin CPU çekirdek sayısıyla aynı olacak şekilde yapılandırılır.

Netty GÇ iş parçacıklarının yalnızca engelleyici olmayan Netty GÇ işleri için kullanılması amaçlanıyor. SDK, Uygulamanın koduna Netty GÇ iş parçacıklarından birinde API çağırma sonucunu döndürür. Uygulama, Netty iş parçacığında sonuçları aldıktan sonra uzun süreli bir işlem gerçekleştirirse, SDK'nın iç GÇ işini gerçekleştirmek için yeterli GÇ iş parçacığı olmayabilir. Bu tür uygulama kodlaması düşük aktarım hızına, yüksek gecikme süresine ve io.netty.handler.timeout.ReadTimeoutException hatalara neden olabilir. Geçici çözüm, işlemin zaman aldığını bildiğinizde iş parçacığını değiştirmektir.

Örneğin, kapsayıcıya öğe ekleyen aşağıdaki kod parçacığına göz atın (veritabanını ve kapsayıcıyı ayarlama yönergeleri için buraya bakın.) Netty iş parçacığında birkaç milisaniyeden uzun süren uzun süreli çalışmalar gerçekleştirebilirsiniz. Öyleyse, sonunda GÇ işini işlemek için Netty GÇ iş parçacığının mevcut olmadığı bir duruma geçebilirsiniz. Sonuç olarak ReadTimeoutException hatası alırsınız.

Java SDK V4 (Maven com.azure::azure-cosmos) Async API

//Bad code with read timeout exception

int requestTimeoutInSeconds = 10;

/* ... */

AtomicInteger failureCount = new AtomicInteger();
// Max number of concurrent item inserts is # CPU cores + 1
Flux<Family> familyPub =
        Flux.just(Families.getAndersenFamilyItem(), Families.getAndersenFamilyItem(), Families.getJohnsonFamilyItem());
familyPub.flatMap(family -> {
    return container.createItem(family);
}).flatMap(r -> {
    try {
        // Time-consuming work is, for example,
        // writing to a file, computationally heavy work, or just sleep.
        // Basically, it's anything that takes more than a few milliseconds.
        // Doing such operations on the IO Netty thread
        // without a proper scheduler will cause problems.
        // The subscriber will get a ReadTimeoutException failure.
        TimeUnit.SECONDS.sleep(2 * requestTimeoutInSeconds);
    } catch (Exception e) {
    }
    return Mono.empty();
}).doOnError(Exception.class, exception -> {
    failureCount.incrementAndGet();
}).blockLast();
assert(failureCount.get() > 0);

Geçici çözüm, üzerinde zaman alan iş parçacığını değiştirmektir. Uygulamanız için zamanlayıcının tek bir örneğini tanımlayın.

Java SDK V4 (Maven com.azure::azure-cosmos) Async API

// Have a singleton instance of an executor and a scheduler.
ExecutorService ex  = Executors.newFixedThreadPool(30);
Scheduler customScheduler = Schedulers.fromExecutor(ex);

İşlem açısından ağır iş veya GÇ'yi engelleme gibi zaman alan işler yapmanız gerekebilir. Bu durumda iş parçacığını API'yi kullanarak sizin customScheduler tarafınızdan sağlanan bir çalışana .publishOn(customScheduler) geçirin.

Java SDK V4 (Maven com.azure::azure-cosmos) Async API

container.createItem(family)
        .publishOn(customScheduler) // Switches the thread.
        .subscribe(
                // ...
        );

kullanarak publishOn(customScheduler)Netty GÇ iş parçacığını serbest bırakır ve özel zamanlayıcı tarafından sağlanan kendi özel iş parçacığınıza geçersiniz. Bu değişiklik sorunu çözer. Artık başarısızlıkla sonuçlanmayacaksınız io.netty.handler.timeout.ReadTimeoutException .

İstek oranı fazla yüksek

Bu hata, sunucu tarafı hatasıdır. Sağlanan aktarım hızınızı kullandığınızı gösterir. Daha sonra yeniden deneyin. Bu hatayı sık sık alırsanız, koleksiyon aktarım hızındaki artışı göz önünde bulundurun.

• getRetryAfterInMilliseconds aralıklarında geri alma uygulama

  Performans testi sırasında, az sayıda istek azaltılana kadar yükü artırmanız gerekir. Kısıtlanırsa, istemci uygulamanın sunucu tarafından belirtilen yeniden deneme aralığı için geri çekilmesi gerekir. Geri alma işlemine saygı duymanız, yeniden denemeler arasında beklemeye en az zaman harcamanızı sağlar.

Java SDK Reaktif Zincirinden hata işleme

Azure Cosmos DB Java SDK'sından hata işleme, istemcinin uygulama mantığı söz konusu olduğunda önemlidir. Farklı senaryolarda kullanılabilecek reaktör çekirdeği çerçevesi tarafından sağlanan farklı hata işleme mekanizmaları vardır. Müşterilerin bu hata işleme işleçlerini ayrıntılı olarak anlamasını ve yeniden deneme mantığı senaryolarına en uygun olanları kullanmasını öneririz.

Azure Cosmos DB Öykünücüsü'ne bağlanma hatası

Azure Cosmos DB Öykünücüsü HTTPS sertifikası otomatik olarak imzalanır. SDK'nın öykünücüyle çalışması için öykünücü sertifikasını bir Java TrustStore'na aktarın. Daha fazla bilgi için bkz . Azure Cosmos DB Öykünücüsü sertifikalarını dışarı aktarma.

Bağımlılık Çakışması Sorunları

Azure Cosmos DB Java SDK'sı birçok bağımlılığı çeker; genel olarak konuşursak, proje bağımlılık ağacınız Azure Cosmos DB Java SDK'sının bağımlı olduğu bir yapıtın eski bir sürümünü içeriyorsa, bu durum uygulamanızı çalıştırdığınızda beklenmeyen hatalar oluşturulmasına neden olabilir. Uygulamanızın neden beklenmedik bir şekilde bir özel durum oluşturduğunu ayıklarsanız, bağımlılık ağacınızın azure Cosmos DB Java SDK bağımlılıklarından birinin veya daha fazlasının eski bir sürümünü yanlışlıkla çekmediğini bir kez daha kontrol etmek iyi bir fikirdir.

Bu tür bir sorunun geçici çözümü, proje bağımlılıklarınızdan hangilerinin eski sürümü getirdiğini belirlemek ve bu eski sürümdeki geçişli bağımlılığı dışlamak ve Azure Cosmos DB Java SDK'sının daha yeni sürümü getirmesine izin vermektir.

Proje bağımlılıklarınızdan hangilerinin Azure Cosmos DB Java SDK'sının bağımlı olduğu bir şeyin eski bir sürümünü getirdiğini belirlemek için proje pom.xml dosyanızda aşağıdaki komutu çalıştırın:

mvn dependency:tree

Daha fazla bilgi için maven bağımlılık ağacı kılavuzuna bakın.

Projenizin hangi bağımlılığının eski bir sürüme bağlı olduğunu bildiğinizde, pom dosyanızdaki bu lib'e bağımlılığı değiştirebilir ve geçişli bağımlılığı hariç tutabilirsiniz. Aşağıdaki örneği izleyerek (reactor-core'un güncel olmayan bağımlılık olduğu varsayılır):

<dependency>
  <groupId>${groupid-of-lib-which-brings-in-reactor}</groupId>
  <artifactId>${artifactId-of-lib-which-brings-in-reactor}</artifactId>
  <version>${version-of-lib-which-brings-in-reactor}</version>
  <exclusions>
    <exclusion>
      <groupId>io.projectreactor</groupId>
      <artifactId>reactor-core</artifactId>
    </exclusion>
  </exclusions>
</dependency>

Daha fazla bilgi için geçişli bağımlılıkları dışlama kılavuzuna bakın.

İstemci SDK günlüğünü etkinleştirme

Azure Cosmos DB Java SDK v4, log4j ve logback gibi popüler günlük çerçevelerinde oturum açmayı destekleyen günlüğe kaydetme cephesi olarak SLF4j kullanır.

Örneğin günlük çerçevesi olarak log4j kullanmak istiyorsanız Java sınıf yolunuzda aşağıdaki kitaplıkları ekleyin.

<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-log4j12</artifactId>
  <version>${slf4j.version}</version>
</dependency>
<dependency>
  <groupId>log4j</groupId>
  <artifactId>log4j</artifactId>
  <version>${log4j.version}</version>
</dependency>

Ayrıca log4j yapılandırması da ekleyin.

# this is a sample log4j configuration

# Set root logger level to INFO and its only appender to A1.
log4j.rootLogger=INFO, A1

log4j.category.com.azure.cosmos=INFO
#log4j.category.io.netty=OFF
#log4j.category.io.projectreactor=OFF
# A1 is set to be a ConsoleAppender.
log4j.appender.A1=org.apache.log4j.ConsoleAppender

# A1 uses PatternLayout.
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%d %5X{pid} [%t] %-5p %c - %m%n

Daha fazla bilgi için sfl4j günlüğe kaydetme kılavuzuna bakın.

İşletim sistemi ağ istatistikleri

ve CLOSE_WAITgibi ESTABLISHED durumlarda kaç bağlantı olduğunu öğrenmek için netstat komutunu çalıştırın.

Linux'ta aşağıdaki komutu çalıştırabilirsiniz.

netstat -nap

Windows'da, aynı komutu farklı bağımsız değişken bayraklarıyla çalıştırabilirsiniz:

netstat -abn

Sonucu yalnızca Azure Cosmos DB uç noktasına yönelik bağlantılara göre filtreleyin.

Durumdaki Azure Cosmos DB uç noktasına ESTABLISHED bağlantı sayısı, yapılandırılan bağlantı havuzu boyutunuzdan büyük olamaz.

Azure Cosmos DB uç noktasına yapılan birçok bağlantı şu durumda CLOSE_WAIT olabilir. 1000'den fazla olabilir. Yüksek olan bir sayı, bağlantıların hızlı bir şekilde kurulduğunu ve kesildiğini gösterir. Bu durum sorunlara neden olabilir. Daha fazla bilgi için Yaygın sorunlar ve geçici çözümler bölümüne bakın.

Sık karşılaşılan sorgu sorunları

Sorgu ölçümleri , sorgunun çoğu zaman nereye harcandığını belirlemeye yardımcı olur. Sorgu ölçümlerinden, arka uçta ve istemcide ne kadar harcandığını görebilirsiniz. Sorgu performansı kılavuzu hakkında daha fazla bilgi edinin.

Sonraki adımlar

• Java SDK v4 için performans yönergeleri hakkında bilgi edinin
• Java SDK v4 için en iyi yöntemler hakkında bilgi edinin