Az Azure Cache for Redis monitorozása

Ez a cikk a következőket ismerteti:

• A szolgáltatáshoz gyűjthető monitorozási adatok típusai.
• Az adatok elemzésének módjai.

Feljegyzés

Ha már ismeri ezt a szolgáltatást és/vagy az Azure Monitort, és csak tudni szeretné, hogyan elemezheti a figyelési adatokat, tekintse meg a cikk végén található Elemzés szakaszt.

Ha olyan kritikus alkalmazásokkal és üzleti folyamatokkal rendelkezik, amelyek Az Azure-erőforrásokra támaszkodnak, figyelnie kell és riasztásokat kell kapnia a rendszeréről. Az Azure Monitor szolgáltatás a rendszer minden összetevőjéből gyűjti és összesíti a metrikákat és naplókat. Az Azure Monitor áttekintést nyújt a rendelkezésre állásról, a teljesítményről és a rugalmasságról, és értesíti Önt a problémákról. A monitorozási adatok beállításához és megtekintéséhez használhatja az Azure Portalt, a PowerShellt, az Azure CLI-t, a REST API-t vagy az ügyfélkódtárakat.

• Az Azure Monitorral kapcsolatos további információkért tekintse meg az Azure Monitor áttekintését.
• Az Azure-erőforrások általános monitorozásával kapcsolatos további információkért lásd : Azure-erőforrások monitorozása az Azure Monitorral.

Elemzések

Az Azure egyes szolgáltatásai beépített monitorozási irányítópulttal rendelkeznek az Azure Portalon, amely kiindulópontot biztosít a szolgáltatás monitorozásához. Ezeket az irányítópultokat elemzéseknek nevezzük, és az Azure Monitor Insights Hubjában, az Azure Portalon találhatja meg őket.

Az Azure Cache for Redis elemzési szolgáltatása a következő élményt nyújtja:

• Az Azure Cache for Redis-erőforrások méretarányos szemszögéből az előfizetések között. Csak a kiértékelni kívánt előfizetésekre és erőforrásokra terjedhet ki szelektíven.
• Az Azure Cache for Redis-erőforrás részletezési elemzése . A problémák diagnosztizálásához megtekintheti a kihasználtság, a hibák, a kapacitás és a műveletek részletes elemzését, vagy részletes áttekintést kaphat a releváns információkról.
• Azure Monitor-munkafüzetsablonokra épülő testreszabás . Módosíthatja a megjelenített metrikákat, és módosíthatja vagy beállíthatja a korlátoknak megfelelő küszöbértékeket. Mentheti a módosításokat egy egyéni munkafüzetben, majd rögzítheti a munkafüzetdiagramokat az Azure-irányítópultokon.

Az Azure Cache for Redis elemzési adatai nem követelik meg, hogy bármit engedélyezhessen vagy konfiguráljon. Az Azure Cache for Redis-információk alapértelmezés szerint összegyűjtve vannak, és az elemzések eléréséhez nincs külön díj.

Az Azure Cache for Redis elemzéseinek megtekintéséről, konfigurálásáról és testreszabásáról az Azure Cache for Redis Azure Monitor insights című témakörben olvashat.

Erőforrástípusok

Az Azure az erőforrástípusok és azonosítók fogalmát használja az előfizetések minden elemének azonosítására. Az erőforrástípusok az Azure-ban futó összes erőforrás erőforrásazonosítóinak is részét képezik. A virtuális gépek egyik erőforrástípusa például az Microsoft.Compute/virtualMachines. A szolgáltatások és a hozzájuk kapcsolódó erőforrástípusok listáját az Erőforrás-szolgáltatók című témakörben találja.

Az Azure Monitor hasonlóan rendszerezi az alapvető monitorozási adatokat metrikákba és naplókba az erőforrástípusok, más néven névterek alapján. Különböző metrikák és naplók érhetők el a különböző erőforrástípusokhoz. Előfordulhat, hogy a szolgáltatás több erőforrástípushoz is társítva van.

