Dokumentacja danych monitorowania usługi Azure Managed Redis

  • Dotyczy: ✅ Azure Managed Redis

Ten artykuł zawiera wszystkie informacje referencyjne dotyczące monitorowania tej usługi.

Wskaźniki

W tej sekcji wymieniono wszystkie automatycznie zebrane metryki platformy dla tej usługi. Te metryki są również częścią globalnej listy wszystkich metryk platformy obsługiwanych w usłudze Azure Monitor.

Aby uzyskać informacje na temat przechowywania metryk, zobacz Przegląd metryk usługi Azure Monitor.

Aby uzyskać więcej informacji na temat obsługiwanych metryk dla usługi Microsoft.Cache/redisEnterprise, zobacz następującą sekcję.

Obsługiwane metryki dla microsoft.cache/redisEnterprise

W poniższej tabeli wymieniono metryki dostępne dla typu zasobu Microsoft.Cache/redisEnterprise.

  • Wszystkie kolumny mogą nie być obecne w każdej tabeli.
  • Niektóre kolumny mogą wykraczać poza obszar wyświetlania strony. Wybierz pozycję Rozwiń tabelę , aby wyświetlić wszystkie dostępne kolumny.

Nagłówki tabel

  • Kategoria — grupa metryk lub klasyfikacja.
  • Metryka — nazwa metryki, jak jest wyświetlana w portalu Azure.
  • Nazwa w interfejsie REST API — nazwa metryki używana w interfejsie REST API.
  • Jednostka — jednostka miary.
  • Agregacja — domyślny typ agregacji. Prawidłowe wartości: Średnia (średnia), Minimalna (Minimalna), Maksymalna (Maksymalna), Łączna (Suma), Liczba.
  • Wymiary - Wymiary dostępne dla tej metryki.
  • Ziarna czasu - Interwały, w których próbkowana jest metryka. Na przykład, PT1M oznacza, że metryka jest próbkowana co minutę, PT30M co 30 minut, PT1H co godzinę, i tak dalej.
  • DS Eksportowanie — określa, czy metryka może być eksportowana do dzienników usługi Azure Monitor za pośrednictwem ustawień diagnostycznych. Aby uzyskać informacje na temat eksportowania metryk, zobacz Tworzenie ustawień diagnostycznych w usłudze Azure Monitor.
Wskaźnik Nazwa w interfejsie API REST Zaawansowane metryki platformy Jednostka Agregacja Wymiary Granulki czasu DS Eksport
Trafienia cache’u

Liczba pomyślnych wyszukiwań kluczy. Aby uzyskać więcej informacji, zobacz https://aka.ms/redis/enterprise/metrics.		 cachehits Nie. Liczba Suma (Całkowita) <żadne> PT1M Tak
Opóźnienie pamięci cache μs (wersja zapoznawcza)

Opóźnienie dostępu do pamięci podręcznej w mikrosekundach. Aby uzyskać więcej informacji, zobacz https://aka.ms/redis/enterprise/metrics.		 cacheLatency Nie. Liczba Średnia InstanceId PT1M Tak
Błędy pamięci podręcznej

Liczba nieudanych wyszukiwań kluczy. Aby uzyskać więcej informacji, zobacz https://aka.ms/redis/enterprise/metrics.		 cachemisses Nie. Liczba Suma (Całkowita) <żadne> PT1M Tak
Odczyt z pamięci podręcznej

Ilość danych odczytanych z pamięci podręcznej w megabajtach na sekundę (MB/s). Aby uzyskać więcej informacji, zobacz https://aka.ms/redis/enterprise/metrics.		 cacheRead Nie. Bajty na sekundę Maksimum InstanceId PT1M Tak
Zapis do pamięci podręcznej

Ilość danych zapisywanych w pamięci podręcznej w megabajtach na sekundę (MB/s). Aby uzyskać więcej informacji, zobacz https://aka.ms/redis/enterprise/metrics.		 cacheWrite Nie. Bajty na sekundę Maksimum InstanceId PT1M Tak
Połączoni klienci

Liczba połączeń klienta z pamięcią podręczną. Aby uzyskać więcej informacji, zobacz https://aka.ms/redis/enterprise/metrics.		 connectedclients Nie. Liczba Maksimum InstanceId PT1M Tak
Usunięte klucze

Liczba elementów usuniętych z pamięci podręcznej. Aby uzyskać więcej informacji, zobacz https://aka.ms/redis/enterprise/metrics.		 evictedkeys Nie. Liczba Suma (Całkowita) <żadne> PT1M Tak
Wygasłe klucze

Liczba elementów, które wygasły z pamięci podręcznej. Aby uzyskać więcej informacji, zobacz https://aka.ms/redis/enterprise/metrics.		 expiredkeys Nie. Liczba Suma (Całkowita) <żadne> PT1M Tak
Replikacja geograficzna w dobrej kondycji

Kondycja replikacji geograficznej w aktywnej grupie replikacji geograficznej. Wartość 0 reprezentuje złą kondycję, a 1 reprezentuje wartość W dobrej kondycji. Aby uzyskać więcej informacji, zobacz https://aka.ms/redis/enterprise/metrics.		 geoReplicationHealthy Nie. Liczba Maksimum <żadne> PT1M Tak
Pobiera

