Monitorování služby Azure Cache for Redis

Tento článek popisuje:

• Typy dat monitorování, které můžete pro tuto službu shromažďovat.
• Způsoby analýzy dat

Poznámka:

Pokud už tuto službu nebo Azure Monitor znáte a chcete jenom vědět, jak analyzovat data monitorování, přečtěte si část Analyzovat na konci tohoto článku.

Pokud máte důležité aplikace a obchodní procesy, které spoléhají na prostředky Azure, musíte monitorovat a dostávat výstrahy pro váš systém. Služba Azure Monitor shromažďuje a agreguje metriky a protokoly ze všech komponent systému. Azure Monitor poskytuje přehled o dostupnosti, výkonu a odolnosti a upozorní vás na problémy. K nastavení a zobrazení dat monitorování můžete použít Azure Portal, PowerShell, Azure CLI, ROZHRANÍ REST API nebo klientské knihovny.

• Další informace o službě Azure Monitor najdete v přehledu služby Azure Monitor.
• Další informace o tom, jak obecně monitorovat prostředky Azure, najdete v tématu Monitorování prostředků Azure pomocí služby Azure Monitor.

Vhledy

Některé služby v Azure mají integrovaný řídicí panel monitorování na webu Azure Portal, který poskytuje výchozí bod pro monitorování vaší služby. Tyto řídicí panely se nazývají přehledy a najdete je v Centru přehledů služby Azure Monitor na webu Azure Portal.

Poznatky pro Azure Cache for Redis poskytují následující dojmy:

• Pohled na škálování vašich Azure Cache for Redis zdrojů napříč předplatnými. Rozsah můžete selektivně vymezit jenom na předplatná a prostředky, které chcete vyhodnotit.
• Podrobná analýza prostředku Azure Cache for Redis Při diagnostice problémů můžete zobrazit podrobnou analýzu využití, selhání, kapacity a operací nebo podrobné zobrazení relevantních informací.
• Přizpůsobení založené na šablonách sešitů služby Azure Monitor Můžete změnit, jaké metriky se zobrazují a upravují nebo nastavují prahové hodnoty, které odpovídají vašim limitům. Změny můžete uložit ve vlastním sešitu a pak připnout grafy sešitů na řídicí panely Azure.

Přehledy pro Azure Cache for Redis nevyžadují povolení ani konfiguraci čehokoli. Informace o službě Azure Cache for Redis se shromažďují ve výchozím nastavení a za přístup k přehledům se neúčtují žádné další poplatky.

Pro rozšíření znalostí o tom, jak prohlížet, konfigurovat a přizpůsobovat informace pro Azure Cache for Redis, navštivte [Azure Monitor insights for Azure Cache for Redis]/azure-cache-for-redis/cache-insights-overview.md).

Typy zdrojů

Azure používá koncept typů prostředků a ID k identifikaci všeho v předplatném. Typy prostředků jsou také součástí ID prostředků pro každý prostředek spuštěný v Azure. Například jedním z typů prostředků pro virtuální počítač je Microsoft.Compute/virtualMachines. Seznam služeb a jejich přidružených typů prostředků najdete v tématu Poskytovatelé prostředků.

Azure Monitor podobně řadí základní monitorovací data do metrik a protokolů podle typů prostředků, také nazývaných jako jmenné prostory. Různé metriky a protokoly jsou k dispozici pro různé typy prostředků. Vaše služba může být přidružená k více než jednomu typu prostředku.

Další informace o typech prostředků pro Azure Cache for Redis najdete v referenčních informacích k datům monitorování Azure Cache for Redis.

Úložiště dat

Pro použití Azure Monitoru:

• Data metrik se ukládají v databázi metrik služby Azure Monitor.
• Data protokolů se ukládají v úložišti protokolů služby Azure Monitor. Log Analytics je nástroj v portálu Azure, který umožňuje dotazování na toto úložiště.
• Protokol aktivit Azure je samostatné úložiště s vlastním rozhraním na webu Azure Portal.

Volitelně můžete směrovat data metriky a protokolu aktivit do úložiště protokolů služby Azure Monitor. Log Analytics pak můžete použít k dotazování na data a jejich korelaci s jinými daty protokolů.