Az Azure Cache for Redis erőforrástípusairól további információt az Azure Cache for Redis monitorozási adathivatkozásában talál.

Adattárolás

Azure Monitor esetén:

• A metrikák adatait az Azure Monitor metrikák adatbázisa tárolja.
• A naplóadatok tárolása az Azure Monitor naplók tárolójában történik. A Log Analytics egy eszköz az Azure Portalon, amely le tudja kérdezni ezt az áruházat.
• Az Azure-tevékenységnapló egy külön tároló, amelynek saját felülete van az Azure Portalon.

A metrikák és a tevékenységnaplók adatait igény szerint átirányíthatja az Azure Monitor-naplók tárolójába. Ezután a Log Analytics használatával lekérdezheti az adatokat, és összehasonlíthatja azokat más naplóadatokkal.

Számos szolgáltatás diagnosztikai beállításokkal küldhet metrikákat és naplóadatokat az Azure Monitoron kívüli más tárolóhelyekre. Ilyenek például az Azure Storage, a üzemeltetett partnerrendszerek és a nem Azure-beli partnerrendszerek az Event Hubs használatával.

Az Azure Monitor adatainak tárolásáról az Azure Monitor adatplatformja nyújt részletes tájékoztatást.

Az Azure Monitor platformmetrikái

Az Azure Monitor platformmetrikát biztosít a legtöbb szolgáltatáshoz. Ezek a metrikák a következők:

• Egyedileg definiálva minden névtérhez.
• Az Azure Monitor idősoros metrikák adatbázisában tárolva.
• Könnyű és képes közel valós idejű riasztások támogatására.
• Egy erőforrás teljesítményének nyomon követésére szolgál az idő függvényében.

Gyűjtemény: Az Azure Monitor automatikusan gyűjti a platformmetrikákat. Nem igényel konfigurálást.

Útválasztás: A platformmetrikákat általában az Azure Monitor-naplókhoz/Log Analyticshez is átirányíthatja, így más naplóadatokkal is lekérdezheti őket. További információt a Metrikák diagnosztikai beállításában talál. A szolgáltatás diagnosztikai beállításainak konfigurálásához lásd : Diagnosztikai beállítások létrehozása az Azure Monitorban.

Az Azure Monitor összes erőforrásához gyűjthető metrikák listájáért tekintse meg az Azure Monitor támogatott metrikáit.

Az Azure Cache for Redishez elérhető metrikák listájáért tekintse meg az Azure Cache for Redis monitorozási adatreferenciáját.

Azure Monitor-erőforrásnaplók

Az erőforrásnaplók betekintést nyújtanak az Azure-erőforrások által végrehajtott műveletekbe. A naplók automatikusan jönnek létre, de a mentésükhöz vagy lekérdezésükhöz az Azure Monitor naplóihoz kell irányítani őket. A naplók kategóriákba vannak rendezve. Egy adott névtér több erőforrásnapló-kategóriával is rendelkezhet.

Gyűjtemény: Az erőforrásnaplók csak akkor lesznek összegyűjtve és tárolva, ha diagnosztikai beállítást hoz létre, és a naplókat egy vagy több helyre irányítja. Diagnosztikai beállítás létrehozásakor meg kell adnia, hogy milyen kategóriájú naplókat kíván gyűjteni. A diagnosztikai beállításokat többféleképpen is létrehozhatja és karbantarthatja, beleértve az Azure Portalt is, programozott módon, és bár az Azure Policyt.

Útválasztás: A javasolt alapértelmezett beállítás az erőforrásnaplók Azure Monitor-naplókba való átirányítása, hogy más naplóadatokkal is lekérdezhesse őket. Más helyek is elérhetők, például az Azure Storage, az Azure Event Hubs és bizonyos Microsoft monitorozási partnerek. További információ: Azure-erőforrásnaplók és erőforrásnapló-célhelyek.

Az erőforrásnaplók gyűjtésével, tárolásával és útválasztásával kapcsolatos részletes információkért tekintse meg az Azure Monitor diagnosztikai beállításait.

