Monitorowanie usługi Azure Cache for Redis

W tym artykule opisano:

• Typy danych monitorowania, które można zbierać dla tej usługi.
• Sposoby analizowania tych danych.

Uwaga

Jeśli znasz już tę usługę i/lub usługę Azure Monitor i chcesz wiedzieć, jak analizować dane monitorowania, zobacz sekcję Analizowanie pod koniec tego artykułu.

Jeśli masz krytyczne aplikacje i procesy biznesowe korzystające z zasobów platformy Azure, musisz monitorować i otrzymywać alerty dla systemu. Usługa Azure Monitor zbiera i agreguje metryki i dzienniki z każdego składnika systemu. Usługa Azure Monitor zapewnia wgląd w dostępność, wydajność i odporność oraz powiadamia o problemach. Do konfigurowania i wyświetlania danych monitorowania można użyć witryny Azure Portal, programu PowerShell, interfejsu wiersza polecenia platformy Azure, interfejsu API REST lub bibliotek klienckich.

• Aby uzyskać więcej informacji na temat usługi Azure Monitor, zobacz Omówienie usługi Azure Monitor.
• Aby uzyskać więcej informacji na temat ogólnego monitorowania zasobów platformy Azure, zobacz Monitorowanie zasobów platformy Azure za pomocą usługi Azure Monitor.

Wyniki analiz

Niektóre usługi na platformie Azure mają wbudowany pulpit nawigacyjny monitorowania w witrynie Azure Portal, który zapewnia punkt wyjścia do monitorowania usługi. Te pulpity nawigacyjne są nazywane szczegółowymi informacjami i można je znaleźć w centrum szczegółowych informacji usługi Azure Monitor w witrynie Azure Portal.

Szczegółowe informacje dotyczące usługi Azure Cache for Redis zapewniają następujące środowisko:

• Z perspektywy skali zasobów usługi Azure Cache for Redis w ramach subskrypcji. Można selektywnie określać zakres tylko dla subskrypcji i zasobów, które chcesz ocenić.
• Przechodzenie do szczegółów analizy zasobu usługi Azure Cache for Redis. Aby zdiagnozować problemy, możesz zobaczyć szczegółową analizę wykorzystania, awarii, pojemności i operacji lub wyświetlić szczegółowy widok odpowiednich informacji.
• Dostosowywanie oparte na szablonach skoroszytów usługi Azure Monitor. Możesz zmienić wyświetlane metryki i zmodyfikować lub ustawić progi zgodne z limitami. Możesz zapisać zmiany w skoroszycie niestandardowym, a następnie przypiąć wykresy skoroszytu do pulpitów nawigacyjnych platformy Azure.

Szczegółowe informacje dotyczące usługi Azure Cache for Redis nie wymagają włączenia ani skonfigurowania niczego. Informacje usługi Azure Cache for Redis są zbierane domyślnie i nie ma dodatkowych opłat za dostęp do szczegółowych informacji.

Aby dowiedzieć się, jak wyświetlać, konfigurować i dostosowywać szczegółowe informacje dla usługi Azure Cache for Redis, zobacz Azure Monitor insights for Azure Cache for Redis (Szczegółowe informacje o usłudze Azure Monitor dla usługi Azure Cache for Redis).

Typy zasobów

Platforma Azure używa koncepcji typów zasobów i identyfikatorów, aby zidentyfikować wszystko w subskrypcji. Typy zasobów są również częścią identyfikatorów zasobów dla każdego zasobu uruchomionego na platformie Azure. Na przykład jeden typ zasobu dla maszyny wirtualnej to Microsoft.Compute/virtualMachines. Aby uzyskać listę usług i skojarzonych z nimi typów zasobów, zobacz Dostawcy zasobów.

Usługa Azure Monitor podobnie organizuje podstawowe dane monitorowania w metryki i dzienniki na podstawie typów zasobów, nazywanych również przestrzeniami nazw. Różne metryki i dzienniki są dostępne dla różnych typów zasobów. Usługa może być skojarzona z więcej niż jednym typem zasobu.

