Rozwiązywanie problemów podczas korzystania z zestawu Java SDK usługi Azure Cosmos DB w wersji 4 z interfejsem API dla kont NoSQL

  • Artykuł

DOTYCZY: NoSQL

Ważne

W tym artykule opisano rozwiązywanie problemów tylko z zestawem Java SDK usługi Azure Cosmos DB w wersji 4. Aby uzyskać więcej informacji, zobacz informacje o wersji zestawu Java SDK usługi Azure Cosmos DB w wersji 4, repozytorium Maven i porady dotyczące wydajności. Jeśli obecnie używasz starszej wersji niż 4, zobacz przewodnik Migrate to Azure Cosmos DB Java SDK v4 (Migrowanie do zestawu Java SDK usługi Azure Cosmos DB w wersji 4), aby uzyskać pomoc dotyczącą uaktualniania do wersji 4 .

W tym artykule opisano typowe problemy, obejścia, kroki diagnostyczne i narzędzia podczas korzystania z zestawu Java SDK usługi Azure Cosmos DB w wersji 4 z kontami noSQL w usłudze Azure Cosmos DB. Zestaw Java SDK usługi Azure Cosmos DB w wersji 4 zapewnia logiczną reprezentację po stronie klienta w celu uzyskania dostępu do usługi Azure Cosmos DB for NoSQL. W tym artykule opisano narzędzia i podejścia pomocne w przypadku napotkania jakichkolwiek problemów.

Zacznij od tej listy:

  • Zapoznaj się z sekcją Typowe problemy i obejścia w tym artykule.
  • Zapoznaj się z zestawem JAVA SDK w centralnym repozytorium usługi Azure Cosmos DB, które jest dostępne w usłudze GitHub. Zawiera sekcję problemów, która jest aktywnie monitorowana. Sprawdź, czy wystąpił już podobny problem z obejściem. Jedną z przydatnych wskazówek jest filtrowanie problemów według tagu *cosmos:v4-item* .
  • Zapoznaj się z poradami dotyczącymi wydajności zestawu Java SDK usługi Azure Cosmos DB w wersji 4 i postępuj zgodnie z sugerowaną praktyką.
  • Przeczytaj resztę tego artykułu, jeśli nie znajdziesz rozwiązania. Następnie zgłoś problem z usługą GitHub. Jeśli istnieje opcja dodawania tagów do problemu z usługą *cosmos:v4-item* GitHub, dodaj tag.

Przechwytywanie diagnostyki

Odpowiedzi bazy danych, kontenera, elementu i zapytań w zestawie Java V4 SDK mają właściwość Diagnostics (Diagnostyka). Ta właściwość rejestruje wszystkie informacje związane z pojedynczym żądaniem, w tym w przypadku ponownych prób lub błędów przejściowych.

Diagnostyka jest zwracana jako ciąg. Ciąg zmienia się wraz z każdą wersją w miarę ulepszania w celu lepszego rozwiązywania problemów z różnymi scenariuszami. W przypadku każdej wersji zestawu SDK ciąg może spowodować przerwanie jego formatu. Nie analizuj ciągu, aby uniknąć zmian powodujących niezgodność.

Poniższy przykładowy kod pokazuje, jak odczytywać dzienniki diagnostyczne przy użyciu zestawu SDK języka Java w wersji 4:

Ważne

Zalecamy zweryfikowanie minimalnej zalecanej wersji zestawu JAVA V4 SDK i upewnienie się, że używasz tej wersji lub nowszej. W tym miejscu możesz sprawdzić zalecaną wersję.

Operacje bazy danych

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

Operacje kontenera

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

Operacje na elementach

// 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);

Operacje zapytań

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());
});

Wyjątki usługi Azure Cosmos DB

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);
}

Rejestrowanie diagnostyki

