Azure Cache voor Redis bewaken

In dit artikel wordt het volgende beschreven:

• De typen bewakingsgegevens die u voor deze service kunt verzamelen.
• Manieren om die gegevens te analyseren.

Notitie

Als u al bekend bent met deze service en/of Azure Monitor en alleen wilt weten hoe u bewakingsgegevens analyseert, raadpleegt u de sectie Analyseren aan het einde van dit artikel.

Wanneer u kritieke toepassingen en bedrijfsprocessen hebt die afhankelijk zijn van Azure-resources, moet u waarschuwingen voor uw systeem bewaken en ontvangen. De Azure Monitor-service verzamelt en aggregeert metrische gegevens en logboeken van elk onderdeel van uw systeem. Azure Monitor biedt een overzicht van beschikbaarheid, prestaties en tolerantie, en geeft u een overzicht van problemen. U kunt de Azure-portal, PowerShell, Azure CLI, REST API of clientbibliotheken gebruiken om bewakingsgegevens in te stellen en weer te geven.

• Zie het overzicht van Azure Monitor voor meer informatie over Azure Monitor.
• Zie Azure-resources bewaken met Azure Monitor voor meer informatie over het bewaken van Azure-resources in het algemeen.

Inzichten

Sommige services in Azure hebben een ingebouwd bewakingsdashboard in Azure Portal dat een beginpunt biedt voor het bewaken van uw service. Deze dashboards worden inzichten genoemd en u kunt ze vinden in de Insights Hub van Azure Monitor in Azure Portal.

Inzichten voor Azure Cache voor Redis bieden de volgende ervaring:

• Op schaal gezien het perspectief van uw Azure Cache voor Redis resources in verschillende abonnementen. U kunt selectief bereik toepassen op alleen de abonnementen en resources die u wilt evalueren.
• Analyse van een Azure Cache voor Redis resource inzoomen. Als u problemen wilt diagnosticeren, kunt u gedetailleerde analyse bekijken van het gebruik, fouten, capaciteit en bewerkingen, of een uitgebreide weergave van relevante informatie bekijken.
• Aanpassing die is gebouwd op Azure Monitor-werkmapsjablonen. U kunt wijzigen welke metrische gegevens worden weergegeven en drempelwaarden wijzigen of instellen die overeenkomen met uw limieten. U kunt de wijzigingen in een aangepaste werkmap opslaan en vervolgens werkmapdiagrammen vastmaken aan Azure-dashboards.

Voor inzichten voor Azure Cache voor Redis hoeft u niets in te schakelen of te configureren. Azure Cache voor Redis gegevens worden standaard verzameld en er worden geen extra kosten in rekening gebracht voor toegang tot inzichten.

Zie Azure Monitor-inzichten voor Azure Cache voor Redis voor meer informatie over het weergeven, configureren en aanpassen van inzichten voor Azure Cache voor Redis.

Resourcetypen

Azure maakt gebruik van het concept van resourcetypen en id's om alles in een abonnement te identificeren. Resourcetypen maken ook deel uit van de resource-id's voor elke resource die wordt uitgevoerd in Azure. Eén resourcetype voor een virtuele machine is Microsoft.Compute/virtualMachinesbijvoorbeeld . Zie Resourceproviders voor een lijst met services en de bijbehorende resourcetypen.

Azure Monitor organiseert op dezelfde manier kernbewakingsgegevens in metrische gegevens en logboeken op basis van resourcetypen, ook wel naamruimten genoemd. Er zijn verschillende metrische gegevens en logboeken beschikbaar voor verschillende resourcetypen. Uw service is mogelijk gekoppeld aan meer dan één resourcetype.

Zie Azure Cache voor Redis referentiemateriaal voor bewakingsgegevens voor meer informatie over de resourcetypen voor Azure Cache voor Redis.

Gegevensopslag

Voor Azure Monitor:

• Metrische gegevens worden opgeslagen in de metrische gegevensdatabase van Azure Monitor.
• Logboekgegevens worden opgeslagen in het logboekarchief van Azure Monitor. Log Analytics is een hulpprogramma in Azure Portal waarmee een query kan worden uitgevoerd op dit archief.
• Het Azure-activiteitenlogboek is een afzonderlijk archief met een eigen interface in Azure Portal.

U kunt eventueel metrische gegevens en activiteitenlogboekgegevens routeren naar het logboekarchief van Azure Monitor. Vervolgens kunt u Log Analytics gebruiken om een query uit te voeren op de gegevens en deze te correleren met andere logboekgegevens.