Aby uzyskać więcej informacji na temat typów zasobów dla usługi Azure Cache for Redis, zobacz Azure Cache for Redis monitoring data reference (Dokumentacja danych monitorowania usługi Azure Cache for Redis).

Magazyn danych

W przypadku usługi Azure Monitor:

• Dane metryk są przechowywane w bazie danych metryk usługi Azure Monitor.
• Dane dziennika są przechowywane w magazynie dzienników usługi Azure Monitor. Log Analytics to narzędzie w witrynie Azure Portal, które może wykonywać zapytania dotyczące tego magazynu.
• Dziennik aktywności platformy Azure to oddzielny magazyn z własnym interfejsem w witrynie Azure Portal.

Opcjonalnie możesz kierować dane metryki i dziennika aktywności do magazynu dzienników usługi Azure Monitor. Następnie możesz użyć usługi Log Analytics, aby wykonać zapytanie o dane i skorelować je z innymi danymi dziennika.

Wiele usług może używać ustawień diagnostycznych do wysyłania danych metryk i dzienników do innych lokalizacji przechowywania poza usługą Azure Monitor. Przykłady obejmują usługę Azure Storage, hostowane systemy partnerskie i systemy partnerskie spoza platformy Azure przy użyciu usługi Event Hubs.

Aby uzyskać szczegółowe informacje na temat sposobu przechowywania danych przez usługę Azure Monitor, zobacz Azure Monitor data platformy.

Metryki platformy usługi Azure Monitor

Usługa Azure Monitor udostępnia metryki platformy dla większości usług. Te metryki to:

• Definiowane indywidualnie dla każdej przestrzeni nazw.
• Przechowywane w bazie danych metryk szeregów czasowych usługi Azure Monitor.
• Lekki i zdolny do obsługi alertów niemal w czasie rzeczywistym.
• Służy do śledzenia wydajności zasobu w czasie.

Kolekcja: usługa Azure Monitor automatycznie zbiera metryki platformy. Nie jest wymagana żadna konfiguracja.

Routing: możesz również kierować niektóre metryki platformy do dzienników usługi Azure Monitor/ usługi Log Analytics, aby móc wykonywać zapytania względem nich przy użyciu innych danych dziennika. Sprawdź ustawienie eksportu DS dla każdej metryki, aby sprawdzić, czy możesz użyć ustawienia diagnostycznego, aby kierować metrykę do dzienników usługi Azure Monitor/ usługi Log Analytics.

• Aby uzyskać więcej informacji, zobacz ustawienie diagnostyczne Metryki.
• Aby skonfigurować ustawienia diagnostyczne dla usługi, zobacz Tworzenie ustawień diagnostycznych w usłudze Azure Monitor.

Aby uzyskać listę wszystkich metryk, które można zebrać dla wszystkich zasobów w usłudze Azure Monitor, zobacz Obsługiwane metryki w usłudze Azure Monitor.

Aby uzyskać listę dostępnych metryk dla usługi Azure Cache for Redis, zobacz Dokumentacja danych monitorowania usługi Azure Cache for Redis.

Dzienniki zasobów usługi Azure Monitor

Dzienniki zasobów zapewniają wgląd w operacje wykonywane przez zasób platformy Azure. Dzienniki są generowane automatycznie, ale należy skierować je do dzienników usługi Azure Monitor, aby je zapisać lub wysłać do nich zapytanie. Dzienniki są zorganizowane w kategoriach. Dana przestrzeń nazw może mieć wiele kategorii dziennika zasobów.

Kolekcja: dzienniki zasobów nie są zbierane i przechowywane do momentu utworzenia ustawienia diagnostycznego i kierowania dzienników do co najmniej jednej lokalizacji. Podczas tworzenia ustawienia diagnostycznego należy określić kategorie dzienników, które mają być zbierane. Istnieje wiele sposobów tworzenia i konserwacji ustawień diagnostycznych, w tym witryny Azure Portal, programowo i choć usługi Azure Policy.