Liczba operacji pobierania z pamięci podręcznej. Aby uzyskać więcej informacji, zobacz https://aka.ms/redis/enterprise/metrics.		 getcommands Nie. Liczba Suma (Całkowita) <żadne> PT1M Tak
Operacje na sekundę

Liczba natychmiastowych operacji wykonywanych na sekundę w pamięci podręcznej. Aby uzyskać więcej informacji, zobacz https://aka.ms/redis/enterprise/metrics.		 operationsPerSecond Nie. Liczba Maksimum <żadne> PT1M Tak
Procesor

Wykorzystanie CPU serwera Azure Redis Cache wyrażone jako procent. Aby uzyskać więcej informacji, zobacz https://aka.ms/redis/enterprise/metrics.		 percentProcessorTime Nie. Procent Maksimum InstanceId PT1M Tak
Ładowanie serwera

Procent cykli, w których serwer Redis jest zajęty przetwarzaniem i nie czeka bezczynnie na komunikaty. Aby uzyskać więcej informacji, zobacz https://aka.ms/redis/enterprise/metrics.		 serverLoad Nie. Procent Maksimum <żadne> PT1M Tak
Ustawia

Liczba ustawionych operacji w pamięci podręcznej. Aby uzyskać więcej informacji, zobacz https://aka.ms/redis/enterprise/metrics.		 setcommands Nie. Liczba Suma (Całkowita) <żadne> PT1M Tak
Łączna liczba operacji

Łączna liczba poleceń przetwarzanych przez serwer pamięci podręcznej. Aby uzyskać więcej informacji, zobacz https://aka.ms/redis/enterprise/metrics.		 totalcommandsprocessed Nie. Liczba Suma (Całkowita) <żadne> PT1M Tak
Łączna liczba kluczy

Łączna liczba elementów w pamięci podręcznej. Aby uzyskać więcej informacji, zobacz https://aka.ms/redis/enterprise/metrics.		 totalkeys Nie. Liczba Maksimum <żadne> PT1M Tak
Używana pamięć

Ilość pamięci podręcznej używanej dla par klucz/wartość w pamięci podręcznej w MB. Aby uzyskać więcej informacji, zobacz https://aka.ms/redis/enterprise/metrics.		 usedmemory Nie. Bajty Maksimum <żadne> PT1M Tak
Procent użycia pamięci

Procent pamięci podręcznej używanej dla par klucz-wartość. Aby uzyskać więcej informacji, zobacz https://aka.ms/redis/enterprise/metrics.		 usedmemorypercentage Nie. Procent Maksimum <żadne> PT1M Tak

Szczegółowe informacje o metrykach usługi Azure Managed Redis

Poniższe sekcje zawierają więcej informacji i wskazówek interpretacyjnych dotyczących obsługiwanych metryk Azure Monitor dla Microsoft. Cache/redisEnterprise. Pełną listę metryk z jednostkami i typami agregacji można znaleźć w tabeli Obsługiwane metryki .

Szczegóły dotyczące wskaźników na poziomie klastrów

Poniższa tabela zawiera podstawową metrykę źródłową Redis V1 Prometheus oraz dodatkowe wskazówki interpretacyjne dla każdej metryki na poziomie klastra. Definicje metryk źródłowych można znaleźć w referencji do metryk Redis Enterprise Prometheus v1.