Veel services kunnen diagnostische instellingen gebruiken om metrische gegevens en logboekgegevens te verzenden naar andere opslaglocaties buiten Azure Monitor. Voorbeelden hiervan zijn Azure Storage, gehoste partnersystemen en niet-Azure-partnersystemen, met behulp van Event Hubs.

Zie het Azure Monitor-gegevensplatform voor gedetailleerde informatie over hoe Azure Monitor gegevens opslaat.

Metrische gegevens van het Azure Monitor-platform

Azure Monitor biedt metrische platformgegevens voor de meeste services. Deze metrische gegevens zijn:

• Afzonderlijk gedefinieerd voor elke naamruimte.
• Opgeslagen in de metrische gegevensdatabase van Azure Monitor.
• Lichtgewicht en in staat om bijna realtime waarschuwingen te ondersteunen.
• Wordt gebruikt om de prestaties van een resource in de loop van de tijd bij te houden.

Verzameling: Azure Monitor verzamelt automatisch metrische platformgegevens. Er is geen configuratie vereist.

Routering: U kunt ook meestal metrische platformgegevens routeren naar Azure Monitor-logboeken/Log Analytics, zodat u er query's op kunt uitvoeren met andere logboekgegevens. Zie de diagnostische instelling voor metrische gegevens voor meer informatie. Zie Diagnostische instellingen maken in Azure Monitor voor informatie over het configureren van diagnostische instellingen voor een service.

Zie Ondersteunde metrische gegevens in Azure Monitor voor een lijst met alle metrische gegevens die kunnen worden verzameld voor alle resources in Azure Monitor.

Zie Azure Cache voor Redis referentiemateriaal voor bewakingsgegevens voor een lijst met beschikbare metrische gegevens voor Azure Cache voor Redis.

Azure Monitor-resourcelogboeken

Resourcelogboeken bieden inzicht in bewerkingen die zijn uitgevoerd door een Azure-resource. Logboeken worden automatisch gegenereerd, maar u moet ze routeren naar Azure Monitor-logboeken om ze op te slaan of er query's op uit te voeren. Logboeken zijn ingedeeld in categorieën. Een bepaalde naamruimte kan meerdere resourcelogboekcategorieën hebben.

Verzameling: Resourcelogboeken worden pas verzameld en opgeslagen als u een diagnostische instelling maakt en de logboeken doorsturen naar een of meer locaties. Wanneer u een diagnostische instelling maakt, geeft u op welke categorieën logboeken moeten worden verzameld. Er zijn meerdere manieren om diagnostische instellingen te maken en te onderhouden, waaronder Azure Portal, programmatisch en hoewel Azure Policy.

Routering: de voorgestelde standaardinstelling is het routeren van resourcelogboeken naar Azure Monitor-logboeken, zodat u er query's op kunt uitvoeren met andere logboekgegevens. Andere locaties, zoals Azure Storage, Azure Event Hubs en bepaalde Microsoft-bewakingspartners, zijn ook beschikbaar. Zie Azure-resourcelogboeken en resourcelogboekbestemmingen voor meer informatie.

Zie Diagnostische instellingen in Azure Monitor voor gedetailleerde informatie over het verzamelen, opslaan en routeren van resourcelogboeken.

Zie Ondersteunde resourcelogboeken in Azure Monitor voor een lijst met alle beschikbare resourcelogboekcategorieën in Azure Monitor.

Alle resourcelogboeken in Azure Monitor hebben dezelfde koptekstvelden, gevolgd door servicespecifieke velden. Het algemene schema wordt beschreven in het schema voor resourcelogboeken van Azure Monitor.

Zie Azure Cache voor Redis referentiemateriaal voor bewakingsgegevens voor de beschikbare resourcelogboekcategorieën, de bijbehorende Log Analytics-tabellen en de logboekschema's voor Azure Cache voor Redis.

resourcelogboeken Azure Cache voor Redis

In Azure Cache voor Redis zijn er twee opties beschikbaar om te registreren:

• Metrische gegevens van cache ('AllMetrics') registreert metrische gegevens van Azure Monitor
• Verbindingslogboeken registreert verbindingen met de cache voor beveiligings- en diagnostische doeleinden.

Metrische cachegegevens

Azure Cache voor Redis verzendt veel metrische gegevens, zoals Server Load en Connections per Second die handig zijn om te registreren. Als u de optie AllMetrics selecteert , kunnen deze en andere metrische gegevens van de cache worden vastgelegd. U kunt configureren hoe lang de metrische gegevens moeten worden bewaard.