Routing: sugerowaną wartością domyślną jest kierowanie dzienników zasobów do dzienników usługi Azure Monitor, co umożliwia wykonywanie zapytań względem nich przy użyciu innych danych dziennika. Dostępne są również inne lokalizacje, takie jak Azure Storage, Azure Event Hubs i niektórzy partnerzy monitorowania firmy Microsoft. Aby uzyskać więcej informacji, zobacz Dzienniki zasobów platformy Azure i lokalizacje docelowe dziennika zasobów.

Aby uzyskać szczegółowe informacje na temat zbierania, przechowywania i routingu dzienników zasobów, zobacz Ustawienia diagnostyczne w usłudze Azure Monitor.

Aby uzyskać listę wszystkich dostępnych kategorii dzienników zasobów w usłudze Azure Monitor, zobacz Obsługiwane dzienniki zasobów w usłudze Azure Monitor.

Wszystkie dzienniki zasobów w usłudze Azure Monitor mają te same pola nagłówka, a następnie pola specyficzne dla usługi. Typowy schemat jest opisany w schemacie dziennika zasobów usługi Azure Monitor.

Aby uzyskać dostępne kategorie dzienników zasobów, skojarzone z nimi tabele usługi Log Analytics i schematy dzienników dla usługi Azure Cache for Redis, zobacz Azure Cache for Redis monitoring data reference (Dokumentacja danych monitorowania usługi Azure Cache for Redis).

Dzienniki zasobów usługi Azure Cache for Redis

W usłudze Azure Cache for Redis dostępne są dwie opcje rejestrowania:

• Metryki dzienników pamięci podręcznej ("AllMetrics") z usługi Azure Monitor
• Dzienniki połączeń rejestrujące połączenia z pamięcią podręczną na potrzeby zabezpieczeń i diagnostyki.

Metryki pamięci podręcznej

Usługa Azure Cache for Redis emituje wiele metryk, takich jak Server Load i Connections per Second które są przydatne do rejestrowania. Wybranie opcji AllMetrics umożliwia rejestrowanie tych i innych metryk pamięci podręcznej. Możesz skonfigurować czas przechowywania metryk.

Dzienniki połączeń

Usługa Azure Cache for Redis używa ustawień diagnostycznych platformy Azure do rejestrowania informacji o połączeniach klientów z pamięcią podręczną. Rejestrowanie i analizowanie tego ustawienia diagnostycznego pomaga zrozumieć, kto łączy się z pamięciami podręcznymi, i znaczniki czasu tych połączeń. Dane dziennika mogą służyć do identyfikowania zakresu naruszenia zabezpieczeń i do celów inspekcji zabezpieczeń.

Dzienniki połączeń mają nieco inne implementacje, zawartość i procedury konfiguracji dla różnych warstw usługi Azure Cache for Redis. Aby uzyskać szczegółowe informacje, zobacz Ustawienia diagnostyczne usługi Azure Monitor.

Dziennik aktywności platformy Azure

Dziennik aktywności zawiera zdarzenia na poziomie subskrypcji, które śledzą operacje dla każdego zasobu platformy Azure widoczne spoza tego zasobu; na przykład utworzenie nowego zasobu lub uruchomienie maszyny wirtualnej.

Kolekcja: zdarzenia dziennika aktywności są generowane automatycznie i zbierane w osobnym magazynie do wyświetlania w witrynie Azure Portal.

Routing: możesz wysyłać dane dziennika aktywności do dzienników usługi Azure Monitor, aby móc analizować je wraz z innymi danymi dziennika. Dostępne są również inne lokalizacje, takie jak Azure Storage, Azure Event Hubs i niektórzy partnerzy monitorowania firmy Microsoft. Aby uzyskać więcej informacji na temat kierowania dziennika aktywności, zobacz Omówienie dziennika aktywności platformy Azure.

Analizowanie danych monitorowania

Istnieje wiele narzędzi do analizowania danych monitorowania.

Narzędzia usługi Azure Monitor

Usługa Azure Monitor obsługuje następujące podstawowe narzędzia:

• Eksplorator metryk — narzędzie w witrynie Azure Portal, które umożliwia wyświetlanie i analizowanie metryk dla zasobów platformy Azure. Aby uzyskać więcej informacji, zobacz Analizowanie metryk za pomocą Eksploratora metryk usługi Azure Monitor.