Wskaźnik Źródło i przypisy
Opóźnienie pamięci podręcznej Średnie opóźnienie żądań obsługiwanych przez punkty końcowe w węźle pamięci podręcznej w określonym interwale raportowania. Ta metryka jest mierzona w milisekundach i pochodzi z metryki node_avg_latency V1 Prometeus. Ta metryka jest zgłaszana tylko wtedy, gdy w pamięci podręcznej jest aktywny ruch.
Trafienia pamięci podręcznej Szybkość udanych wyszukiwań kluczy, wyrażona jako liczba odsłon na sekundę. Pochodzi z metryki bdb_read_hits V1 Prometheus. To jest metryka wskaźnikowa; jego jednostka Azure Monitor wyświetla się jako Count, ale wartość to szybkość na sekundę.
Chybienia w pamięci podręcznej Szybkość nieudanych wyszukiwań kluczy, wyrażona jako błędy na sekundę. Pochodzi z metryki bdb_read_misses_max V1 Prometheus. To jest metryka wskaźnikowa; jego jednostka Azure Monitor wyświetla się jako Count, ale wartość to szybkość na sekundę. Błędy pamięci podręcznej nie muszą oznaczać problemu z pamięcią podręczną. Na przykład w przypadku korzystania ze wzorca programowania z odkładaniem do pamięci podręcznej aplikacja wygląda najpierw w pamięci podręcznej dla elementu. Jeśli element nie istnieje (chybienie pamięci podręcznej), element zostanie pobrany z bazy danych i dodany do pamięci podręcznej do następnego czasu. Błędy pamięci podręcznej są normalnym zachowaniem wzorca programowania z odkładaniem do pamięci podręcznej. Jeśli liczba chybień pamięci podręcznej jest wyższa niż oczekiwano, sprawdź logikę aplikacji, która wypełnia i odczytuje z pamięci podręcznej. Jeśli elementy są eksmitowane z pamięci podręcznej ze względu na wykorzystanie pamięci, może wystąpić pewne błędy pamięci podręcznej, ale lepszą metryką do monitorowania ciśnienia pamięci będzie Used Memory or Evicted Keys.
Odczyt pamięci podręcznej Reprezentuje szybkość przychodzącego ruchu sieciowego do węzła pamięci podręcznej w bajtach na sekundę. Ta wartość pochodzi z metryki node_ingress_bytes_max V1 Prometeus. Jeśli chcesz skonfigurować alerty dotyczące limitów przepustowości sieci po stronie serwera, utwórz je przy użyciu tego licznika odczytu pamięci podręcznej. Zobacz tę tabelę , aby zapoznać się z obserwowanymi limitami przepustowości dla różnych warstw cenowych i rozmiarów pamięci podręcznej. Jest to metryka szybkości, wyrażona jako bajty na sekundę.
Zapis w pamięci podręcznej Reprezentuje szybkość ruchu sieciowego wychodzącego z węzła cache w bajtach na sekundę. Ta wartość pochodzi z metryki node_egress_bytes_max V1 Prometeus. Jest to metryka szybkości, wyrażona jako bajty na sekundę.
Połączeni klienci Pochodzi z metryki node_conns V1 Prometheus, która liczy klientów podłączonych do punktów końcowych na węźle. Po osiągnięciu limitu połączenia późniejsze próby nawiązania połączenia z pamięcią podręczną kończą się niepowodzeniem. Nawet jeśli nie ma aktywnych aplikacji klienckich, nadal może istnieć kilka wystąpień połączonych klientów z powodu wewnętrznych procesów i połączeń.
CPU Wyprowadzony z metryki node_cpu_idle V1 Prometheus, która reprezentuje średnią część czasu bezczynności CPU (wartość od 0 do 1, pomnożoną przez 100, aby wyrazić procent) w tym przedziale i jest odwrócona, aby odzwierciedlić czas zajętości CPU. Metryka procesora CPU obejmuje procesy w tle, takie jak oprogramowanie chroniące przed złośliwym oprogramowaniem, które nie są ściśle procesami serwera Redis, dzięki czemu czasami może ona gwałtownie zwiększać się niezależnie od obciążenia usługi Redis. Zalecamy użycie tej metryki nad obciążeniem serwera do monitorowania, ponieważ obsługuje przechodzenie do szczegółów na poziomie wystąpienia przez podzielenie identyfikatora wystąpienia, zapewniając większą szczegółowość działania węzła pod presją.
Wykluczone klucze Tempo kluczowych eksmisji, wyrażone jako liczba eksmisji na sekundę. Pochodzi z metryki bdb_evicted_objects V1 Prometheus. To jest metryka wskaźnikowa; jego jednostka Azure Monitor wyświetla się jako Count, ale wartość to szybkość na sekundę.
Wygasłe klucze Szybkość wygaśnięcia kluczy, wyrażona jako wygaśnięcia na sekundę. Pochodzi z metryki bdb_expired_objects V1 Prometheus. To jest metryka wskaźnikowa; jego jednostka Azure Monitor wyświetla się jako Count, ale wartość to szybkość na sekundę.
Replikacja geograficzna w dobrej kondycji Wskazuje kondycję połączenia replikacji geograficznej między pamięciami podręcznymi w aktywnej grupie Geo-Replication. Metryka zgłasza jedną z dwóch wartości:

0 - odłączenie/niezdrowe
1 - zdrowe

Metryka jest dostępna w pamięciach podręcznych zoptymalizowanych pod kątem pamięci, zrównoważonych i zoptymalizowanych pod kątem obliczeń z włączoną replikacją geograficzną. Wartość 0 nie oznacza utraty danych w repliki geograficznej. Oznacza to tylko, że połączenie między serwerem geograficznym podstawowym a pomocniczym obszarem geograficznym jest w złej kondycji.

Ta metryka może wskazywać stan replikacji rozłączonej/złej kondycji z kilku powodów, w tym: comiesięczne stosowanie poprawek, aktualizacje systemu operacyjnego hosta, błędna konfiguracja sieci lub nieudana aprowizacja łącza replikacji geograficznej. Usługa Azure Managed Redis okresowo poprawia pamięci podręczne przy użyciu najnowszych funkcji i ulepszeń platformy. Podczas tych aktualizacji każdy węzeł pamięci podręcznej jest przełączony w tryb offline, co tymczasowo wyłącza łącze replikacji geograficznej. Jeśli link replikacji geograficznej jest w złej kondycji, sprawdź, czy był spowodowany przez zdarzenie stosowania poprawek w podstawowej lub pomocniczej pamięci podręcznej geograficznej, korzystając z menu Diagnozowanie i rozwiązywanie problemów z menu Zasób w portalu. W zależności od ilości danych w pamięci podręcznej przestój podczas stosowania poprawek może potrwać od kilku minut do godziny. Jeśli link replikacji geograficznej jest w złej kondycji przez ponad godzinę, prześlij wniosek o pomoc techniczną.
Pobrania Szybkość operacji odczytu, wyrażona jako operacje na sekundę. Pochodzi z metryki bdb_read_req V1 Prometheus, która reprezentuje szybkość wszystkich żądań odczytu w bazie danych i jest równoważna sumie trafień i nietrafień cache. To jest metryka wskaźnikowa; jego jednostka Azure Monitor wyświetla się jako Count, ale wartość to szybkość na sekundę.
Operacje na sekundę Łączna liczba żądań obsługiwanych na sekundę przez wszystkie fragmenty pamięci podręcznej w określonym interwale raportowania. Ta wartość pochodzi z metryki bdb_instantaneous_ops_per_sec V1 Prometeus. Jest to metryka szybkości, wyrażona jako operacje na sekundę.
Obciążenie serwera Metryka obciążenia serwera odzwierciedla własną ocenę całkowitego obciążenia przez serwer Redis. Podobnie jak metryka CPU , pochodzi ona z metryki node_cpu_idle V1 Prometheus, odwrócona, aby odzwierciedlić czas zajętości serwera. Różnica polega na tym, że obciążenie serwera mierzy się na poziomie klastra, podczas gdy CPU na poziomie węzła (instancji).