Mnoho služeb může použít nastavení diagnostiky k odesílání metrik a dat protokolů do jiných umístění úložiště mimo Azure Monitor. Mezi příklady patří Azure Storage, hostované partnerské systémy a partnerské systémy mimo Azure pomocí služby Event Hubs.

Podrobné informace o tom, jak Azure Monitor ukládá data, najdete na datové platformě Azure Monitoru.

Metriky služby Azure Monitor

Azure Monitor poskytuje metriky platformy pro většinu služeb. Tyto metriky jsou:

• Individuálně definované pro každý namespace.
• Uložená v databázi metrik časových řad služby Azure Monitor.
• Zjednodušené a schopné podporovat upozorňování téměř v reálném čase.
• Používá se ke sledování výkonu prostředku v průběhu času.

Kolekce: Azure Monitor shromažďuje metriky platformy automaticky. Není nutná žádná konfigurace.

Směrování: Některé metriky platformy můžete také směrovat do protokolů služby Azure Monitor / Log Analytics, abyste je mohli dotazovat pomocí jiných dat protokolů. Zkontrolujte nastavení exportu DS pro každou metriku a zjistěte, jestli můžete pomocí nastavení diagnostiky směrovat metriku do protokolů služby Azure Monitor nebo Log Analytics.

• Další informace najdete v nastavení diagnostiky Metriky.
• Informace o konfiguraci nastavení diagnostiky pro službu najdete v tématu Vytvoření nastavení diagnostiky ve službě Azure Monitor.

Seznam všech metrik, které je možné shromáždit pro všechny prostředky ve službě Azure Monitor, najdete v tématu Podporované metriky ve službě Azure Monitor.

Seznam dostupných metrik pro Azure Cache for Redis najdete v referenčních informacích k datům monitorování Azure Cache for Redis.

Protokoly zdrojů Azure Monitor

Logy zdrojů umožňují náhled do operací, které byly provedeny prostřednictvím prostředku Azure. Protokoly se generují automaticky, ale pokud je chcete uložit nebo dotazovat, musíte je směrovat do protokolů služby Azure Monitor. Protokoly jsou uspořádané do jednotlivých kategorií. Daný obor pojmenování může mít více kategorií záznamů prostředků.

Kolekce: Protokoly zdrojů se neshromažďují a neukládají, dokud nevytvoříte diagnostické nastavení a nesměrujete protokoly do jednoho nebo více umístění. Při vytváření nastavení diagnostiky určíte, které kategorie protokolů se mají shromažďovat. Existuje několik způsobů, jak vytvořit a udržovat nastavení diagnostiky, včetně webu Azure Portal, prostřednictvím kódu programu a služby Azure Policy.

Směrování: Navrhované výchozí nastavení je směrovat záznamy o prostředcích do protokolů služby Azure Monitor, tak, aby bylo možné je dotazovat pomocí jiných dat protokolu. K dispozici jsou také jiná umístění, jako je Azure Storage, Azure Event Hubs a někteří monitorovací partneři Microsoftu. Pro více informací se podívejte na protokoly prostředků Azure a umístění protokolů prostředků.

Podrobné informace o shromažďování, ukládání a směrování protokolů prostředků najdete v části Nastavení diagnostiky ve službě Azure Monitor.

Seznam všech dostupných kategorií protokolů prostředků ve službě Azure Monitor najdete v tématu Podporované protokoly prostředků ve službě Azure Monitor.

Všechny protokoly prostředků v Azure Monitor mají stejná hlavičková pole, za kterými následují pole specifická pro službu. Běžné schéma je uvedeno ve Azure Monitor resource log schema.

Dostupné kategorie protokolů prostředků, jejich přidružené tabulky Log Analytics a schémata protokolů pro Azure Cache for Redis najdete v referenčních materiálech k monitorovacím datům Azure Cache for Redis.

Protokoly prostředků Azure Cache for Redis

V Azure Cache for Redis jsou k dispozici dvě možnosti pro protokolování:

• Metriky mezipaměti ("AllMetrics") protokolují metriky ze služby Azure Monitor
• Protokoly připojení protokolující připojení k mezipaměti pro účely zabezpečení a diagnostiky.