• Log Analytics — narzędzie w witrynie Azure Portal, które umożliwia wykonywanie zapytań i analizowanie danych dzienników przy użyciu języka zapytań Kusto (KQL). Aby uzyskać więcej informacji, zobacz Rozpoczynanie pracy z zapytaniami dzienników w usłudze Azure Monitor.

• Dziennik aktywności, który zawiera interfejs użytkownika w witrynie Azure Portal do wyświetlania i podstawowych wyszukiwań. Aby przeprowadzić bardziej szczegółową analizę, musisz kierować dane do dzienników usługi Azure Monitor i uruchamiać bardziej złożone zapytania w usłudze Log Analytics.

Narzędzia, które umożliwiają bardziej złożoną wizualizację, obejmują:

• Pulpity nawigacyjne, które umożliwiają łączenie różnych rodzajów danych w jednym okienku w witrynie Azure Portal.
• Skoroszyty, dostosowywalne raporty, które można utworzyć w witrynie Azure Portal. Skoroszyty mogą zawierać tekst, metryki i zapytania dziennika.
• Grafana to otwarte narzędzie platformy, które wyróżnia się na operacyjnych pulpitach nawigacyjnych. Za pomocą narzędzia Grafana można tworzyć pulpity nawigacyjne zawierające dane z wielu źródeł innych niż usługa Azure Monitor.
• Power BI, usługa analizy biznesowej, która udostępnia interaktywne wizualizacje w różnych źródłach danych. Usługę Power BI można skonfigurować tak, aby automatycznie importować dane dziennika z usługi Azure Monitor, aby korzystać z tych wizualizacji.

Narzędzia eksportu usługi Azure Monitor

Dane z usługi Azure Monitor można pobrać do innych narzędzi przy użyciu następujących metod:

• Metryki: użyj interfejsu API REST dla metryk , aby wyodrębnić dane metryk z bazy danych metryk usługi Azure Monitor. Interfejs API obsługuje wyrażenia filtrów w celu uściślinia pobranych danych. Aby uzyskać więcej informacji, zobacz Dokumentacja interfejsu API REST usługi Azure Monitor.

• Dzienniki: użyj interfejsu API REST lub skojarzonych bibliotek klienckich.

• Inną opcją jest eksportowanie danych obszaru roboczego.

Aby rozpocząć pracę z interfejsem API REST dla usługi Azure Monitor, zobacz Przewodnik po interfejsie API REST monitorowania platformy Azure.

Metryki usługi Azure Cache for Redis

Metryki wystąpień usługi Azure Cache for Redis są zbierane przy użyciu polecenia Redis INFO . Metryki są zbierane około dwa razy na minutę, dzięki czemu mogą być wyświetlane na wykresach metryk i oceniane przez reguły alertów. Aby dowiedzieć się, jak długo są przechowywane dane i jak skonfigurować inne zasady przechowywania, zobacz Przechowywanie i archiwizowanie danych w dziennikach usługi Azure Monitor.

Metryki są raportowane przy użyciu kilku interwałów raportowania, w tym ostatnich godzin, Today, Past Week i Custom. Każdy wykres metryk zawiera wartości średnie, minimalne i maksymalne dla każdej metryki na wykresie, a niektóre metryki wyświetlają sumę dla interwału raportowania.

Każda metryka zawiera dwie wersje: jedna metryka mierzy wydajność całej pamięci podręcznej i pamięci podręcznych korzystających z klastrowania. Druga wersja metryki, która zawiera (Shard 0-9) nazwę, mierzy wydajność pojedynczego fragmentu w pamięci podręcznej. Na przykład jeśli pamięć podręczna ma cztery fragmenty, Cache Hits jest łączną liczbą trafień dla całej pamięci podręcznej i Cache Hits (Shard 3) mierzy tylko trafienia dla tego fragmentu pamięci podręcznej.

Wyświetlanie metryk pamięci podręcznej

Metryki usługi Azure Monitor dla usługi Azure Cache for Redis można wyświetlić bezpośrednio z zasobu usługi Azure Cache for Redis w witrynie Azure Portal.