Verbindingslogboeken

Azure Cache voor Redis maakt gebruik van diagnostische azure-instellingen voor het vastleggen van gegevens over clientverbindingen met uw cache. Door deze diagnostische instelling te registreren en te analyseren, krijgt u inzicht in wie verbinding maakt met uw caches en de tijdstempel van deze verbindingen. De logboekgegevens kunnen worden gebruikt om het bereik van een beveiligingsschending en voor beveiligingscontroledoeleinden te identificeren.

De verbindingslogboeken hebben iets andere implementaties, inhoud en installatieprocedures voor de verschillende Azure Cache voor Redis lagen. Zie diagnostische instellingen van Azure Monitor voor meer informatie.

Azure-activiteitenlogboek

Het activiteitenlogboek bevat gebeurtenissen op abonnementsniveau waarmee bewerkingen voor elke Azure-resource worden bijgehouden, zoals van buiten die resource wordt gezien; Bijvoorbeeld het maken van een nieuwe resource of het starten van een virtuele machine.

Verzameling: gebeurtenissen in activiteitenlogboeken worden automatisch gegenereerd en verzameld in een afzonderlijk archief voor weergave in Azure Portal.

Routering: U kunt activiteitenlogboekgegevens verzenden naar Azure Monitor-logboeken, zodat u deze naast andere logboekgegevens kunt analyseren. Andere locaties, zoals Azure Storage, Azure Event Hubs en bepaalde Microsoft-bewakingspartners, zijn ook beschikbaar. Zie Overzicht van het Azure-activiteitenlogboek voor meer informatie over het routeren van het activiteitenlogboek.

Bewakingsgegevens analyseren

Er zijn veel hulpprogramma's voor het analyseren van bewakingsgegevens.

Azure Monitor-hulpprogramma's

Azure Monitor ondersteunt de volgende basishulpprogramma's:

• Metrics Explorer, een hulpprogramma in Azure Portal waarmee u metrische gegevens voor Azure-resources kunt weergeven en analyseren. Zie Metrische gegevens analyseren met Azure Monitor Metrics Explorer voor meer informatie.

• Log Analytics, een hulpprogramma in Azure Portal waarmee u logboekgegevens kunt opvragen en analyseren met behulp van de Kusto-querytaal (KQL). Zie Aan de slag met logboekquery's in Azure Monitor voor meer informatie.

• Het activiteitenlogboek, dat een gebruikersinterface in Azure Portal heeft voor het weergeven en uitvoeren van basiszoekopdrachten. Als u uitgebreidere analyses wilt uitvoeren, moet u de gegevens routeren naar Azure Monitor-logboeken en complexere query's uitvoeren in Log Analytics.

Hulpprogramma's waarmee complexere visualisaties mogelijk zijn, zijn onder andere:

• Dashboards waarmee u verschillende soorten gegevens kunt combineren in één deelvenster in Azure Portal.
• Werkmappen, aanpasbare rapporten die u kunt maken in Azure Portal. Werkmappen kunnen tekst, metrische gegevens en logboekquery's bevatten.
• Grafana, een open platformhulpprogramma dat excelleert in operationele dashboards. U kunt Grafana gebruiken om dashboards te maken die gegevens uit meerdere andere bronnen dan Azure Monitor bevatten.
• Power BI, een business analytics-service die interactieve visualisaties biedt in verschillende gegevensbronnen. U kunt Power BI zo configureren dat logboekgegevens automatisch vanuit Azure Monitor worden geïmporteerd om te profiteren van deze visualisaties.

Azure Monitor-exporthulpprogramma's

U kunt gegevens uit Azure Monitor ophalen in andere hulpprogramma's met behulp van de volgende methoden:

• Metrische gegevens: gebruik de REST API voor metrische gegevens om metrische gegevens te extraheren uit de metrische Azure Monitor-database. De API ondersteunt filterexpressies om de opgehaalde gegevens te verfijnen. Zie azure Monitor REST API-naslaginformatie voor meer informatie.

• Logboeken: Gebruik de REST API of de bijbehorende clientbibliotheken.

• Een andere optie is het exporteren van werkruimtegegevens.

Als u aan de slag wilt gaan met de REST API voor Azure Monitor, raadpleegt u de stapsgewijze instructies voor Azure Monitoring REST API.

metrische gegevens Azure Cache voor Redis