Az Azure Monitor összes elérhető erőforrásnapló-kategóriájának listáját lásd: Támogatott erőforrásnaplók az Azure Monitorban.

Az Azure Monitor összes erőforrásnaplója ugyanazokkal a fejlécmezőkkel rendelkezik, amelyeket a szolgáltatásspecifikus mezők követnek. A közös sémát az Azure Monitor erőforrásnapló-sémája ismerteti.

Az elérhető erőforrásnapló-kategóriákról, a hozzájuk tartozó Log Analytics-táblákról és az Azure Cache for Redis naplós sémáiról lásd az Azure Cache for Redis monitorozási adatreferenciáját.

Azure Cache for Redis-erőforrásnaplók

Az Azure Cache for Redisben két lehetőség érhető el a naplózáshoz:

• Gyorsítótármetrikák ("AllMetrics") naplók metrikái az Azure Monitorból
• A kapcsolatnaplók biztonsági és diagnosztikai célból naplóznak kapcsolatokat a gyorsítótárhoz.

Gyorsítótár-metrikák

Az Azure Cache for Redis számos olyan metrikát bocsát ki, mint például Server Load a naplózható és Connections per Second hasznos. Az AllMetrics beállítás kiválasztásával ezek és más gyorsítótármetrikák naplózhatók. Beállíthatja, hogy mennyi ideig őrizze meg a metrikákat.

Kapcsolatnaplók

Az Azure Cache for Redis az Azure diagnosztikai beállításaival naplózza a gyorsítótár ügyfélkapcsolatainak adatait. A diagnosztikai beállítás naplózása és elemzése segít megérteni, hogy ki csatlakozik a gyorsítótárakhoz és a kapcsolatok időbélyegét. A naplóadatok felhasználhatók a biztonsági incidens hatókörének azonosítására és biztonsági naplózási célokra.

A kapcsolatnaplók némileg eltérő implementációkkal, tartalommal és beállítási eljárásokkal rendelkeznek a különböző Azure Cache for Redis-szintekhez. További részletekért tekintse meg az Azure Monitor diagnosztikai beállításait.

Azure-tevékenységnapló

A tevékenységnapló előfizetésszintű eseményeket tartalmaz, amelyek nyomon követik az egyes Azure-erőforrások műveleteit az adott erőforráson kívülről látható módon; például új erőforrás létrehozása vagy virtuális gép indítása.

Gyűjtemény: A tevékenységnapló-események automatikusan létrejönnek, és egy külön tárolóban lesznek összegyűjtve az Azure Portalon való megtekintéshez.

Útválasztás: Tevékenységnapló-adatokat küldhet az Azure Monitor-naplókba, hogy más naplóadatokkal együtt elemezhesse azokat. Más helyek is elérhetők, például az Azure Storage, az Azure Event Hubs és bizonyos Microsoft monitorozási partnerek. A tevékenységnapló irányításával kapcsolatos további információkért tekintse meg az Azure-tevékenységnapló áttekintését.

Monitorozási adatok elemzése

A monitorozási adatok elemzésére számos eszköz áll rendelkezésre.

Azure Monitor-eszközök

Az Azure Monitor a következő alapvető eszközöket támogatja:

• A Metrics Explorer egy eszköz az Azure Portalon, amely lehetővé teszi az Azure-erőforrások mérőszámainak megtekintését és elemzését. További információ: Metrikák elemzése az Azure Monitor metrikakezelőjével.

• A Log Analytics egy eszköz az Azure Portalon, amely lehetővé teszi a naplóadatok lekérdezését és elemzését a Kusto lekérdezési nyelv (KQL) használatával. További információ: A napló lekérdezéseinek első lépései az Azure Monitorban.

• A tevékenységnapló, amely egy felhasználói felülettel rendelkezik az Azure Portalon a megtekintéshez és az alapszintű keresésekhez. A részletesebb elemzéshez át kell irányítania az adatokat az Azure Monitor-naplókba, és összetettebb lekérdezéseket kell futtatnia a Log Analyticsben.