Metriky mezipaměti

Azure Cache for Redis generuje mnoho metrik, jako jsou Server Load a Connections per Second, které je užitečné protokolovat. K protokolování těchto a dalších metrik mezipaměti slouží možnost AllMetrics. Můžete nakonfigurovat, jak dlouho se mají metriky uchovávat.

Protokoly připojení

Azure Cache for Redis používá nastavení diagnostiky Azure k protokolování informací o klientských připojeních k mezipaměti. Protokolování a analýza tohoto nastavení diagnostiky vám pomůže pochopit, kdo se připojuje k vašim mezipamětím, a čas těchto připojení. Data protokolu lze použít k identifikaci rozsahu porušení zabezpečení a pro účely auditování zabezpečení.

Protokoly připojení mají mírně odlišné implementace, obsah a postupy nastavení pro různé úrovně Azure Cache for Redis. Pro podrobnosti viz [Azure Monitor diagnostic settings]/azure-cache-for-redis/cache-monitor-diagnostic-settings.md).

Protokol aktivit Azure

Protokol aktivit obsahuje události na úrovni předplatného, které sledují operace každého prostředku Azure tak, jak jsou viditelné zvenčí; například vytvoření nového prostředku nebo spuštění virtuálního počítače.

Shromažďování: Události protokolu aktivit se automaticky generují a shromažďují v samostatném úložišti pro zobrazení na webu Azure Portal.

Směrování: Data protokolu aktivit můžete odesílat do protokolů služby Azure Monitor, abyste je mohli analyzovat společně s dalšími daty protokolů. K dispozici jsou také jiná umístění, jako je Azure Storage, Azure Event Hubs a někteří monitorovací partneři Microsoftu. Další informace o směrování protokolu aktivit najdete v tématu Přehled protokolu aktivit Azure.

Analýza dat monitorování

Existuje mnoho nástrojů pro analýzu dat monitorování.

Nástroje služby Azure Monitor

Azure Monitor podporuje následující základní nástroje:

• Metrics Explorer, nástroj v Azure Portálu, který umožňuje zobrazit a analyzovat metriky pro zdroje Azure. Další informace najdete v tématu Analýza metrik pomocí Průzkumníka metrik služby Azure Monitor.

• Log Analytics, nástroj na webu Azure Portal, který umožňuje dotazovat a analyzovat data protokolů pomocí dotazovacího jazyka Kusto (KQL). Další informace najdete v tématu Začínáme s dotazy na protokoly ve službě Azure Monitor.

• Protokol aktivit, který má uživatelské rozhraní v Azure portálu pro zobrazení a základní vyhledávání. Pokud chcete provádět podrobnější analýzu, musíte data směrovat do protokolů služby Azure Monitor a spouštět složitější dotazy v Log Analytics.

Mezi nástroje, které umožňují složitější vizualizaci, patří:

• Řídicí panely , které umožňují kombinovat různé druhy dat do jednoho podokna na webu Azure Portal.
• Sešity a přizpůsobitelné sestavy, které můžete vytvořit v portálu Azure. Sešity mohou obsahovat text, metriky a dotazy na logy.
• Grafana, otevřený nástroj platformy, který exceluje v provozních řídicích panelech Grafana umožňuje vytvářet řídicí panely, které obsahují data z více zdrojů, než je Azure Monitor.
• Power BI, služba obchodní analýzy, která poskytuje interaktivní vizualizace napříč různými zdroji dat. Power BI můžete nakonfigurovat tak, aby automaticky naimportovali data protokolů ze služby Azure Monitor, abyste mohli tyto vizualizace využívat.

Nástroje pro export ve službě Azure Monitor

Data ze služby Azure Monitor můžete získat do jiných nástrojů pomocí následujících metod:

• Metriky: Pomocí rozhraní REST API pro metriky extrahujte data metrik z databáze metrik služby Azure Monitor. Rozhraní API podporuje filtrovací výrazy pro upřesnění načtených dat. Další informace najdete v referenčních informacích k rozhraní REST API služby Azure Monitor.

• Protokoly: Použijte rozhraní REST API nebo přidružené klientské knihovny.