Metrische gegevens voor Azure Cache voor Redis exemplaren worden verzameld met behulp van de Redis-opdrachtINFO. Metrische gegevens worden ongeveer twee keer per minuut verzameld, zodat ze kunnen worden weergegeven in de grafieken met metrische gegevens en kunnen worden geëvalueerd door waarschuwingsregels. Zie Gegevensretentie en archiveren in Azure Monitor-logboeken voor informatie over hoe lang gegevens worden bewaard en hoe u een ander bewaarbeleid configureert.

De metrische gegevens worden gerapporteerd met behulp van verschillende rapportage-intervallen, waaronder afgelopen uur, vandaag, afgelopen week en aangepast. In elke grafiek met metrische gegevens worden de gemiddelde, minimum- en maximumwaarden weergegeven voor elke metrische waarde in de grafiek, en sommige metrische gegevens geven een totaal weer voor het rapportage-interval.

Elke metriek bevat twee versies: Met één metrische waarde worden de prestaties voor de hele cache meten en voor caches die gebruikmaken van clustering. Een tweede versie van de metrische waarde, die in de naam is opgenomen (Shard 0-9) , meet de prestaties voor één shard in een cache. Als een cache bijvoorbeeld vier shards heeft, Cache Hits is het totale aantal treffers voor de hele cache en Cache Hits (Shard 3) meet alleen de treffers voor die shard van de cache.

Metrische gegevens van cache weergeven

U kunt metrische gegevens van Azure Monitor voor Azure Cache voor Redis rechtstreeks vanuit een Azure Cache voor Redis resource bekijken in Azure Portal.

Selecteer uw Azure Cache voor Redis exemplaar in de portal. Op de overzichtspagina ziet u de vooraf gedefinieerde grafieken voor geheugengebruik en Redis Server Load Monitoring. Deze grafieken zijn handige samenvattingen waarmee u de status van uw cache snel kunt bekijken.

Voor uitgebreidere informatie kunt u de volgende nuttige Azure Cache voor Redis metrische gegevens bewaken vanuit de sectie Bewaking van het menu Resource.

metrische gegevens Azure Cache voor Redis	Meer informatie
Gebruik van netwerkbandbreedte	Cacheprestaties - beschikbare bandbreedte
Verbonden clients	Standaardconfiguratie van Redis-server - maximaal aantal clients
Serverbelasting	Redis-server laden
Geheugengebruik	Cacheprestaties - grootte

Uw eigen metrische gegevens maken

U kunt uw eigen aangepaste grafiek maken om de metrische gegevens bij te houden die u wilt zien. Metrische gegevens voor cache worden gerapporteerd met behulp van verschillende rapportageintervallen, waaronder afgelopen uur, vandaag, afgelopen week en aangepast. Selecteer aan de linkerkant de metrische waarde in de sectie Bewaking . In elke grafiek met metrische gegevens worden de gemiddelde, minimum- en maximumwaarden weergegeven voor elke metrische waarde in de grafiek, en sommige metrische gegevens geven een totaal weer voor het rapportage-interval.

Elke metriek bevat twee versies: Met één metrische waarde worden de prestaties voor de hele cache meten en voor caches die gebruikmaken van clustering. Een tweede versie van de metrische waarde, die in de naam is opgenomen (Shard 0-9) , meet de prestaties voor één shard in een cache. Als een cache bijvoorbeeld vier shards heeft, Cache Hits is het totale aantal treffers voor de hele cache en Cache Hits (Shard 3) meet alleen de treffers voor die shard van de cache.

Selecteer in het menu Resource aan de linkerkant metrische gegevens onder Bewaking. Hier ontwerpt u uw eigen grafiek voor uw cache, waarmee u het metrische type en het aggregatietype definieert.

Typen aggregatie

Zie Aggregatie configureren voor algemene informatie over aggregatietypen.

Onder normale cacheomstandigheden zijn gemiddelde en max vergelijkbaar omdat alleen het primaire knooppunt deze metrische gegevens verzendt. In een scenario waarin het aantal verbonden clients snel verandert, geeft Max, Average en Min verschillende waarden weer, wat ook verwacht gedrag is.

De typen Aantal en Som kunnen misleidend zijn voor bepaalde metrische gegevens, zoals verbonden clients. In plaats daarvan kunt u het beste kijken naar de metrische gemiddelden en niet naar de metrische gegevens som.

Notitie

Zelfs wanneer de cache niet actief is zonder verbonden actieve clienttoepassingen, ziet u mogelijk wat cacheactiviteit, zoals verbonden clients, geheugengebruik en bewerkingen die worden uitgevoerd. De activiteit is normaal in de werking van de cache.