Az összetettebb vizualizációt lehetővé tevő eszközök a következők:

• Irányítópultok , amelyek lehetővé teszik, hogy különböző típusú adatokat egyesítsen egyetlen panelen az Azure Portalon.
• Az Azure Portalon létrehozható munkafüzetek, testreszabható jelentések. A munkafüzetek tartalmazhatnak szöveget, metrikákat és napló lekérdezéseket.
• Grafana, egy nyíltplatformos eszköz, amely kiválóan működik az irányítópultokon. A Grafana használatával olyan irányítópultokat hozhat létre, amelyek az Azure Monitoron kívül több forrásból származó adatokat is tartalmaznak.
• A Power BI egy üzleti elemzési szolgáltatás, amely interaktív vizualizációkat biztosít különböző adatforrásokban. A Power BI-t úgy konfigurálhatja, hogy automatikusan importálja a naplóadatokat az Azure Monitorból a vizualizációk előnyeinek kihasználásához.

Az Azure Monitor exportálási eszközei

Az Azure Monitorból más eszközökre is lekérheti az adatokat az alábbi módszerekkel:

• Metrikák: Metrikákhoz használja a REST API-t metrikaadatok kinyeréséhez az Azure Monitor metrika-adatbázisából. Az API támogatja a szűrőkifejezéseket a lekért adatok finomításához. További információ: Azure Monitor REST API-referencia.

• Naplók: Használja a REST API-t vagy a kapcsolódó ügyfélkódtárakat.

• Egy másik lehetőség a munkaterület adatexportálása.

Az Azure MonitorHOZ készült REST API használatának megkezdéséhez tekintse meg az Azure monitoring REST API-útmutatót.

Azure Cache for Redis-metrikák

Az Azure Cache for Redis-példányok metrikáit a Redis INFO paranccsal gyűjtjük össze. A metrikákat percenként körülbelül két alkalommal gyűjtjük össze, hogy megjeleníthetők legyenek a metrikák diagramjaiban, és riasztási szabályok alapján kiértékelhetők legyenek. Az adatok megőrzésének időtartamáról és egy másik adatmegőrzési szabályzat konfigurálásáról az Azure Monitor-naplók adatmegőrzési és archiválási útmutatójában olvashat.

A metrikák jelentése több jelentési intervallummal történik, például az Elmúlt óra, a Ma, az Elmúlt hét és az Egyéni. Minden metrikadiagram megjeleníti a diagram egyes metrikáinak átlagát, minimális és maximális értékeit, egyes metrikák pedig a jelentési időköz összegét.

Minden metrika két verziót tartalmaz: egy metrika a teljes gyorsítótár teljesítményét méri, valamint a fürtözést használó gyorsítótárak esetében. A metrika második verziója, amely magában foglalja (Shard 0-9) a nevet, a gyorsítótárban lévő egyetlen szegmens teljesítményét méri. Ha például egy gyorsítótár négy szegmensből áll, Cache Hits az a teljes gyorsítótárra vonatkozó találatok teljes száma, és Cache Hits (Shard 3) csak a gyorsítótár adott szegmensének találatait méri.

Gyorsítótármetrikák megtekintése

Az Azure Cache for Redis Azure Monitor-metrikáit közvetlenül az Azure Cache for Redis-erőforrásból tekintheti meg az Azure Portalon.

Válassza ki az Azure Cache for Redis-példányt a portálon. Az Áttekintés lapon az előre definiált memóriahasználati és Redis-kiszolgálói terhelésfigyelési diagramok láthatók. Ezek a diagramok hasznos összegzések, amelyek lehetővé teszik a gyorsítótár állapotának gyors áttekintését.

Részletesebb információkért az Erőforrás menü Figyelés szakaszában az alábbi hasznos Azure Cache for Redis-metrikákat figyelheti.