• Další možností je export dat z pracovního prostoru.

Pokud chcete začít s rozhraním REST API pro Azure Monitor, přečtěte si průvodce rozhraním REST API pro monitorování Azure.

Metriky Azure Cache for Redis

Metriky pro instance Azure Cache for Redis se shromažďují pomocí příkazu Redis INFO . Metriky se shromažďují přibližně dvakrát za minutu, aby se mohly zobrazit v grafech metrik a pravidla upozornění je mohla vyhodnotit. Informace o tom, jak dlouho se data uchovávají a jak nakonfigurovat jiné zásady uchovávání informací, najdete v tématu Uchovávání a archivace dat v protokolech služby Azure Monitor.

Metriky jsou vykazovány v několika intervalech, včetně poslední hodiny, dnes, minulého týdne a vlastního nastavení. Každý graf metrik zobrazuje průměrné, minimální a maximální hodnoty pro každou metriku v grafu a některé metriky zobrazují celkovou hodnotu za období generování sestav.

Každá metrika obsahuje dvě verze: Jedna metrika měří výkon pro celou mezipaměť a pro mezipaměti, které používají clustering. Druhá verze metriky, která zahrnuje (Shard 0-9) v názvu, měří výkon pro jeden fragment v mezipaměti. Pokud má například mezipaměť čtyři horizontální oddíly, Cache Hits je celkový počet přístupů pro celou mezipaměť a Cache Hits (Shard 3) měří pouze počet přístupů pro tento horizontální oddíl mezipaměti.

Zobrazení metrik mezipaměti

Metriky služby Azure Monitor pro Azure Cache for Redis můžete zobrazit přímo z prostředku Azure Cache for Redis na webu Azure Portal.

Na portálu vyberte instanci Azure Cache for Redis. Na stránce Přehled se zobrazují předdefinované grafy využití paměti a monitorování zatížení serveru Redis Server. Tyto grafy jsou užitečné souhrny, které vám umožní rychle se podívat na stav mezipaměti.

Pro podrobnější informace můžete sledovat následující užitečné metriky Azure Cache for Redis z části Monitorování v nabídce Prostředky.

Metrika Azure Cache for Redis	Více informací
Využití šířky pásma sítě	Výkon mezipaměti – dostupná šířka pásma
Klienti, kteří jsou připojeni	Výchozí konfigurace serveru Redis – maximální počet klientů
Zatížení serveru	Zatížení serveru Redis
Využití paměti	Výkon mezipaměti – velikost

Vytvoření vlastních metrik

Můžete vytvořit vlastní graf pro sledování metrik, které chcete zobrazit. Metriky mezipaměti se hlásí v několika intervalech, včetně poslední hodina, dnes, poslední týden a vlastní. Vlevo vyberte metriku v části Monitorování. Každý graf metrik zobrazuje průměrné, minimální a maximální hodnoty pro každou metriku v grafu a některé metriky zobrazují celkovou hodnotu za období generování sestav.

Každá metrika obsahuje dvě verze: Jedna metrika měří výkon pro celou mezipaměť a pro mezipaměti, které používají clustering. Druhá verze metriky, která zahrnuje (Shard 0-9) v názvu, měří výkon pro jeden fragment v mezipaměti. Pokud má například mezipaměť čtyři horizontální oddíly, Cache Hits je celkový počet přístupů pro celou mezipaměť a Cache Hits (Shard 3) měří pouze počet přístupů pro tento horizontální oddíl mezipaměti.

V nabídce Prostředek na levé straně vyberte Metriky v části Monitorování. Tady navrhnete vlastní graf pro vaši mezipaměť a definujete typ metriky a typ agregace.

Typy agregace

Obecné informace o typech agregace najdete v tématu Konfigurace agregace.

Za normálních podmínek mezipaměti jsou průměr a maximum podobné, protože tyto metriky generuje pouze primární uzel. Ve scénáři, kdy se počet připojených klientů rychle změní, Max, Average a Min zobrazují různé hodnoty, což je také očekávané chování.

Typy Count a Sum můžou být pro určité metriky zavádějící, například připojené klienty. Místo toho je nejlepší se podívat na průměrné metriky a ne na metriky součet.