Obciążenie serwera osiągające 100 nie oznacza koniecznie, że CPU jest wyczerpane w pamięci podręcznej; może wskazywać, że procesor na jednym z węzłów zbliża się do nasycenia. Z tego powodu należy ocenić zarówno obciążenie serwera , jak i metrykę CPU na węzeł, zanim podejmie decyzje dotyczące wydajności, takie jak skalowanie lub partycjonowanie danych na wielu cache'ach.

Utrzymujące się wysokie obciążenie serwera może mieć kilka skutków ubocznych, w tym zwiększone opóźnienia po stronie serwera oraz wyjątki związane z wyjątkiem czasowym.

Uwaga: Dla pamięci podręcznej Azure Managed Redis, obciążenie serwera czasem odzwierciedla wartości powyżej 100. Zalecamy stosowanie metryki CPU lub jednoczesną ocenę obu metryk przed podjęciem decyzji opartych na wydajności.
Zestawy Szybkość operacji zapisu, wyrażona jako operacje na sekundę. Pochodzi z metryki bdb_write_req V1 Prometheus, która reprezentuje wskaźnik wszystkich żądań zapisu w bazie danych. To jest metryka wskaźnikowa; jego jednostka Azure Monitor wyświetla się jako Count, ale wartość to szybkość na sekundę.
Łączna liczba kluczy Pochodzi z metryki bdb_no_of_keys V1 Prometheus.

Ważne: Ze względu na ograniczenie w systemie metryk dla pamięci podręcznych z włączonym klastrowaniem, Total Keys zwraca maksymalną liczbę kluczy odłamka, które miały maksymalną liczbę kluczy w okresie raportowania.

Aby zobaczyć dokładne liczby kluczy na odłamek pamięci podręcznej, użyj metryki Shard Key Count na poziomie odłamka pociętej według wymiaru Slots (Range) .
Łączna liczba operacji Szybkość wszystkich operacji, wyrażona jako operacje na sekundę. Pochodzi z metryki bdb_total_req V1 Prometheus. To jest metryka wskaźnikowa; jego jednostka Azure Monitor wyświetla się jako Count, ale wartość to szybkość na sekundę.
Użyta pamięć Pochodzi z metryki bdb_used_memory V1 Prometheus. W pamięciach podręcznych zoptymalizowanych pod kątem pamięci flash ta wartość obejmuje zarówno pamięć RAM, jak i pamięć flash. Ta wartość nie zawiera fragmentacji.

Po włączeniu wysokiej dostępności wartość Używana pamięć zawiera pamięć w węzłach podstawowych i replik. Może to sprawić, że metryka będzie wyświetlana dwa razy większa niż oczekiwano.
Procentowe użycie pamięci Obliczane jako stosunek do bdb_used_memorybdb_memory_limit z metryk Redis Enterprise V1 Prometheus. Ta wartość nie zawiera fragmentacji.

Metryki na poziomie odłamków

Azure Managed Redis udostępnia teraz metryki na poziomie shardów, które zapewniają wgląd w zachowanie pamięci podręcznej dla każdego sharda. Metryki te pochodzą z punktów końcowych Redis V2 Prometheus (redis_server_* metryki).

Wymiary

Każda metryka na poziomie odłamka obsługuje następujące wymiary:

Wymiar Nazwa w interfejsie API REST Description
Instance ID InstanceId Identyfikuje konkretny węzeł Redis (instancję VM) w klastrze. Wykorzystaj ten wymiar do wyizolowania zachowania pojedynczego węzła i identyfikacji nierównowagi obciążenia między węzłami.
Slots (Range) Slots Identyfikuje odłamek według zakresu slotów mieszającego. Wykorzystaj ten wymiar do wykrywania nierównowagi pamięci lub nierównomiernego rozkładu kluczy między odłamkami.
Shard ID Shard Unikalny identyfikator odłamka z użyciem interfejsu Redis shard. Użyj tego wymiaru równolegleSlots (Range), aby powiązać dane Azure Monitor z identyfikatorami odłamków na poziomie Redis.
Shard Role Role Rola węzła: primary lub replica. Użyj tego wymiaru, aby porównać metryki między węzłami pierwotnymi a replikami na tym samym odłamku.

Note