Azure Cache for Redis metrika	További információ
Hálózati sávszélesség-használat	Gyorsítótár teljesítménye – elérhető sávszélesség
Csatlakoztatott ügyfelek	Alapértelmezett Redis-kiszolgálókonfiguráció – maximális ügyfelek
Kiszolgáló terhelése	Redis Server Load
Memóriahasználat	Gyorsítótár teljesítménye – méret

Saját metrikák létrehozása

Létrehozhat saját egyéni diagramot a látni kívánt metrikák nyomon követéséhez. A gyorsítótármetrikák több jelentési időköz használatával jelennek meg, például az Elmúlt óra, a Ma, az Elmúlt hét és az Egyéni. A bal oldalon válassza ki a metrikát a Figyelés szakaszban. Minden metrikadiagram megjeleníti a diagram egyes metrikáinak átlagát, minimális és maximális értékeit, egyes metrikák pedig a jelentési időköz összegét.

Minden metrika két verziót tartalmaz: egy metrika a teljes gyorsítótár teljesítményét méri, valamint a fürtözést használó gyorsítótárak esetében. A metrika második verziója, amely magában foglalja (Shard 0-9) a nevet, a gyorsítótárban lévő egyetlen szegmens teljesítményét méri. Ha például egy gyorsítótár négy szegmensből áll, Cache Hits az a teljes gyorsítótárra vonatkozó találatok teljes száma, és Cache Hits (Shard 3) csak a gyorsítótár adott szegmensének találatait méri.

A bal oldali Erőforrás menüben válassza a Metrika elemet a Figyelés csoportban. Itt saját diagramot tervezhet a gyorsítótárhoz, meghatározva a metrika típusát és az összesítés típusát.

Összesítési típusok

Az összesítési típusokkal kapcsolatos általános információkért tekintse meg az összesítés konfigurálását ismertető témakört.

Normál gyorsítótár-körülmények között az Átlag és a Max hasonló, mert csak az elsődleges csomópont bocsátja ki ezeket a metrikákat. Olyan esetekben, amikor a csatlakoztatott ügyfelek száma gyorsan változik, a Max, az Átlag és a Min különböző értékeket jelenít meg, ami szintén elvárt viselkedés.

A Darabszám és a Sum típus félrevezető lehet bizonyos metrikák, például a csatlakoztatott ügyfelek esetében. Ehelyett az Átlag metrikákat érdemes megnézni, nem pedig az Összeg metrikákat.

Feljegyzés

Még akkor is, ha a gyorsítótár inaktív, és nincs csatlakoztatott aktív ügyfélalkalmazás, előfordulhat, hogy bizonyos gyorsítótár-tevékenységek, például a csatlakoztatott ügyfelek, a memóriahasználat és a műveletek végrehajtása folyamatban van. A tevékenység normális a gyorsítótár működésében.

Nemclustered gyorsítótárak esetén a legjobb, ha a metrikákat utótag Instance Basednélkül használja. Ha például ellenőrizni szeretné a gyorsítótárpéldány kiszolgálói terhelését, használja a metrikakiszolgáló terhelését.

Ezzel szemben a fürtözött gyorsítótárak esetében használja a metrikákat az utótaggal Instance Based. Ezután adjon hozzá egy felosztást vagy szűrőt.ShardId Például az 1. szegmens kiszolgálói terhelésének ellenőrzéséhez használja a metrikakiszolgáló terhelését (példányalapú), majd alkalmazza a ShardId = 1 szűrőt.

Kusto-lekérdezések

A monitorozási adatokat az Azure Monitor Naplók/ Log Analytics-tárolóban a Kusto lekérdezési nyelv (KQL) használatával elemezheti.

Fontos

Amikor a portálon a szolgáltatás menüjében a Naplók lehetőséget választja, megnyílik a Log Analytics, és a lekérdezés hatóköre az aktuális szolgáltatásra van állítva. Ez a hatókör azt jelenti, hogy a napló lekérdezései csak az adott típusú erőforrásból származó adatokat tartalmazzák. Ha más Azure-szolgáltatásokból származó adatokat tartalmazó lekérdezést szeretne futtatni, válassza a Naplók lehetőséget az Azure Monitor menüjében. A részletekért tekintse meg az Azure Monitor Log Analytics napló lekérdezési hatókörét és időtartományát.