Zestaw Java V4 SDK w wersji 4.43.0 lub nowszej obsługuje automatyczne rejestrowanie diagnostyki cosmos dla wszystkich żądań lub błędów, jeśli spełniają określone kryteria. Deweloperzy aplikacji mogą definiować progi opóźnienia (dla punktu (tworzenie, odczytywanie, zastępowanie, upsert, patch) lub operacje niepunktowe (zapytanie, zestawienie zmian, zbiorcze i wsadowe) oraz rozmiar opłaty i ładunku żądania. Jeśli żądania przekraczają te zdefiniowane progi, diagnostyka cosmos dla tych żądań będzie emitowana automatycznie.

Domyślnie zestaw JAVA v4 SDK rejestruje te dane diagnostyczne automatycznie w określonym formacie. Można to jednak zmienić, implementując CosmosDiagnosticsHandler interfejs i udostępniając własną niestandardową procedurę obsługi diagnostycznej.

Można je CosmosDiagnosticsThresholds następnie użyć w CosmosClientTelemetryConfig obiekcie, który należy przekazać CosmosClientBuilder podczas tworzenia synchronizacji lub klienta asynchronicznego.CosmosDiagnosticsHandler

UWAGA: Te progi diagnostyczne są stosowane w różnych typach diagnostyki, w tym rejestrowania, śledzenia i telemetrii klienta.

Poniższe przykłady kodu pokazują, jak zdefiniować progi diagnostyczne, niestandardowy rejestrator diagnostyki i używać ich za pośrednictwem konfiguracji telemetrii klienta:

Definiowanie niestandardowych progów diagnostyki

//  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);

Definiowanie niestandardowej procedury obsługi diagnostycznej

//  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());
    }
};

Definiowanie obiektu CosmosClientTelemetryConfig

//  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();

Ponawianie próby projektu

Zapoznaj się z naszym przewodnikiem dotyczącym projektowania odpornych aplikacji przy użyciu zestawów SDK usługi Azure Cosmos DB, aby uzyskać wskazówki dotyczące projektowania odpornych aplikacji i dowiedz się, które są semantyka ponawiania próby zestawu SDK.

Typowe problemy i ich rozwiązania

Sprawdzanie metryk portalu

Sprawdzenie metryk portalu pomoże określić, czy jest to problem po stronie klienta, czy występuje problem z usługą. Jeśli na przykład metryki zawierają wysoką częstotliwość żądań ograniczonych szybkością (kod stanu HTTP 429), co oznacza, że żądanie jest ograniczane, sprawdź zbyt dużą sekcję Częstotliwość żądań.

Problemy z siecią, błąd limitu czasu odczytu netty, niska przepływność, duże opóźnienie

Sugestie ogólne

Aby uzyskać najlepszą wydajność:

  • Upewnij się, że aplikacja działa w tym samym regionie co konto usługi Azure Cosmos DB.
  • Sprawdź użycie procesora CPU na hoście, na którym działa aplikacja. Jeśli użycie procesora CPU wynosi co najmniej 50 procent, uruchom aplikację na hoście z wyższą konfiguracją. Możesz też rozłożyć obciążenie na więcej maszyn.

Ograniczanie przepustowości Połączenie ion

Połączenie ograniczanie przepustowości może wystąpić z powodu limitu połączenia na maszynie hosta lub wyczerpaniu portów SNAT (PAT).

limit Połączenie ion na maszynie hosta

Niektóre systemy Linux, takie jak Red Hat, mają górny limit całkowitej liczby otwartych plików. Gniazda w systemie Linux są implementowane jako pliki, więc ta liczba ogranicza łączną liczbę połączeń. Uruchom następujące polecenie:

ulimit -a

Liczba maksymalnych dozwolonych otwartych plików, które są identyfikowane jako "nofile", musi być co najmniej dwukrotnie większy niż rozmiar puli połączeń. Aby uzyskać więcej informacji, zobacz Porady dotyczące wydajności zestawu Java SDK usługi Azure Cosmos DB w wersji 4.

Wyczerpanie portów SNAT (PAT) platformy Azure