Wybierz wystąpienie usługi Azure Cache for Redis w portalu. Na stronie Przegląd przedstawiono wstępnie zdefiniowane wykresy użycia pamięci i monitorowania obciążenia serwera Redis Server. Te wykresy są przydatnymi podsumowaniami, które umożliwiają szybkie przyjrzenie się stanowi pamięci podręcznej.

Aby uzyskać bardziej szczegółowe informacje, możesz monitorować następujące przydatne metryki usługi Azure Cache for Redis w sekcji Monitorowanie w menu Zasób.

Metryka usługi Azure Cache for Redis	Więcej informacji
Użycie przepustowości sieci	Wydajność pamięci podręcznej — dostępna przepustowość
Połączonych klientów	Domyślna konfiguracja serwera Redis — maksymalna liczba klientów
Obciążenie serwera	Ładowanie serwera Redis
Użycie pamięci	Wydajność pamięci podręcznej — rozmiar

Tworzenie własnych metryk

Możesz utworzyć własny wykres niestandardowy, aby śledzić metryki, które chcesz zobaczyć. Metryki pamięci podręcznej są raportowane przy użyciu kilku interwałów raportowania, w tym ostatnich godzin, Today, Past Week i Custom. Po lewej stronie wybierz pozycję Metryka w sekcji Monitorowanie . Każdy wykres metryk zawiera wartości średnie, minimalne i maksymalne dla każdej metryki na wykresie, a niektóre metryki wyświetlają sumę dla interwału raportowania.

Każda metryka zawiera dwie wersje: jedna metryka mierzy wydajność całej pamięci podręcznej i pamięci podręcznych korzystających z klastrowania. Druga wersja metryki, która zawiera (Shard 0-9) nazwę, mierzy wydajność pojedynczego fragmentu w pamięci podręcznej. Na przykład jeśli pamięć podręczna ma cztery fragmenty, Cache Hits jest łączną liczbą trafień dla całej pamięci podręcznej i Cache Hits (Shard 3) mierzy tylko trafienia dla tego fragmentu pamięci podręcznej.

W menu Zasób po lewej stronie wybierz pozycję Metryki w obszarze Monitorowanie. W tym miejscu projektujesz własny wykres dla pamięci podręcznej, definiując typ metryki i typ agregacji.

Typy agregacji

Aby uzyskać ogólne informacje o typach agregacji, zobacz Konfigurowanie agregacji.

W normalnych warunkach pamięci podręcznej średnie i maksymalne są podobne, ponieważ tylko węzeł podstawowy emituje te metryki. W scenariuszu, w którym liczba połączonych klientów szybko się zmienia, Wartość Maksymalna, Średnia i Min pokazują różne wartości, co jest również oczekiwane.

Typy Liczba i Suma mogą być mylące dla niektórych metryk, takich jak połączony klienci. Zamiast tego najlepiej jest przyjrzeć się metryce Średnia , a nie metryki Suma .

Uwaga

Nawet jeśli pamięć podręczna jest bezczynna bez połączonych aktywnych aplikacji klienckich, może zostać wyświetlona niektóre działania pamięci podręcznej, takie jak połączone klientów, użycie pamięci i wykonywane operacje. Działanie jest normalne w operacji pamięci podręcznej.

W przypadku nieklastrowanych pamięci podręcznych najlepiej używać metryk bez sufiksu Instance Based. Aby na przykład sprawdzić obciążenie serwera dla wystąpienia pamięci podręcznej, użyj metryki Obciążenie serwera.

Natomiast w przypadku klastrowanych pamięci podręcznych użyj metryk z sufiksem Instance Based. Następnie dodaj podział lub filtr w pliku ShardId. Aby na przykład sprawdzić obciążenie serwera fragmentu 1, użyj metryki Obciążenie serwera (oparte na wystąpieniu), a następnie zastosuj filtr ShardId = 1.

Zapytania usługi Kusto

Dane monitorowania można analizować w magazynie dzienników usługi Azure Monitor /Log Analytics przy użyciu języka zapytań Kusto (KQL).

Ważne