A szolgáltatások gyakori lekérdezéseinek listáját a Log Analytics lekérdezési felületén találja.

Log Analytics-lekérdezések

Feljegyzés

Az Azure Log Analytics használatával kapcsolatos oktatóanyagért tekintse meg a Log Analytics áttekintését az Azure Monitorban. Ne feledje, hogy akár 90 percig is eltarthat, amíg a naplók megjelennek a Log Analtyicsben.

Íme néhány alapszintű lekérdezés, amelyet modellként kell használni.

Lekérdezések alapszintű, standard és prémium szintű szintekhez

• Az Azure Cache for Redis-ügyfélkapcsolatok óránként a megadott IP-címtartományon belül:

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)

• A gyorsítótárhoz csatlakoztatott egyedi Redis-ügyfél IP-címek:

ACRConnectedClientList
| summarize count() by ClientIp

Nagyvállalati és Vállalati Flash-szintek lekérdezései

• Az Azure Cache for Redis-kapcsolatok óránként a megadott IP-címtartományon belül:

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)

• Az Azure Cache for Redis hitelesítési kérései óránként a megadott IP-címtartományon belül:

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)

• A gyorsítótárhoz csatlakoztatott egyedi Redis-ügyfél IP-címek:

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

• Sikertelen hitelesítési kísérletek a gyorsítótárba

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

Riasztások

Az Azure Monitor-riasztások proaktív módon értesítik, ha adott feltételek találhatók a monitorozási adatokban. A riasztások lehetővé teszik a rendszer problémáinak azonosítását és kezelését, mielőtt az ügyfelek észrevennénk őket. További információ: Azure Monitor-riasztások.

Az Azure-erőforrásokra vonatkozó gyakori riasztások számos forrásból állnak. Az Azure-erőforrásokra vonatkozó gyakori riasztások példáiért lásd a naplóriasztási lekérdezéseket. Az Azure Monitor Alapszintű riasztások (AMBA) webhelye félautomata módszert biztosít a fontos platformmetrika-riasztások, irányítópultok és irányelvek implementálására. A webhely az Azure-szolgáltatások folyamatosan bővülő részhalmazára vonatkozik, beleértve az Azure Landing Zone (ALZ) részét képező összes szolgáltatást is.

A gyakori riasztási séma szabványosítja az Azure Monitor riasztási értesítéseinek használatát. További információ: Gyakori riasztási séma.

Riasztások típusai

Az Azure Monitor adatplatformon bármilyen metrika- vagy naplóadatforrásról riasztást készíthet. A figyelt szolgáltatásoktól és a gyűjtött monitorozási adatoktól függően számos különböző típusú riasztás létezik. A különböző típusú riasztások különböző előnyökkel és hátrányokkal rendelkeznek. További információ: A megfelelő figyelési riasztástípus kiválasztása.

Az alábbi lista a létrehozható Azure Monitor-riasztások típusait ismerteti:

• A metrikariasztások rendszeres időközönként értékelik ki az erőforrásmetrikákat. A metrikák lehetnek platformmetrikák, egyéni metrikák, az Azure Monitorból metrikákká konvertált naplók vagy Application Insights-metrikák. A metrikariasztások több feltételt és dinamikus küszöbértéket is alkalmazhatnak.
• A naplóriasztások lehetővé teszik, hogy a felhasználók Log Analytics-lekérdezéssel kiértékeljék az erőforrásnaplókat egy előre meghatározott gyakorisággal.
• A tevékenységnapló-riasztások akkor aktiválnak, ha egy új tevékenységnapló-esemény következik be, amely megfelel a megadott feltételeknek. A Resource Health-riasztások és a Service Health-riasztások olyan tevékenységnapló-riasztások, amelyek jelentést jelentenek a szolgáltatásról és az erőforrás állapotáról.

Egyes Azure-szolgáltatások intelligens észlelési riasztásokat, Prometheus-riasztásokat vagy ajánlott riasztási szabályokat is támogatnak.