Poznámka:

I když je mezipaměť nečinná bez připojených aktivních klientských aplikací, může se zobrazit nějaká aktivita mezipaměti, jako jsou připojení klienti, využití paměti a prováděné operace. Aktivita je v provozu mezipaměti normální.

Pro neclusterované mezipaměti je nejlepší použít metriky bez přípony Instance Based. Pokud chcete například zkontrolovat zatížení serveru pro vaši instanci mezipaměti, použijte metriky Zatížení serveru.

Naproti tomu pro clusterované mezipaměti použijte metriky s příponou Instance Based. Potom přidejte rozdělení nebo filtr na ShardId. Například, chcete-li zkontrolovat zatížení serveru horizontálního oddílu 1, použijte metriku zatížení serveru (na základě instance), a poté aplikujte filtr ShardId = 1.

Dotazy pro Kusto

Data monitorování můžete analyzovat v protokolech služby Azure Monitor nebo v úložišti Log Analytics pomocí dotazovacího jazyka Kusto (KQL).

Důležité

Když na portálu vyberete protokoly z nabídky služby, otevře se Log Analytics s oborem dotazu nastaveným na aktuální službu. Tento obor znamená, že dotazy protokolu budou obsahovat pouze data z tohoto typu prostředku. Pokud chcete spustit dotaz, který obsahuje data z jiných služeb Azure, vyberte Protokoly z nabídky Azure Monitor. Podrobnosti najdete v tématu Rozsah dotazů protokolu a časový rozsah ve službě Azure Monitor Log Analytics .

Seznam běžných dotazů pro libovolnou službu najdete v rozhraní dotazů Log Analytics.

Dotazy pro Log Analytics

Poznámka:

Kurz použití Azure Log Analytics najdete v přehledu služby Log Analytics ve službě Azure Monitor. Mějte na paměti, že může trvat až 90 minut, než se protokoly zobrazí v Log Analytics.

Zde jsou některé základní dotazy, které mohou sloužit jako modely.

Dotazy na úrovně Basic, Standard a Premium

• Připojení klientů Azure Cache for Redis za hodinu v zadaném rozsahu IP adres:

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)

• Jedinečné IP adresy klienta Redis, které jsou připojené k mezipaměti:

ACRConnectedClientList
| summarize count() by ClientIp

Dotazy na úrovně Enterprise a Enterprise Flash

• Připojení Azure Cache for Redis za hodinu v zadaném rozsahu IP adres:

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)

• Požadavky na ověřování Azure Cache for Redis za hodinu v zadaném rozsahu IP adres:

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)

• Jedinečné IP adresy klienta Redis, které jsou připojené k mezipaměti:

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

• Neúspěšné pokusy o ověření v mezipaměti

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

Výstrahy

Upozornění služby Azure Monitor vás aktivně upozorňují, když se v datech monitorování nacházejí konkrétní podmínky. Upozornění umožňují identifikovat a řešit problémy ve vašem systému, než si je zákazníci všimnou. Další informace najdete v tématu Upozornění služby Azure Monitor.

Existuje mnoho zdrojů běžných upozornění pro prostředky Azure. Příklady běžných upozornění pro prostředky Azure najdete v části Ukázkové dotazy na protokolová upozornění. Web AMBA (Baseline Alerts) služby Azure Monitor poskytuje poloautomatickou metodu implementace důležitých upozornění, řídicích panelů a pokynů pro metriky platformy. Web se vztahuje na neustále se rozšiřující podmnožinu služeb Azure, včetně všech služeb, které jsou součástí cílové zóny Azure (ALZ).

Unifikované schéma upozornění standardizuje příjem notifikací služby Azure Monitor. Další informace najdete v tématu Běžné schéma upozornění.

Typy výstrah

Na libovolnou metriku nebo zdroj protokolových dat na datové platformě Azure Monitoru můžete nastavit upozornění. Existuje mnoho různých typů upozornění v závislosti na službách, které monitorujete, a na datech monitorování, která shromažďujete. Různé typy upozornění mají různé výhody a nevýhody. Další informace naleznete v tématu Volba správného typu upozornění monitorování.