Po wybraniu pozycji Dzienniki z menu usługi w portalu usługa Log Analytics zostanie otwarta z zakresem zapytania ustawionym na bieżącą usługę. Ten zakres oznacza, że zapytania dziennika będą zawierać tylko dane z tego typu zasobu. Jeśli chcesz uruchomić zapytanie zawierające dane z innych usług platformy Azure, wybierz pozycję Dzienniki z menu usługi Azure Monitor . Aby uzyskać szczegółowe informacje, zobacz Zakres zapytań dzienników i zakres czasu w usłudze Azure Monitor Log Analytics .

Aby uzyskać listę typowych zapytań dotyczących dowolnej usługi, zobacz interfejs zapytań usługi Log Analytics.

Zapytania usługi Log Analytics

Uwaga

Aby zapoznać się z samouczkiem dotyczącym korzystania z usługi Azure Log Analytics, zobacz Omówienie usługi Log Analytics w usłudze Azure Monitor. Pamiętaj, że wyświetlenie dzienników w usłudze Log Analytics może potrwać do 90 minut.

Poniżej przedstawiono kilka podstawowych zapytań, które mają być używane jako modele.

Zapytania dotyczące warstw Podstawowa, Standardowa i Premium

• Połączenia klienta usługi Azure Cache for Redis na godzinę w określonym zakresie adresów IP:

let IpRange = "10.1.1.0/24";
ACRConnectedClientList
// For particular datetime filtering, add '| where TimeGenerated between (StartTime .. EndTime)'
| where ipv4_is_in_range(ClientIp, IpRange)
| summarize ConnectionCount = sum(ClientCount) by TimeRange = bin(TimeGenerated, 1h)

• Unikatowe adresy IP klienta redis połączone z pamięcią podręczną:

ACRConnectedClientList
| summarize count() by ClientIp

Zapytania dotyczące warstw Flash w przedsiębiorstwie i przedsiębiorstwie

• Połączenia usługi Azure Cache for Redis na godzinę w określonym zakresie adresów IP:

REDConnectionEvents
// For particular datetime filtering, add '| where EventTime between (StartTime .. EndTime)'
// For particular IP range filtering, add '| where ipv4_is_in_range(ClientIp, IpRange)'
// IP range can be defined like this 'let IpRange = "10.1.1.0/24";' at the top of query.
| extend EventTime = unixtime_seconds_todatetime(EventEpochTime)
| where EventType == "new_conn"
| summarize ConnectionCount = count() by TimeRange = bin(EventTime, 1h)

• Żądania uwierzytelniania usługi Azure Cache for Redis na godzinę w określonym zakresie adresów IP:

REDConnectionEvents
| extend EventTime = unixtime_seconds_todatetime(EventEpochTime)
// For particular datetime filtering, add '| where EventTime between (StartTime .. EndTime)'
// For particular IP range filtering, add '| where ipv4_is_in_range(ClientIp, IpRange)'
// IP range can be defined like this 'let IpRange = "10.1.1.0/24";' at the top of query.
| where EventType == "auth"
| summarize AuthenticationRequestsCount = count() by TimeRange = bin(EventTime, 1h)

• Unikatowe adresy IP klienta redis połączone z pamięcią podręczną:

REDConnectionEvents
// https://docs.redis.com/latest/rs/security/audit-events/#status-result-codes
// EventStatus :
// 0    AUTHENTICATION_FAILED    -    Invalid username and/or password.
// 1    AUTHENTICATION_FAILED_TOO_LONG    -    Username or password are too long.
// 2    AUTHENTICATION_NOT_REQUIRED    -    Client tried to authenticate, but authentication isn’t necessary.
// 3    AUTHENTICATION_DIRECTORY_PENDING    -    Attempting to receive authentication info from the directory in async mode.
// 4    AUTHENTICATION_DIRECTORY_ERROR    -    Authentication attempt failed because there was a directory connection error.
// 5    AUTHENTICATION_SYNCER_IN_PROGRESS    -    Syncer SASL handshake. Return SASL response and wait for the next request.
// 6    AUTHENTICATION_SYNCER_FAILED    -    Syncer SASL handshake. Returned SASL response and closed the connection.
// 7    AUTHENTICATION_SYNCER_OK    -    Syncer authenticated. Returned SASL response.
// 8    AUTHENTICATION_OK    -    Client successfully authenticated.
| where EventType == "auth" and EventStatus == 2 or EventStatus == 8 or EventStatus == 7
| summarize count() by ClientIp