Egyes szolgáltatások esetében nagy léptékben monitorozhat, ha ugyanazt a metrikariasztási szabályt több, azonos típusú erőforrásra alkalmazza, amelyek ugyanabban az Azure-régióban léteznek. Minden figyelt erőforráshoz külön értesítéseket küld a rendszer. A támogatott Azure-szolgáltatásokról és felhőkről lásd : Több erőforrás monitorozása egyetlen riasztási szabmánnyal.

Riasztások létrehozása

A mérőszámok és tevékenységnaplók alapján beállíthatja, hogy milyen riasztásokat szeretne kapni. Az Azure Monitor segítségével konfigurálhat riasztásokat, amelyek aktiválása esetén a követező műveletek végrehajtására kerülhet sor:

• E-mail-értesítés küldése
• Webhook meghívása
• Egy Azure Logic App-alkalmazás meghívása

A gyorsítótár riasztásainak konfigurálásához válassza a Riasztások lehetőséget az Erőforrás menü Figyelés területén.

Az Azure Cache for Redis gyakori riasztási szabályai

Az alábbi táblázat az Azure Cache for Redis általános és ajánlott riasztási szabályait sorolja fel.

Riasztástípus	Feltétel	Leírás
Metrika	99. percentilis késés	Riasztás a kiszolgálóoldali parancsok legrosszabb késéséről az Azure Cache for Redis-példányokban. A késés mérése parancsokkal és a válaszidők nyomon követésével PING történik. Kövesse nyomon a gyorsítótárpéldány állapotát, és ellenőrizze, hogy a hosszan futó parancsok veszélyeztetik-e a késési teljesítményt.
Metrika	Magas Server Load kihasználtság vagy kiugró értékek	A magas kiszolgálóterhelés azt jelenti, hogy a Redis-kiszolgáló nem tud lépést tartani a kérésekkel, ami időtúllépésekhez vagy lassú válaszokhoz vezet. Riasztásokat hozhat létre a kiszolgálói terhelési metrikák metrikáival kapcsolatban, hogy korai értesítést kapjon a lehetséges hatásokról.
Metrika	Nagy hálózati sávszélesség-használat	Ha a kiszolgáló túllépi a rendelkezésre álló sávszélességet, a rendszer nem küldi el az adatokat olyan gyorsan az ügyfélnek. Az ügyfélkérések túlléphetik az időkorlátot amiatt, hogy a kiszolgáló nem képes elég gyorsan leküldeni az adatokat az ügyfélnek. Állítson be riasztásokat a kiszolgálóoldali hálózati sávszélesség korlátaihoz a számlálók és Cache Write a Cache Read számlálók használatával.

Az Advisor javaslatai

Egyes szolgáltatások esetében, ha az erőforrás-műveletek során kritikus feltételek vagy közelgő változások lépnek fel, riasztás jelenik meg a portál szolgáltatásáttekintő lapján. A riasztással kapcsolatos további információkat és javasolt javításokat a bal oldali menü Figyelés területén található Advisor-javaslatok között találja. Normál műveletek során nem jelennek meg tanácsadói javaslatok.

Az Azure Advisorról további információt az Azure Advisor áttekintésében talál.

Az alábbi képernyőképen egy Azure Cache for Redis-riasztásra vonatkozó tanácsadói javaslat látható:

A gyorsítótár frissítéséhez válassza a Frissítés most lehetőséget a tarifacsomag módosításához és a gyorsítótár méretezéséhez. A tarifacsomag kiválasztásáról további információt a megfelelő szint kiválasztása című témakörben talál.

Kapcsolódó tartalom

• Az Azure Cache for Redishez létrehozott metrikák, naplók és egyéb fontos értékek referenciáját az Azure Cache for Redis monitorozási adatreferenciájában talál.
• Az Azure-erőforrások monitorozásával kapcsolatos általános részletekért tekintse meg az Azure-erőforrások Monitorozása az Azure Monitorral című témakört.