Gdy dzielisz lub filtrujesz według wymiaru przez Azure Monitor REST API, użyj wartości w kolumnie Nazwa w REST API zamiast nazwy portalu wyświetlanej. Nazwy metryk i wymiarów w Azure Monitor REST API są niewrażliwe na wielka litera. Na przykład zapytanie percentProcessorTime, PercentProcessorTime, lub PERCENTPROCESSORTIME wszystkie zwracają te same wyniki. To samo dotyczy wartości filtrów wymiarowych: instanceId eq '*' i INSTANCEID eq '*' są równoważne. Obudowa użyta w tym artykule jest wyłącznie konwencją dla poprawności czytelności.

Ważna

Te metryki są publikowane na poziomie odłamków. Gdy zapytanie jest wykonywane bez podziału przez wymiar, Azure Monitor agreguje wartości ze wszystkich odłamków, używając domyślnego typu agregacji. Dla większości wskaźników takie agregowanie krzyżowych fragmentów nie generuje znaczących sum na poziomie całego klastra. Zawsze dziel się na wymiar, Slots (Range) aby dokładnie analizować pojedynczy fragment.

Szczegóły dotyczące metryk na poziomie odłamków

Poniższa tabela przedstawia podstawową metrykę źródłową Redis V2 Prometheus oraz dodatkowe wskazówki interpretacyjne dla każdego metryki na poziomie shard. Definicje metryk źródłowych można znaleźć w odniesieniu do metryk Redis Enterprise Prometheus v2.

Wskaźnik Szczegóły
Używana pamięć odłamków (bajty) (Podgląd) Pamięć używana przez ten fragment, w bajtach. W SKU obsługujących flash obejmuje to zarówno DRAM, jak i flash. Pochodzi z metryki redis_server_used_memory Prometeusza z Redis V2.
Klienci pamięci odłamków normalnie (bajty) (Podgląd) Aktualna pamięć używana do buforów wejściowych i wyjściowych klientów niereplikowanych. Pochodzi z metryki redis_server_mem_clients_normal Prometeusza z Redis V2.
Replika klientów pamięci odłamkowej (bajty) (Podgląd) Aktualna pamięć używana do buforów wejściowych i wyjściowych replik. Pochodzi z metryki redis_server_mem_clients_slaves Prometeusza z Redis V2.
Liczba kluczy odłamków (Zapowiedź) Całkowita liczba kluczy. Pochodzi z metryki redis_server_db_keys Prometeusza z Redis V2.
Link do replikacji odłamków (Podgląd) Wskazuje, czy replika jest połączona ze swoim głównym elementem. Pochodzi z metryki redis_server_master_link_status Redis V2 Prometheus, która jest emitowana tylko przez odłamki replik, ponieważ tylko replika ma połączenie replikacyjne z powrotem do swojego głównego obiektu, na którym można raportować.

Metryki Big Keys

Poniższe metryki śledzą rozkład rozmiaru klucza na odłamkach, pomagając zidentyfikować duże klucze, zanim spowodują problemy z wydajnością.

Note

Metryki dużych kluczy nie są jeszcze wspierane w aktywnych geo-replikowanych cache. Wsparcie dla tych metryk dla geo-replikowanych pamięci podręcznych pojawi się w późniejszym terminie.

Klucze łańcuchowe (według rozmiaru pamięci)

Wskaźnik Szczegóły
Rozmiary ciągów odłamków poniżej 128 MB (Podgląd) Liczba kluczy na tym fragmencie o rozmiarze pamięci poniżej 128 MB.

Zestaw kluczy (według liczby elementów)

Wskaźnik Szczegóły
Shard zestawia elementy poniżej 1M Elements (Podgląd) Liczba kluczy na tym odłamku z mniej niż milionem elementów.
Zestawy odłamków Elementy od 1M do 8M (Podgląd) Liczba kluczy na tym fragmencie zawiera od 1 miliona do 8 milionów elementów.
Zestawy odłamków Elementy powyżej 8M Elements (Zapowiedź) Liczba zestawów kluczy na tym fragmencie z ponad 8 milionami elementów.

Klucze posortowanych zbiorów (według liczby elementów)

Wskaźnik Szczegóły
Sortowanie fragmentów zestawia elementy poniżej 1M Elements (podgląd) Liczba posortowanych kluczy zestawu na tym fragmencie z mniej niż 1 milionem elementów.
Sortowane odłamki zestawiają elementy od 1M do 8M Elementy (Podgląd) Liczba posortowanych kluczy zestawów na tym fragmencie – od 1 miliona do 8 milionów elementów.
Fragmenty sortowane Zestawy Przedmioty powyżej 8M Elements (Podgląd) Liczba posortowanych kluczy zestawu na tym fragmencie z ponad 8 milionami elementów.

Klucze skrótu (według liczby pól)

Wskaźnik Szczegóły
Hashowanie elementów odłamków poniżej 1M (podgląd) Liczba kluczy skrótu na tym fragmencie z mniej niż milionem pól.
Hashowanie odłamków elementów od 1M do 8M (Podgląd) Liczba kluczy skrótów na tym fragmencie – od 1 miliona do 8 milionów pól.
Hashowanie elementów odłamków powyżej 8M elementów (podgląd) Liczba kluczy skrótu na tym fragmencie z ponad 8 milionami pól.

Klucze listy (według liczby elementów)