• Nieudane próby uwierzytelnienia w pamięci podręcznej

REDConnectionEvents
// https://docs.redis.com/latest/rs/security/audit-events/#status-result-codes
// EventStatus : 
// 0    AUTHENTICATION_FAILED    -    Invalid username and/or password.
// 1    AUTHENTICATION_FAILED_TOO_LONG    -    Username or password are too long.
// 2    AUTHENTICATION_NOT_REQUIRED    -    Client tried to authenticate, but authentication isn’t necessary.
// 3    AUTHENTICATION_DIRECTORY_PENDING    -    Attempting to receive authentication info from the directory in async mode.
// 4    AUTHENTICATION_DIRECTORY_ERROR    -    Authentication attempt failed because there was a directory connection error.
// 5    AUTHENTICATION_SYNCER_IN_PROGRESS    -    Syncer SASL handshake. Return SASL response and wait for the next request.
// 6    AUTHENTICATION_SYNCER_FAILED    -    Syncer SASL handshake. Returned SASL response and closed the connection.
// 7    AUTHENTICATION_SYNCER_OK    -    Syncer authenticated. Returned SASL response.
// 8    AUTHENTICATION_OK    -    Client successfully authenticated.
| where EventType == "auth" and EventStatus != 2 and EventStatus != 8 and EventStatus != 7
| project ClientIp, EventStatus, ConnectionId

Alerty

Alerty usługi Azure Monitor proaktywnie powiadamiają o znalezieniu określonych warunków w danych monitorowania. Alerty umożliwiają identyfikowanie i rozwiązywanie problemów w systemie przed ich zauważeniem przez klientów. Aby uzyskać więcej informacji, zobacz Alerty usługi Azure Monitor.

Istnieje wiele źródeł typowych alertów dotyczących zasobów platformy Azure. Przykłady typowych alertów dotyczących zasobów platformy Azure można znaleźć w temacie Przykładowe zapytania alertów dziennika. Witryna Alerty bazowe usługi Azure Monitor (AMBA) udostępnia częściowo zautomatyzowaną metodę implementowania ważnych alertów metryk platformy, pulpitów nawigacyjnych i wytycznych. Witryna ma zastosowanie do stale powiększającego się podzestawu usług platformy Azure, w tym wszystkich usług, które są częścią strefy docelowej platformy Azure (ALZ).

Typowy schemat alertu standandaryzuje użycie powiadomień o alertach usługi Azure Monitor. Aby uzyskać więcej informacji, zobacz Wspólny schemat alertów.

Typy alertów

Możesz otrzymywać alerty dotyczące dowolnej metryki lub źródła danych dziennika na platformie danych usługi Azure Monitor. Istnieje wiele różnych typów alertów w zależności od usług, które monitorujesz i zbieranych danych monitorowania. Różne typy alertów mają różne zalety i wady. Aby uzyskać więcej informacji, zobacz Wybieranie odpowiedniego typu alertu monitorowania.

Poniższa lista zawiera opis typów alertów usługi Azure Monitor, które można utworzyć:

• Alerty metryk oceniają metryki zasobów w regularnych odstępach czasu. Metryki mogą być metrykami platformy, metrykami niestandardowymi, dziennikami z usługi Azure Monitor przekonwertowanym na metryki lub metrykami usługi Application Insights. Alerty metryk mogą również stosować wiele warunków i progów dynamicznych.
• Alerty dzienników umożliwiają użytkownikom używanie zapytania usługi Log Analytics do oceny dzienników zasobów z wstępnie zdefiniowaną częstotliwością.
• Alerty dziennika aktywności są wyzwalane, gdy wystąpi nowe zdarzenie dziennika aktywności zgodne ze zdefiniowanymi warunkami. Alerty usługi Resource Health i alerty usługi Service Health to alerty dziennika aktywności, które zgłaszają kondycję usługi i zasobów.