Jeśli aplikacja jest wdrażana na maszynach wirtualnych platformy Azure bez publicznego adresu IP, domyślnie porty SNAT platformy Azure nawiązują połączenia z dowolnym punktem końcowym poza maszyną wirtualną. Liczba połączeń dozwolonych z maszyny wirtualnej do punktu końcowego usługi Azure Cosmos DB jest ograniczona przez konfigurację protokołu SNAT platformy Azure.

Porty SNAT platformy Azure są używane tylko wtedy, gdy maszyna wirtualna ma prywatny adres IP i proces z maszyny wirtualnej próbuje nawiązać połączenie z publicznym adresem IP. Istnieją dwa obejścia, aby uniknąć ograniczenia usługi Azure SNAT:

  • Dodaj punkt końcowy usługi Azure Cosmos DB do podsieci sieci wirtualnej usługi Azure Virtual Machines. Aby uzyskać więcej informacji, zobacz Punkty końcowe usługi Azure Virtual Network.

    Po włączeniu punktu końcowego usługi żądania nie są już wysyłane z publicznego adresu IP do usługi Azure Cosmos DB. Zamiast tego są wysyłane tożsamości sieci wirtualnej i podsieci. Ta zmiana może spowodować porzucenie zapory, jeśli dozwolone są tylko publiczne adresy IP. Jeśli używasz zapory, po włączeniu punktu końcowego usługi dodaj podsieć do zapory przy użyciu list ACL sieci wirtualnej.

  • Przypisz publiczny adres IP do maszyny wirtualnej platformy Azure.

Nie można nawiązać połączenia z usługą — zapora

ConnectTimeoutException wskazuje, że zestaw SDK nie może nawiązać połączenia z usługą. Podczas korzystania z trybu bezpośredniego może wystąpić błąd podobny do następującego:

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]

Jeśli na maszynie aplikacji działa zapora, otwórz zakres portów od 10 000 do 20 000, które są używane przez tryb bezpośredni. Należy również przestrzegać limitu Połączenie ion na maszynie hosta.

UnknownHostException

UnknownHostException oznacza, że platforma Java nie może rozpoznać wpisu DNS dla punktu końcowego usługi Azure Cosmos DB na maszynie, której dotyczy problem. Należy sprawdzić, czy maszyna może rozpoznać wpis DNS lub jeśli masz niestandardowe oprogramowanie do rozpoznawania nazw DNS (takie jak sieć VPN lub serwer proxy lub rozwiązanie niestandardowe), upewnij się, że zawiera właściwą konfigurację punktu końcowego DNS, którego błąd nie może zostać rozwiązany. Jeśli błąd jest stały, możesz zweryfikować rozpoznawanie nazw DNS maszyny za pomocą curl polecenia do punktu końcowego opisanego w błędzie.

Serwer proxy HTTP

Jeśli używasz serwera proxy HTTP, upewnij się, że może obsługiwać liczbę połączeń skonfigurowanych w zestawie SDK ConnectionPolicy. W przeciwnym razie występują problemy z połączeniem.

Nieprawidłowy wzorzec kodowania: Blokowanie wątku we/wy netty

Zestaw SDK używa biblioteki we/wy netty do komunikowania się z usługą Azure Cosmos DB. Zestaw SDK ma asynchroniczny interfejs API i używa nieblokujących interfejsów API we/wy platformy Netty. Praca we/wy zestawu SDK jest wykonywana w wątkach IO Netty. Liczba wątków netty we/wy jest skonfigurowana tak samo jak liczba rdzeni procesora CPU maszyny aplikacji.

Wątki we/wy Netty mają być używane tylko w przypadku pracy we/wy netty nieblokujących. Zestaw SDK zwraca wynik wywołania interfejsu API dla jednego z wątków operacji we/wy netty do kodu aplikacji. Jeśli aplikacja wykonuje długotrwałą operację po otrzymaniu wyników w wątku Netty, zestaw SDK może nie mieć wystarczającej liczby wątków we/wy, aby wykonać wewnętrzną pracę we/wy. Takie kodowanie aplikacji może spowodować niską przepływność, duże opóźnienia i io.netty.handler.timeout.ReadTimeoutException błędy. Obejście polega na przełączeniu wątku, gdy wiadomo, że operacja zajmuje trochę czasu.