Wskaźnik Szczegóły
Odłamek wymienia elementy poniżej 1M (podgląd) Liczba kluczy listy na tym fragmencie zawiera mniej niż 1 milion elementów.
Odłamek wymienia elementy od 1M do 8M (Podgląd) Liczba kluczy listy na tym fragmencie zawiera od 1 miliona do 8 milionów elementów.
Odłamek wymienia elementy powyżej 8 milionów elementów (podgląd) Liczba kluczy listy na tym fragmencie z ponad 8 milionami elementów.

Rozwiązywanie problemów za pomocą metryk na poziomie odłamków

Poniższe sekcje opisują typowe scenariusze na poziomie odłamków i sposoby ich diagnozowania:

Awaria łącza replikacyjnego występuje, gdy odłamek pierwotny nie jest w stanie nawiązać połączenia replikacyjnego z powiązanym fragmentem repliki, przez co replika nie może już pozostać w synchronizacji z odłamkiem głównym. Ta metryka jest emitowana tylko przez fragmenty replik, ponieważ tylko replika ma połączenie replikacyjne do swojego głównego do raportowania i raportuje, czy replika jest obecnie połączona z podstawą. Długotrwała awaria usuwa ochronę wysokiej dostępności dla dotkniętego fragmentu i zwiększa ryzyko utraty danych, jeśli awaria nastąpi przed odzyskaniem łącza. Mimo to łącze replikacyjne może być tymczasowo niezdrowe podczas failoveru, migracji shardów, skalowania lub wydarzeń konserwacyjnych, więc ten wskaźnik może być szumowy. Dlatego ważne jest, gdy ustawiasz alerty na tym wskaźniku, aby ostrzegać tylko przez dłuższy czas, z wieloma punktami wskazującymi na spadek zdrowia.

Podejście do wykrywania:

  1. Link do replikacji rozdzielonych fragmentów przez Slots (Range). Wartość 0 na dowolnym odłamku oznacza, że połączenie replikacyjne odłamku jest nieaktywne; 1 oznacza, że jest na górze.
  2. Traktuj łącze, które utrzymuje się na 0 przez dłuższy czas (na przykład 120 minut lub dłużej), jako trwałą awarię, a nie jako przejściowe ponowne połączenie. Krótkie spadki mogą wystąpić podczas normalnej konserwacji lub awarii.
  3. Porównaj z replikami Shard Memory Used i Shard Memory Clients na tym samym odłamku, aby sprawdzić, czy awaria towarzyszy presji zasobów na podstawowym odłamku.

Typowe przyczyny:

  • Duże klucze to główna przyczyna. Duże klucze i kolekcje sprawiają, że synchronizacja jest wolna i kosztowna, co może opóźnić replikę i ostatecznie doprowadzić łącze replikacyjne do niezdrowego stanu.
  • Zakłócenia sieci lub wysokie opóźnienia między węzłem głównym a repliką.
  • Główny odłamek jest przeciążony (wysoka przepustowość zapisu lub nasycenie CPU), więc nie może obsłużyć replikacji.
  • Presja pamięci na podstawową uniemożliwiała operacje w tle potrzebne do synchronizacji repliki.
  • Powtarzające się cykle pełnej synchronizacji spowodowane przez wolną replikę pozostającą w tyle za zaległością replikacji.

Korygowanie:

  • Zmniejsz ciągłą przepustowość zapisu lub skaluj pamięć podręczną, aby zwiększyć pojemność, tak aby główny fragment był mniej przesycony.
  • Zidentyfikuj i rozbij duże klucze, co sprawia, że replikacja i resynchronizacja są droższe na dotkniętym odłamku.
  • Jeśli łącze pozostaje niedostępne po zmniejszeniu obciążenia, otwórz zapytanie wsparcia, aby zespół platformy mógł sprawdzić stan węzła i wewnętrzne zaległości replikacyjne.

Identyfikacja nierównowagi pamięci

Nierównowaga pamięci występuje, gdy niektóre odłamki zużywają znacznie więcej pamięci niż inne, co może prowadzić do eksmisji na konkretnych odłamkach, podczas gdy inne mają dużo wolnej pamięci.

Podejście do wykrywania:

  1. Podzielona pamięć odłamkowa używana (bajty) przez Slots (Range). Maksymalny stosunek maksymalny/minimalny większy niż 2x wskazuje na znaczącą nierównowagę.
  2. Skoreluj z liczbą kluczy odłamków , Slots (Range) aby określić, czy nierównowaga wynika z większej liczby kluczy czy większych wartości na konkretnych odłamkach.

Typowe przyczyny:

  • Niewłaściwe użycie hashtagów polegające na koncentrowaniu dużej liczby kluczy na tym samym odłamku.
  • Duże klucze: niewielka liczba bardzo dużych struktur danych na konkretnym fragmencie.
  • Niespójne polityki TTL powodujące rozbieżności w wykorzystaniu pamięci w czasie.

Korygowanie:

  • Rozdzielając klucze poprzez przeglądanie i zmianę użycia hashtagów.
  • Zidentyfikuj i rozbijaj duże klucze, korzystając z metryk Big Keys, aby zlokalizować dotknięte odłamki.
  • Przejrzyj polityki TTL dla kluczy na odłamkach o dużej ilości pamięci.

Diagnozowanie wzrostu buforu replikacyjnego