Následující seznam popisuje typy upozornění služby Azure Monitor, které můžete vytvořit:

• Upozornění na metriky vyhodnocují metriky prostředků v pravidelných intervalech. Metriky můžou být metriky platformy, vlastní metriky, protokoly ze služby Azure Monitor převedené na metriky nebo metriky Application Insights. Upozornění na metriky můžou také použít více podmínek a dynamických prahových hodnot.
• Protokolová upozornění umožňují uživatelům použít dotaz Log Analytics k vyhodnocení protokolů prostředků v předem definovaných intervalech.
• Upozornění protokolu aktivit se aktivují, když dojde k nové události protokolu aktivit, která odpovídá definovaným podmínkám. Upozornění na stav prostředků a upozornění na stav služby jsou upozornění z protokolu aktivit, která informují o stavu vašich služeb a prostředků.

Některé služby Azure také podporují upozornění inteligentního zjišťování, výstrahy Prometheus nebo doporučená pravidla upozornění.

U některých služeb můžete monitorovat škálování použitím stejného pravidla upozornění na metriku u více prostředků stejného typu, které existují ve stejné oblasti Azure. Jednotlivá oznámení se odesílají pro každý monitorovaný prostředek. Pro informace o podporovaných službách a cloudech Azure viz Monitorování více prostředků pomocí jednoho pravidla upozornění.

Vytváření upozornění

Můžete nakonfigurovat odesílání upozornění na základě metrik a protokolů aktivit. Azure Monitor umožňuje nakonfigurovat upozornění, které při aktivaci provede některé z následujících kroků:

• Odeslání e-mailového oznámení
• Volání webhooku
• Vyvolání aplikace logiky Azure

Chcete-li nakonfigurovat výstrahy pro vaši mezipaměť, vyberte možnost Výstrahy pod Monitorování v nabídce Zdroje.

Běžná pravidla upozornění služby Azure Cache for Redis

Následující tabulka uvádí běžná a doporučená pravidla upozornění pro Azure Cache for Redis.

Typ upozornění	Podmínka	Popis
Metric	Latence 99. percentilu	Upozornění na nejhorší možnou latenci serverových příkazů v instancích Azure Cache for Redis. Latence se měří pomocí PING příkazů a sledování doby odezvy. Sledujte stav vaší instance mezipaměti a zjistěte, jestli dlouhotrvající příkazy neohrožují výkon latence.
Metric	Vysoké Server Load využití nebo výkyvy	Vysoké zatížení serveru znamená, že server Redis nemůže držet krok s požadavky, což vede k vypršení časového limitu nebo pomalým odpovědím. Vytvořte upozornění na metriky zatížení serveru, abyste byli včas informováni o potenciálních dopadech.
Metric	Vysoké využití šířky pásma sítě	Pokud server překročí dostupnou šířku pásma, budou data odesílána klientovi pomaleji. U požadavků klienta může docházet k vypršení časových limitů, protože server nedokáže dostatečně rychle odesílat data do klienta. Nastavte upozornění na omezení šířky pásma sítě na straně serveru pomocí čítačů Cache Read a Cache Write.

Doporučení poradce

U některých služeb, pokud během operací prostředků dojde k kritickým nebo bezprostředním změnám, zobrazí se na stránce Přehled služby na portálu výstraha. Další informace a doporučené opravy výstrahy najdete v doporučeních Advisoruv části Monitorování v nabídce vlevo. Během normálních operací se nezobrazují žádná doporučení poradce.

Další informace o Azure Advisoru najdete v přehledu Azure Advisoru.

Následující snímek obrazovky ukazuje doporučení poradce pro upozornění Azure Cache for Redis:

Pokud chcete upgradovat mezipaměť, vyberte Upgradovat a změňte cenovou úroveň a škálujte mezipaměť. Další informace o výběru cenové úrovně najdete v tématu Volba správné úrovně.

Související obsah

• Informace o metrikách, protokolech a dalších důležitých hodnotách vytvořených pro Azure Cache for Redis najdete v referenčních informacích k datům monitorování Azure Cache for Redis.
• Obecné podrobnosti o monitorování prostředků Azure najdete v tématu Monitorování prostředků Azure pomocí služby Azure Monitor .