Zapoznaj się na przykład z poniższym fragmentem kodu, który dodaje elementy do kontenera (zapoznaj się z poniższymi wskazówkami dotyczącymi konfigurowania bazy danych i kontenera). Możesz wykonać długotrwałą pracę, która zajmuje więcej niż kilka milisekund w wątku Netty. Jeśli tak, w końcu możesz dostać się do stanu, w którym żaden wątek we/wy netty nie jest obecny do przetwarzania operacji we/wy. W rezultacie otrzymasz błąd ReadTimeoutException.

Zestaw JAVA SDK w wersji 4 (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);

Obejście polega na zmianie wątku, na którym wykonujesz pracę, która zajmuje trochę czasu. Zdefiniuj pojedyncze wystąpienie harmonogramu dla aplikacji.

Zestaw JAVA SDK w wersji 4 (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);

Może być konieczne wykonywanie pracy, która wymaga czasu, na przykład obliczeniowej ciężkiej pracy lub blokowania operacji we/wy. W takim przypadku przełącz wątek do procesu roboczego dostarczonego przez użytkownika customScheduler przy użyciu interfejsu .publishOn(customScheduler) API.

Zestaw JAVA SDK w wersji 4 (Maven com.azure::azure-cosmos) Async API

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

Za pomocą polecenia publishOn(customScheduler)wydasz wątek Netty we/wy i przełączysz się do własnego niestandardowego wątku udostępnionego przez niestandardowy harmonogram. Ta modyfikacja rozwiązuje problem. Nie otrzymasz już błędu io.netty.handler.timeout.ReadTimeoutException .

Zbyt duża liczba żądań

Ten błąd jest awarią po stronie serwera. Wskazuje ona, że zużyliśmy aprowizowaną przepływność. Ponów próbę później. Jeśli ten błąd występuje często, rozważ zwiększenie przepływności kolekcji.

  • Implementowanie wycofywania w interwałach getRetryAfterInMilliseconds

    Podczas testowania wydajnościowego należy zwiększyć obciążenie, dopóki nie zostanie ograniczona niewielka liczba żądań. Jeśli zostanie ograniczona, aplikacja kliencka powinna wycofać się z interwału ponawiania prób określonego przez serwer. Przestrzeganie wycofywania gwarantuje, że spędzasz minimalny czas oczekiwania między ponawianiem prób.

Obsługa błędów z reaktywnego łańcucha zestawu JAVA SDK

Obsługa błędów z zestawu Java SDK usługi Azure Cosmos DB jest ważna, jeśli chodzi o logikę aplikacji klienta. Istnieją różne mechanizmy obsługi błędów zapewniane przez strukturę reaktora-rdzenia, które mogą być używane w różnych scenariuszach. Zalecamy klientom szczegółowe zrozumienie tych operatorów obsługi błędów i użycie tych, które najlepiej pasują do scenariuszy logiki ponawiania prób.

Ważne

Nie zalecamy używania onErrorContinue() operatora, ponieważ nie jest on obsługiwany we wszystkich scenariuszach. Należy pamiętać, że onErrorContinue() jest specjalistycznym operatorem, który może sprawić, że zachowanie reaktywnego łańcucha jest niejasne. Działa on na operatorach nadrzędnych, a nie podrzędnych, wymaga obsługi określonego operatora do działania, a zakres może łatwo propagować nadrzędny kod do kodu biblioteki, który nie przewidywał (co powoduje niezamierzone zachowanie). Aby uzyskać więcej informacji na temat tego operatora specjalnego, zapoznaj się z dokumentacjąonErrorContinue().

Niepowodzenie nawiązywania połączenia z emulatorem usługi Azure Cosmos DB