Każdy główny fragment utrzymuje bufor wyjściowy dla swojej repliki, który kolejkuje zapisy, których replika jeszcze nie zastosowała. Gdy replika nie nadąża, ten bufor rośnie i zużywa pamięć na odłamku. Jeśli rośnie bez ograniczeń, replika może zostać odłączona i zmuszona do pełnej resynchronizacji, co jest kosztowne i może prowadzić do powtarzających się cykli resynchronizacji lub nawet do niezdrowej synchronizacji replikacji. Ponieważ każdy fragment ma własny bufor repliki, wzrost często jest ograniczony do konkretnych odłamków.

Podejście do wykrywania:

  1. Podziel replikę klientów pamięci odłamków (bajty) i Slots (Range) szukaj utrzymującego się trendu wzrostowego na każdym odłamku powyżej 15 minut lub dłużej, zamiast jednego wysokiego odczytu. Sygnalizacja to stały wzrost, a nie chwilowy skok.
  2. Skoreluj z Shard Replication Link Up na tym samym fragmencie. Wzrost bufora kończący się spadkiem łącza do 0 wskazuje, że replika została odłączona i prawdopodobna jest resynchronizacja.
  3. Porównaj z aktywnością zapisu (Sety i Operacje Całkowite na poziomie klastra), aby sprawdzić, czy write burst napędza wzrost.

Typowe przyczyny:

  • Długotrwały zapis powoduje zmiany szybciej, niż replika może je zastosować.
  • Powolna replika, w walce o zasoby, zostająca w tyle za oficjalnymi wyborami.
  • Powtarzające się pełne pętle resynchronizacji, które wielokrotnie napełniają bufor.
  • Duże klucze, które sprawiają, że pojedyncze replikowane operacje są duże i wolniejsze w transferze.

Korygowanie:

  • Wygładz lub ogranicz bursty zapisu, jeśli to możliwe, albo skaluj pamięć podręczną, aby zwiększyć pojemność.
  • Zidentyfikuj i rozbij duże klucze, aby zmniejszyć rozmiar pojedynczych replikowanych operacji.
  • Jeśli bufor będzie się powiększał, a replika wielokrotnie się rozłączała, otwórz żądanie wsparcia, aby zespół platformy mógł przejrzeć stan repliki i rozmiarowanie bufora, które są zarządzane przez usługę.

Zarządzanie dużymi kluczami

Duże klucze i duże kolekcje zwiększają obciążenie pamięci na pojedyncze odłamki i sprawiają, że replikacja staje się droższa. Aby uzyskać najlepszą wydajność ścieżek danych, należy utrzymać rozmiary poszczególnych kluczy/wartości poniżej 512 KB. To jest rekomendacja dotycząca wydajności, a nie egzekwowany limit.

Duże klucze dotyczą tylko granic — nie są zalecane ani zalecane rozmiary kluczy. Na przykład bucket Shard Strings Sizes Smaller 128 MB po prostu liczy klucze łańcuchów mniejsze niż 128 MB, więc możesz obserwować wzrost; to nie znaczy, że Azure zaleca przechowywanie kluczy w okolicach 128 MB. Podobnie kubełki z liczbą elementów (1M, 8M) są progiem wykrywania powiększonych kolekcji, a nie docelowymi rozmiarami. Zawsze celuj w najmniejszy praktyczny rozmiar klucza (najlepiej poniżej 512 KB) i traktuj każdy klucz, który wchodzi do wyższego kubełka, jako coś do zbadania.

Metryki Big Keys łączą klucze do zakresów rozmiarów, dzięki czemu można zauważyć wzrost zanim spowoduje problemy. W przypadku kolekcji pierwszy kubełek reprezentuje klucze mieszczące się w normalnym zakresie, więc traktuj wszystkie klucze pojawiające się w drugim lub trzecim kubełku za warte zbadania. W przypadku kluczy ciągów znaków jest widoczny tylko kubełek poniżej 128 MB, więc traktuj każdą wartość ciągu znaków zbliżającą się lub przekraczającą 128 MB jako powód.

Dlaczego duże klawisze mają znaczenie:

  • Koszt replikacji: Duże klucze sprawiają, że zarówno replikacja o wysokiej dostępności, jak i aktywna replikacja geo-replikacja (CRDB) są droższe. Efekt nie jest natychmiastowy; zazwyczaj pojawia się podczas pełnej synchronizacji wywołanej późniejszą awarią lub ponownym połączeniem.
  • Wpływ na pamięć podręczną Flash Optimized na pamięć podręczną: W SKU Flash Optimized jeśli klucz jest duży, pozostaje w pamięci RAM i nie jest przeładowywany do flasha, co może powodować błędy wyczerpania pamięci (OOM) nawet jeśli wolne miejsce na dysku flash pozostaje dostępne. Wartości, które są bardzo małe względem nazwy klucza, również słabo się rozładowują.

Podejście do wykrywania:

  1. Podziel każdą metrykę dużych kluczy według Slots (Range) tego, które odłamki zawierają duże klucze.
  2. W przypadku kolekcji skup się na drugim i trzecim kubełku z liczbą elementów (od 1M do 8M i powyżej 8M). Trzeci kubełek reprezentuje najbardziej ekstremalne tonacje. Dla łańcuchów znaków jest widoczny tylko rozmiar łańcuchów odłamków poniżej 128 MB , więc traktuj wartość ciągu ciągu powyżej 128 MB jako problem.
  3. Porównaj z pamięcią odłamków używaną do Slots (Range) potwierdzenia, czy duże klucze powodują nierównowagę pamięci na konkretnych odłamkach.