Niektóre usługi platformy Azure obsługują również alerty wykrywania inteligentnego, alerty Prometheus lub zalecane reguły alertów.

W przypadku niektórych usług można monitorować na dużą skalę, stosując tę samą regułę alertu metryki do wielu zasobów tego samego typu, które istnieją w tym samym regionie świadczenia usługi Azure. Poszczególne powiadomienia są wysyłane dla każdego monitorowanego zasobu. Aby uzyskać informacje o obsługiwanych usługach i chmurach platformy Azure, zobacz Monitorowanie wielu zasobów przy użyciu jednej reguły alertu.

Tworzenie alertów

Można skonfigurować odbieranie alertów w oparciu o metryki i dzienniki aktywności. Usługa Azure Monitor umożliwia skonfigurowanie alertu powodującego wykonywanie następujących czynności po jego wyzwoleniu:

• Wysyłanie powiadomienia e-mail
• Wywołanie elementu webhook
• Wywołanie aplikacji logiki platformy Azure

Aby skonfigurować alerty dla pamięci podręcznej, wybierz pozycję Alerty w obszarze Monitorowanie w menu Zasób.

Typowe reguły alertów usługi Azure Cache for Redis

W poniższej tabeli wymieniono typowe i zalecane reguły alertów dla usługi Azure Cache for Redis.

Typ alertu	Warunek	opis
Metric	99. opóźnienie percentylu	Alert dotyczący najgorszego opóźnienia poleceń po stronie serwera w wystąpieniach usługi Azure Cache for Redis. Opóźnienie jest mierzone przy użyciu PING poleceń i śledzenia czasów odpowiedzi. Śledź kondycję wystąpienia pamięci podręcznej, aby sprawdzić, czy długotrwałe polecenia obniżają wydajność opóźnień.
Metric	Wysokie Server Load użycie lub skoki	Duże obciążenie serwera oznacza, że serwer Redis nie może nadążyć za żądaniami, co prowadzi do przekroczenia limitu czasu lub wolnych odpowiedzi. Utwórz alerty dotyczące metryk obciążenia serwera, aby otrzymywać powiadomienia na wczesnym etapie o potencjalnym wpływie.
Metric	Wysokie użycie przepustowości sieci	Jeśli serwer przekroczy dostępną przepustowość, dane nie będą wysyłane do klienta tak szybko. Żądania klientów mogą powodować przekraczanie limitu czasu, ponieważ serwer nie może wystarczająco szybko wypychać danych do klienta. Skonfiguruj alerty dotyczące limitów przepustowości sieci po stronie serwera przy użyciu Cache Read liczników i Cache Write .

Zalecenia doradcy

W przypadku niektórych usług, jeśli podczas operacji zasobów wystąpią krytyczne warunki lub nieuchronne zmiany, na stronie Przegląd usługi w portalu zostanie wyświetlony alert. Więcej informacji i zalecanych poprawek alertu można znaleźć w temacie Zalecenia usługi Advisor w obszarze Monitorowanie w menu po lewej stronie. Podczas normalnych operacji nie są wyświetlane żadne zalecenia doradcy.

Aby uzyskać więcej informacji na temat usługi Azure Advisor, zobacz Omówienie usługi Azure Advisor.

Poniższy zrzut ekranu przedstawia zalecenie doradcy dotyczące alertu usługi Azure Cache for Redis:

Aby uaktualnić pamięć podręczną, wybierz pozycję Uaktualnij teraz , aby zmienić warstwę cenową i skalować pamięć podręczną. Aby uzyskać więcej informacji na temat wybierania warstwy cenowej, zobacz Wybieranie odpowiedniej warstwy.

Powiązana zawartość

• Zobacz Dokumentację danych monitorowania usługi Azure Cache for Redis, aby uzyskać informacje o metrykach, dziennikach i innych ważnych wartościach utworzonych dla usługi Azure Cache for Redis.
• Zobacz Monitorowanie zasobów platformy Azure za pomocą usługi Azure Monitor , aby uzyskać ogólne informacje na temat monitorowania zasobów platformy Azure.