Voor niet-geclusterde caches kunt u het beste de metrische gegevens gebruiken zonder het achtervoegsel Instance Based. Als u bijvoorbeeld de serverbelasting voor uw cache-exemplaar wilt controleren, gebruikt u de metrische serverbelasting.

Gebruik daarentegen voor geclusterde caches de metrische gegevens met het achtervoegsel Instance Based. Voeg vervolgens een splitsing of filter toe aan ShardId. Als u bijvoorbeeld de serverbelasting van shard 1 wilt controleren, gebruikt u de metrische serverbelasting (op basis van exemplaar) en past u vervolgens filter ShardId = 1 toe.

Kusto-query's

U kunt bewakingsgegevens analyseren in de Azure Monitor-logboeken/Log Analytics-opslag met behulp van de Kusto-querytaal (KQL).

Belangrijk

Wanneer u Logboeken selecteert in het menu van de service in de portal, wordt Log Analytics geopend met het querybereik ingesteld op de huidige service. Dit bereik betekent dat logboekquery's alleen gegevens uit dat type resource bevatten. Als u een query wilt uitvoeren die gegevens uit andere Azure-services bevat, selecteert u Logboeken in het menu Azure Monitor . Zie Log-querybereik en tijdsbereik in Azure Monitor Log Analytics voor meer informatie.

Zie de interface voor Log Analytics-query's voor een lijst met algemene query's voor elke service.

Log Analytics-query's

Notitie

Zie Overzicht van Log Analytics in Azure Monitor voor een zelfstudie over het gebruik van Azure Log Analytics. Houd er rekening mee dat het maximaal 90 minuten kan duren voordat logboeken worden weergegeven in Logboek analtyics.

Hier volgen enkele basisquery's die u als modellen kunt gebruiken.

Query's voor Basic-, Standard- en Premium-lagen

• Azure Cache voor Redis clientverbindingen per uur binnen het opgegeven IP-adresbereik:

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)

• Unieke IP-adressen van Redis-clients die zijn verbonden met de cache:

ACRConnectedClientList
| summarize count() by ClientIp

Query's voor Enterprise- en Enterprise Flash-lagen

• Azure Cache voor Redis verbindingen per uur binnen het opgegeven IP-adresbereik:

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)

• Azure Cache voor Redis verificatieaanvragen per uur binnen het opgegeven IP-adresbereik:

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 AuthencationRequestsCount = count() by TimeRange = bin(EventTime, 1h)

• Unieke IP-adressen van Redis-clients die zijn verbonden met de cache:

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

• Mislukte verificatiepogingen naar de cache

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

Waarschuwingen

Azure Monitor-waarschuwingen melden u proactief wanneer er specifieke voorwaarden worden gevonden in uw bewakingsgegevens. Met waarschuwingen kunt u problemen in uw systeem identificeren en oplossen voordat uw klanten ze opmerken. Zie Azure Monitor-waarschuwingen voor meer informatie.

Er zijn veel bronnen van algemene waarschuwingen voor Azure-resources. Zie Voorbeeldquery's voor logboekwaarschuwingen voor voorbeelden van veelvoorkomende waarschuwingen voor Azure-resources. De site Azure Monitor Baseline Alerts (AMBA) biedt een semi-geautomatiseerde methode voor het implementeren van belangrijke metrische platformwaarschuwingen, dashboards en richtlijnen. De site is van toepassing op een voortdurend uitbreidende subset van Azure-services, inclusief alle services die deel uitmaken van de Azure Landing Zone (ALZ).

Het algemene waarschuwingsschema standaardiseert het verbruik van Azure Monitor-waarschuwingsmeldingen. Zie Algemeen waarschuwingsschema voor meer informatie.

Typen waarschuwingen

U kunt een waarschuwing ontvangen voor elke metrische gegevensbron of logboekgegevensbron in het Azure Monitor-gegevensplatform. Er zijn veel verschillende typen waarschuwingen, afhankelijk van de services die u bewaakt en de bewakingsgegevens die u verzamelt. Verschillende typen waarschuwingen hebben verschillende voordelen en nadelen. Zie Het juiste waarschuwingstype voor bewaking kiezen voor meer informatie.

In de volgende lijst worden de typen Azure Monitor-waarschuwingen beschreven die u kunt maken:

• Metrische waarschuwingen evalueren met regelmatige tussenpozen resourcegegevens. Metrische gegevens kunnen metrische platformgegevens, aangepaste metrische gegevens, logboeken van Azure Monitor zijn geconverteerd naar metrische gegevens of metrische Gegevens van Application Insights. Metrische waarschuwingen kunnen ook meerdere voorwaarden en dynamische drempelwaarden toepassen.
• Met logboekwaarschuwingen kunnen gebruikers een Log Analytics-query gebruiken om resourcelogboeken met een vooraf gedefinieerde frequentie te evalueren.
• Waarschuwingen voor activiteitenlogboeken worden geactiveerd wanneer een nieuwe gebeurtenis van het activiteitenlogboek plaatsvindt die overeenkomt met gedefinieerde voorwaarden. Resource Health-waarschuwingen en Service Health-waarschuwingen zijn waarschuwingen voor activiteitenlogboeken die rapporteren over uw service en resourcestatus.

Sommige Azure-services ondersteunen ook waarschuwingen voor slimme detectie, Prometheus-waarschuwingen of aanbevolen waarschuwingsregels.

Voor sommige services kunt u op schaal bewaken door dezelfde waarschuwingsregel voor metrische gegevens toe te passen op meerdere resources van hetzelfde type dat in dezelfde Azure-regio aanwezig is. Afzonderlijke meldingen worden verzonden voor elke bewaakte resource. Zie Meerdere resources bewaken met één waarschuwingsregel voor ondersteunde Azure-services en -clouds.

Waarschuwingen maken

U kunt instellen dat u waarschuwingen ontvangt op basis van metrische gegevens en activiteitenlogboeken. Met Azure Monitor kunt u een waarschuwing configureren om het volgende te doen bij activering:

• Een e-mailmelding verzenden
• Een webhook aanroepen
• Een logische Azure-app aanroepen

Als u waarschuwingen voor uw cache wilt configureren, selecteert u Waarschuwingen onder Bewaking in het menu Resource.

algemene waarschuwingsregels Azure Cache voor Redis

De volgende tabel bevat algemene en aanbevolen waarschuwingsregels voor Azure Cache voor Redis.

Waarschuwingstype	Voorwaarde	Beschrijving
Metrische gegevens	Latentie van het 99e percentiel	Waarschuwing over de slechtste latentie van opdrachten aan de serverzijde in Azure Cache voor Redis exemplaren. Latentie wordt gemeten met behulp van PING opdrachten en reactietijden bijhouden. Houd de status van uw cache-exemplaar bij om te zien of langlopende opdrachten de latentieprestaties in gevaar brengen.
Metrische gegevens	Hoog Server Load gebruik of pieken	Hoge serverbelasting betekent dat de Redis-server geen aanvragen kan bijhouden, wat leidt tot time-outs of trage reacties. Waarschuwingen maken voor metrische gegevens over serverbelastingsgegevens om vroeg op de hoogte te worden gesteld van mogelijke gevolgen.
Metrische gegevens	Hoog netwerkbandbreedtegebruik	Als de server de beschikbare bandbreedte overschrijdt, worden gegevens niet zo snel naar de client verzonden. Bij clientaanvragen kan een time-out optreden omdat de gegevens niet snel genoeg van de server naar de client kunnen worden gepusht. Stel waarschuwingen in voor netwerkbandbreedtelimieten aan de serverzijde met behulp van de Cache Read en Cache Write tellers.

Advisor-aanbevelingen

Voor sommige services, als er kritieke omstandigheden of aanstaande wijzigingen optreden tijdens resourcebewerkingen, wordt een waarschuwing weergegeven op de pagina Serviceoverzicht in de portal. Meer informatie en aanbevolen oplossingen voor de waarschuwing vindt u in Advisor-aanbevelingen onder Bewaking in het linkermenu. Tijdens normale bewerkingen worden er geen aanbevelingen van advisor weergegeven.

Zie het overzicht van Azure Advisor voor meer informatie over Azure Advisor.

In de volgende schermopname ziet u een aanbeveling van advisor voor een Azure Cache voor Redis waarschuwing:

Als u uw cache wilt upgraden, selecteert u Nu upgraden om de prijscategorie te wijzigen en uw cache te schalen . Zie De juiste laag kiezen voor meer informatie over het kiezen van een prijscategorie.

Gerelateerde inhoud

• Zie Azure Cache voor Redis bewakingsgegevensreferentie voor een verwijzing naar de metrische gegevens, logboeken en andere belangrijke waarden die zijn gemaakt voor Azure Cache voor Redis.
• Zie Azure-resources bewaken met Azure Monitor voor algemene informatie over het bewaken van Azure-resources.