Korygowanie:

  • Zmniejsz rozmiar wartości w kierunku pierwszego kubełka lub 512 KB jako najlepszą praktykę. Typowe strategie obejmują dzielenie lub dzielenie dużej wartości na wiele kluczy oraz kompresję lub przeformatowanie wartości serializowanej.
  • Dla kolekcji (listy, zbiory, posortowane zbiory i skróty), które rosną nieograniczonie w czasie, podziel kolekcję na wiele kluczy lub okresowo ją przycinaj.
  • Celem jest zmniejszenie rozmiaru pojedynczego klucza i kolekcji. Najlepsza metoda zależy od projektu aplikacji i typu danych.

Zalecenia dotyczące alertów dla metryk na poziomie odłamków

Scenario Wskaźnik Warunek Okno oceny Severity
Awaria łącza replikacyjnego Link Link Shard Replication, podzielony przez Slots (Range) Minimum = 0 na dowolnym odłamku 120+ min High
Nierównowaga pamięci Używana pamięć odłamkowa (bajty), podzielona przez Slots (Range) Maksymalny stosunek do min między slotami > 2x 5 minut Medium
Wzrost bufora replikacyjnego Replika klientów pamięci na fragmentach (bajty), podzielona przez Slots (Range) Stały wzrost w ciągu 15 minut 15 minut Medium
Bardzo duże zbiory (trzeci kubeł) Dowolna metryka zbioru "Powyżej 8M Elements", podzielona przez Slots (Range) Wartość > 0 na dowolnym odłamku ponad 10 minut High
Duże zbiory (drugi kubeł) Dowolna metryka zbioru "1M do 8M Elements" podzielona przez Slots (Range) Liczba kubeł, gdy udział łącznych kluczy tego typu przekracza 10% ponad 10 minut Medium
Duże klawisze strunowe Rozmiary stringów odłamków poniżej 128 MB (jedyny odsłonięty bucket stringów) Każda wartość ciągu ciągu na poziomie lub powyżej 128 MB budzi niepokój; obserwuj liczbę kluczy poniżej 128 MB rosnącą w kierunku progu ponad 10 minut Informacyjny

Note

Alert o awarii łącza replikacyjnego może być autorowany bezpośrednio jako alert metryki Azure Monitor, ponieważ metryka agreguje się jako minimum, więc wartość 0 nad oknem oznacza, że link był w pewnym momencie niedostępny. Alert bardzo dużych kolekcji (trzeci kubeł) może być również tworzony natywnie, ponieważ testuje pojedynczą metrykę względem stałego progu (wartości większej niż 0). Pozostałe scenariusze nie mogą być natywnie ocenione przez alerty metryk Azure Monitor: alerty metryk nie mogą porównywać wartości między wartościami wymiarów (np. maksymalny stosunek Slots (Range)do minimum), nie mogą obliczyć stosunku między dwoma metrykami (na przykład drugi kubełek liczony jako udział łącznych kluczy tego typu) i nie wykrywają utrzymującego się trendu wzrostowego. Sprawdzają jedynie, czy dana wartość przekracza ustalony próg w danym momencie. Utwórz je jako alerty wyszukiwania logów nad eksportowanymi metrykami: wyślij metryki do przestrzeni roboczej Log Analytics za pomocą ustawień diagnostycznych, a następnie oblicz maksymalny stosunek do minimum, udział w kubełkach lub trend w zapytaniu Kusto (KQL). Metryki pierwszego kubeczka nie potrzebują powiadomień; Obserwuj ich trendy w czasie.

Dzienniki zasobów

W tej sekcji wymieniono typy dzienników zasobów, które można zbierać dla tej usługi. Sekcja pobiera z listy wszystkich typów kategorii dzienników zasobów obsługiwanych w usłudze Azure Monitor.

Obsługiwane dzienniki zasobów dla usługi Microsoft.Cache/redisEnterprise/databases

Kategoria Koszty eksportu Tabela logów Obsługuje podstawowy plan dziennikowania Obsługuje transformacje podczas wprowadzania danych Przykłady zapytań
Zdarzenia połączenia (nowe połączenie/uwierzytelnianie/rozłączenie) Tak REDConnectionEvents

Rejestruje zdarzenia połączenia, gdy klient nawiązuje połączenie z bazą danych przedsiębiorstwa redis.

 Tak Tak Zapytania

Tabele dzienników usługi Azure Monitor

W tej sekcji wymieniono tabele dzienników usługi Azure Monitor dotyczące tej usługi, które są dostępne do wykonywania zapytań przez usługę Log Analytics przy użyciu zapytań Kusto. Tabele zawierają dane dziennika zasobów i prawdopodobnie więcej w zależności od tego, co jest zbierane i kierowane do nich.

Zarządzany Redis w Azure

Microsoft.Cache/redisEnterprise

Dziennik aktywności

Tabela połączona zawiera listę operacji, które można zarejestrować w dzienniku aktywności dla tej usługi. Te operacje są podzbiorem wszystkich możliwych operacji dostawcy zasobów w dzienniku aktywności.

Aby uzyskać więcej informacji na temat schematu wpisów dziennika aktywności, zobacz Schemat dziennika aktywności.

Treści powiązane

  • Last updated on