Certyfikat HTTPS emulatora usługi Azure Cosmos DB jest z podpisem własnym. Aby zestaw SDK działał z emulatorem, zaimportuj certyfikat emulatora do magazynu zaufania Java. Aby uzyskać więcej informacji, zobacz Eksportowanie certyfikatów emulatora usługi Azure Cosmos DB.

Problemy z konfliktem zależności

Zestaw Java SDK usługi Azure Cosmos DB ściąga wiele zależności; ogólnie rzecz biorąc, jeśli drzewo zależności projektu zawiera starszą wersję artefaktu, od którego zależy zestaw JAVA SDK usługi Azure Cosmos DB, może to spowodować nieoczekiwane błędy generowane podczas uruchamiania aplikacji. Jeśli debugujesz, dlaczego aplikacja nieoczekiwanie zgłasza wyjątek, warto dokładnie sprawdzić, czy drzewo zależności nie jest przypadkowo ściągane w starszej wersji co najmniej jednej zależności zestawu Java SDK usługi Azure Cosmos DB.

Obejściem takiego problemu jest zidentyfikowanie, które z zależności projektu wprowadza starą wersję i wyklucza zależność przechodnią od tej starszej wersji, oraz zezwalanie zestawowi SDK języka Java usługi Azure Cosmos DB na wprowadzenie nowszej wersji.

Aby określić, które zależności projektu zawierają starszą wersję elementu, od którego zależy zestaw Java SDK usługi Azure Cosmos DB, uruchom następujące polecenie względem pliku pom.xml projektu:

mvn dependency:tree

Aby uzyskać więcej informacji, zobacz przewodnik drzewa zależności maven.

Gdy wiesz, która zależność projektu zależy od starszej wersji, możesz zmodyfikować zależność od tej biblioteki w pliku pom i wykluczyć zależność przechodnią, postępując zgodnie z poniższym przykładem (w którym przyjęto założenie, że rdzeń reaktora jest nieaktualną zależnością):

<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>

Aby uzyskać więcej informacji, zobacz przewodnik po zależnościach przejściowych wykluczania.

Włączanie rejestrowania zestawu SDK klienta

Zestaw Java SDK usługi Azure Cosmos DB w wersji 4 używa SLF4j jako fasady rejestrowania, która obsługuje logowanie do popularnych struktur rejestrowania, takich jak log4j i logback.

Jeśli na przykład chcesz użyć log4j jako struktury rejestrowania, dodaj następujące biblioteki w ścieżce klas Języka Java.

<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>

Dodaj również konfigurację log4j.

# 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

Aby uzyskać więcej informacji, zobacz podręcznik rejestrowania sfl4j.

Statystyki sieci systemu operacyjnego

Uruchom polecenie netstat, aby uzyskać informacje o liczbie połączeń w stanach, takich jak ESTABLISHED i CLOSE_WAIT.

W systemie Linux możesz uruchomić następujące polecenie.

netstat -nap

W systemie Windows można uruchomić to samo polecenie z różnymi flagami argumentów:

netstat -abn

Filtruj wynik tylko do połączeń z punktem końcowym usługi Azure Cosmos DB.

Liczba połączeń z punktem końcowym usługi Azure Cosmos DB w ESTABLISHED stanie nie może być większa niż skonfigurowany rozmiar puli połączeń.

Wiele połączeń z punktem końcowym usługi Azure Cosmos DB może być w CLOSE_WAIT stanie . Może istnieć więcej niż 1000. Liczba, która wysoka wskazuje, że połączenia są ustanawiane i szybko się rozwiązywane. Ta sytuacja potencjalnie powoduje problemy. Aby uzyskać więcej informacji, zobacz sekcję Typowe problemy i obejścia .

Typowe problemy z zapytaniami

Metryki zapytań pomogą określić, gdzie zapytanie spędza większość czasu. Z metryk zapytania możesz zobaczyć, ile z niego jest wydawane na zapleczu a klientem. Dowiedz się więcej na temat przewodnika dotyczącego wydajności zapytań.

Następne kroki