Olvasás angol nyelven

Megosztás a következőn keresztül:

A riasztási szabály megfelelő típusának kiválasztása

  • Cikk

Ez a cikk a létrehozható Azure Monitor-riasztások típusait ismerteti. Segít megérteni, hogy mikor érdemes használni az egyes típusú riasztásokat. A díjszabással kapcsolatos további információkért tekintse meg a díjszabási oldalt.

A riasztások típusai a következők:

Az Azure Monitor-riasztások típusai

Riasztástípus Mikor érdemes használni? Díjszabási információk
Metrikariasztás A metrikaadatok tárolása már előre kiszámított rendszerben történik. A metrikariasztások akkor hasznosak, ha olyan adatokról szeretne riasztást kapni, amelyekhez kevés vagy semmilyen manipuláció nem szükséges. Metrikariasztásokat használjon, ha a figyelni kívánt adatok elérhetők a metrikaadatokban. Minden metrikariasztási szabály díja a figyelt idősorok száma alapján történik.
Naplókeresési riasztás A naplókeresési riasztásokkal speciális logikai műveleteket hajthat végre az adatokon. Ha a figyelni kívánt adatok elérhetők a naplókban, vagy speciális logikát igényelnek, a Kusto lekérdezésnyelv (KQL) robusztus funkcióit használhatja az adatok kezelésére a naplókeresési riasztások használatával. Minden naplókeresési riasztási szabály számlázása a napló lekérdezés kiértékelésének időköze alapján történik. A lekérdezések gyakoribb kiértékelése magasabb költséget eredményez. A dimenziók szerinti felosztással történő nagy léptékű monitorozáshoz konfigurált naplókeresési riasztások esetében a költség a lekérdezésből eredő dimenziók által létrehozott idősorok számától is függ.
Tevékenységnapló-riasztás A tevékenységnaplók az erőforrásokon végrehajtott összes művelet ellenőrzését biztosítják. Tevékenységnapló-riasztások használatával riasztást jeleníthet meg, ha egy adott esemény történik egy erőforrással, például újraindítással, leállítással vagy egy erőforrás létrehozásával vagy törlésével. A Service Health-riasztások és a Resource Health-riasztások jelzik, ha probléma merül fel az egyik szolgáltatással vagy erőforrással kapcsolatban. További tájékoztatás a díjszabási oldalon olvasható.
Prometheus-riasztások A Prometheus-riasztások a Prometheus által felügyelt Azure Monitor-szolgáltatásokban tárolt Prometheus-metrikák riasztására szolgálnak. A riasztási szabályok a PromQL nyílt forráskódú lekérdezési nyelvén alapulnak. A Prometheus riasztási szabályai csak a szabályok által lekérdezett adatokért lesznek felszámítva. További tájékoztatás a díjszabási oldalon olvasható.

Metrikariasztások

A metrikariasztási szabály rendszeres időközönként kiértékeli az erőforrások metrikáinak feltételeit. Ha a feltételek teljesülnek, riasztás aktiválódik. A metrikaidősorok egy adott időszak alatt rögzített metrikaértékek sorozatai.

Az alábbi metrikák használatával hozhat létre szabályokat:

A metrikariasztási szabályok a következő funkciókat tartalmazzák:

  • Egyetlen erőforráshoz több feltételt is használhat egy riasztási szabályon.
  • Részletességet több metrikadimenzió monitorozásával adhat hozzá.
  • Dinamikus küszöbértékeket használhat, amelyeket a gépi tanulás vezérel.
  • Beállíthatja, hogy a metrikariasztások állapotalapúak vagy állapot nélküliek-e. A metrikariasztások alapértelmezés szerint állapotalapúak.

A metrikariasztási szabály célja a következő lehet:

Több feltétel alkalmazása metrikariasztási szabályra

Ha egyetlen erőforráshoz hoz létre riasztási szabályt, több feltételt is alkalmazhat. Létrehozhat például egy riasztási szabályt egy Azure-beli virtuális gép és riasztás figyeléséhez, ha a "Százalékos CPU-érték meghaladja a 90%-ot" és a "Várólista hossza több mint 300 elem". Ha egy riasztási szabály több feltételt is biztosít, a riasztás akkor aktiválódik, ha a riasztási szabályban szereplő összes feltétel igaz, és akkor szűnik meg, ha a feltételek közül legalább egy már nem igaz három egymást követő ellenőrzésre.

A cél szűkítése dimenziókkal

A dimenziók metrikariasztási szabályokban való használatára vonatkozó utasításokért lásd : Több idősor monitorozása egyetlen metrikariasztási szabályban.

Ugyanazon feltétel monitorozása több erőforráson dimenziók szerinti felosztással

Ha ugyanazt a feltételt több Azure-erőforráson szeretné monitorozni, dimenziók szerinti felosztást használhat. Ha dimenziók szerinti felosztást használ, erőforrás-központú riasztásokat hozhat létre nagy méretekben egy előfizetéshez vagy erőforráscsoporthoz. A riasztások csoportosítási kombinációkkal külön riasztásokra vannak felosztva. Az Azure-erőforrás-azonosító oszlop felosztásával a megadott erőforrás a riasztási célhelyre kerül.

Dönthet úgy is, hogy nem osztja fel a feltételeket, ha a hatókörben több erőforrásra is alkalmazni szeretné a feltételt. Előfordulhat például, hogy riasztást szeretne küldeni, ha az erőforráscsoport hatókörében legalább öt gép processzorhasználata meghaladja a 80%-ot.

Több erőforrás monitorozása egyetlen riasztási szabmánnyal

Nagy léptékű monitorozáshoz ugyanazt a metrikariasztási szabályt több, azonos típusú erőforrásra is alkalmazhatja az ugyanazon Azure-régióban található erőforrások esetében. Minden figyelt erőforráshoz külön értesítéseket küld a rendszer.

Az alábbi Azure-felhőkben ezekhez a szolgáltatásokhoz tartozó platformmetrikák támogatottak:

Szolgáltatás Erőforrás-szolgáltató Globális Azure Államigazgatás Kína
Virtual machines (Virtuális gépek) "Microsoft.Compute/virtualMachines" Igen Igen Igen
SQL Server-adatbázisok "Microsoft.Sql/servers/databases" Igen Igen Igen
Rugalmas SQL Server-készletek "Microsoft.Sql/servers/elasticpools" Igen Igen Igen
NetApp-fájlok kapacitáskészlete "Microsoft.NetApp/netAppAccounts/capacityPools" Igen Igen Igen
NetApp-fájlok kötetei "Microsoft.NetApp/netAppAccounts/capacityPools/volumes" Igen Igen Igen
Azure Key Vault "Microsoft.KeyVault/vaults" Igen Igen Igen
Azure Cache for Redis "Microsoft.Cache/redis" Igen Igen Igen
Azure Stack Edge-eszközök (Ehhez az erőforráshoz nincs konkrét erőforrás-szolgáltató. A Stack edge-eszközök működése miatt a metrikák több erőforrás-szolgáltatótól is lekérhetők. Az erőforrással kapcsolatos riasztásokkal kapcsolatos további részletekért tekintse meg ezt a dokumentációt: Riasztások áttekintése az Azure Stack Edge-en) Igen Igen Igen
Helyreállítási tárak "Microsoft.RecoveryServices/Vaults" Igen Nem Nem
Rugalmas Azure Database for PostgreSQL-kiszolgáló "Microsoft.DBforPostgreSQL/flexibleServers" Igen Igen Igen
Csupasz fém gépek (Operátor Nexus) "Microsoft.NetworkCloud/bareMetalMachines" Igen Igen Igen
Tárolóberendezések (operátori nexus) "Microsoft.NetworkCloud/storageAppliances" Igen Igen Igen
Fürtök (operátori nexus) "Microsoft.NetworkCloud/fürtök" Igen Igen Igen
Hálózati eszközök (operátori nexus) Microsoft.NetworkCloud/l2Networks, Microsoft.NetworkCloud/l3Networks Igen Igen Igen
Adatgyűjtési szabályok "Microsoft.Insights/datacollectionrules" Igen Igen Igen

Megjegyzés

A több erőforrású metrikariasztások nem támogatottak a következőkhöz:

  • Riasztás a virtuális gép vendégmetrikáiról.
  • Riasztás a virtuális gép hálózati metrikáiról (Összes bejövő hálózati forgalom, Összes kimenő hálózati forgalom, Bejövő forgalomfolyamok, Kimenő forgalomfolyamok, Bejövő forgalomfolyamok maximális létrehozási gyakorisága és Kimenő forgalomfolyamok maximális létrehozási gyakorisága).

A figyelés hatókörét háromféleképpen adhatja meg egyetlen metrikariasztási szabálysal. Virtuális gépek esetén például a hatókört a következőképpen adhatja meg:

  • Az előfizetésen belüli egyetlen Azure-régióban lévő virtuális gépek listája.
  • Egy Azure-régió összes virtuális gépe egy előfizetés egy vagy több erőforráscsoportjában.
  • Egy előfizetés egy Azure-régiójában lévő összes virtuális gép.

Fejlett gépi tanulás alkalmazása dinamikus küszöbértékekkel

A dinamikus küszöbértékek fejlett gépi tanulást használnak:

  • Ismerje meg a metrikák előzményi viselkedését.
  • Azonosítsa a mintákat, és alkalmazkodjon a metrikák időbeli változásaihoz, például óránkénti, napi vagy heti mintákhoz.
  • Felismerheti a lehetséges szolgáltatásproblémákat jelző anomáliákat.
  • Számítsa ki a metrika legmegfelelőbb küszöbértékét.

A gépi tanulás folyamatosan új adatokat használ a további információkhoz, és pontosabbá teszi a küszöbértéket. Mivel a rendszer idővel alkalmazkodik a metrikák viselkedéséhez és a mintától való eltéréseken alapuló riasztásokhoz, nem kell ismernie az egyes metrikák "megfelelő" küszöbértékét.

A dinamikus küszöbértékek segítenek:

  • Skálázható riasztások létrehozása több száz metrikasorozathoz egyetlen riasztási szabmánnyal. Ha kevesebb riasztási szabályt használ, kevesebb időt tölt riasztási szabályok létrehozásával és kezelésével.
  • Szabályok létrehozása anélkül, hogy ismernie kellene a konfigurálni kívánt küszöbértéket.
  • A metrikariasztásokat magas szintű fogalmak használatával konfigurálhatja anélkül, hogy a metrika széles körű tartományismerettel rendelkezik.
  • Megakadályozza a zajos (kis pontosságú) vagy széles (alacsony visszahívási) küszöbértékeket, amelyek nem rendelkeznek elvárt mintával.
  • Kezelje a zajos metrikákat (például a gép cpu-ját vagy memóriáját) és az alacsony szórású metrikákat (például a rendelkezésre állást és a hibaarányt).

A dinamikus küszöbértékeket a dinamikus küszöbértékek metrikariasztási szabályokban való használatával kapcsolatos részletes utasításokért tekinti meg.

Naplókeresési riasztások

A naplókeresési riasztási szabály egy Log Analytics-lekérdezéssel figyeli az erőforrásokat egy megadott gyakoriságú erőforrásnaplók kiértékeléséhez. Ha a feltételek teljesülnek, riasztás aktiválódik. Mivel Log Analytics-lekérdezéseket is használhat, speciális logikai műveleteket hajthat végre az adatokon, és a robusztus KQL-funkciókkal kezelheti a naplóadatokat.

A naplókeresési riasztási szabály célja a következő lehet:

  • Egyetlen erőforrás, például virtuális gép.
  • Egyetlen erőforrástároló, például erőforráscsoport vagy előfizetés.
  • Több erőforrás, amely erőforrásközi lekérdezést használ.

A naplókeresési riasztások két különböző dolgot mérhetnek, amelyek különböző figyelési forgatókönyvekhez használhatók:

  • Táblázatsorok: A visszaadott sorok száma felhasználható olyan események kezelésére, mint a Windows-eseménynaplók, a Syslog és az alkalmazáskivüldők.
  • Numerikus oszlop kiszámítása: A numerikus oszlopokon alapuló számítások tetszőleges számú erőforrást tartalmazhatnak. Ilyen például a processzorhasználat százalékos aránya.

Beállíthatja, hogy a naplókeresési riasztások állapotalapúak vagy állapot nélküliek-e.
Vegye figyelembe, hogy az állapotalapú naplókeresési riasztások a következő korlátozásokkal rendelkeznek:

  • kiértékelésenként legfeljebb 300 riasztást aktiválhatnak.
  • legfeljebb 5000 riasztással rendelkezhet a fired riasztási feltétellel.

Megjegyzés

A naplókeresési riasztások akkor működnek a legjobban, ha adott adatokat próbál észlelni a naplókban, szemben a naplókban lévő adatok hiányának észlelésekor. Mivel a naplók félig strukturált adatok, ezek eredendően látensebbek, mint a virtuálisgép-szívveréshez hasonló adatok mérőszámai. A naplókban lévő adatok hiányának észlelésekor előforduló hibák elkerülése érdekében fontolja meg a metrikariasztások használatát. Naplókból adatokat küldhet a metrikatárolóba a naplókhoz tartozó metrikariasztások használatával.

Erőforrás több példányának monitorozása dimenziókkal

Dimenziók használatával naplókeresési riasztási szabályokat hozhat létre egy erőforrás több példányának értékeinek monitorozásához egyetlen szabmánnyal. Figyelheti például a cpu-használatot a webhelyet vagy alkalmazást futtató több példányon. Minden példányt külön figyelünk. Az egyes példányokhoz értesítéseket küld a rendszer.

Ugyanazon feltétel monitorozása több erőforráson dimenziók szerinti felosztással

Ha ugyanazt a feltételt több Azure-erőforráson szeretné monitorozni, dimenziók szerinti felosztást használhat. Ha dimenziók szerinti felosztást használ, erőforrás-központú riasztásokat hozhat létre nagy méretekben egy előfizetéshez vagy erőforráscsoporthoz. A riasztások különálló riasztásokra vannak felosztva, ha kombinációkat csoportosítanak numerikus vagy sztringoszlopok használatával. Az Azure-erőforrásazonosító oszlop felosztásával a megadott erőforrás a riasztási célhelyre kerül.

Dönthet úgy is, hogy nem osztja fel a feltételeket, ha a hatókörben több erőforrásra is alkalmazni szeretné a feltételt. Előfordulhat például, hogy riasztást szeretne küldeni, ha az erőforráscsoport hatókörében legalább öt gép processzorhasználata meghaladja a 80%-ot.

Az API használata naplókeresési riasztási szabályokhoz

Új szabályok kezelése a munkaterületeken az ScheduledQueryRules API használatával.

Megjegyzés

Az örökölt Log Analytics Alert API-val kezelt Log Analytics naplókeresési riasztásai. További információ az aktuális ScheduledQueryRules API-ra való váltásról.

Naplókeresési riasztások az Azure-számlán

A naplókeresési riasztások az erőforrás-szolgáltató microsoft.insights/scheduledqueryrules alatt jelennek meg a következőkkel:

  • Naplókeresési riasztások az Application Insightsban a pontos erőforrásnévvel, valamint az erőforráscsoport és a riasztás tulajdonságaival.
  • A Log Analytics naplókeresési riasztásai pontos erőforrásnévvel és erőforráscsoport- és riasztási tulajdonságokkal jelennek meg, amikor az ütemezettQueryRules API használatával jönnek létre.
  • Az örökölt Log Analytics API-ból létrehozott naplókeresési riasztások nem követik nyomon az Azure-erőforrásokat, és nem kényszerítettek egyedi erőforrásneveket. Ezek a riasztások továbbra is rejtett erőforrásokként jönnek létre microsoft.insights/scheduledqueryrules , amelyek erőforrás-elnevezési struktúrával <WorkspaceName>|<savedSearchId>|<scheduleId>|<ActionId>rendelkeznek. Az örökölt API naplókeresési riasztásai az előző rejtett erőforrásnévvel, valamint az erőforráscsoport és a riasztás tulajdonságaival jelennek meg.

Megjegyzés

Nem támogatott erőforráskarakterek, például <: , >%, &; , ? és / helyett egy aláhúzásjel (_) a rejtett erőforrásnevekben. Ez a karakterváltozás a számlázási adatokban is tükröződik.

Tevékenységnapló-alapú riasztások

A tevékenységnapló-riasztások úgy figyelik az erőforrásokat, hogy ellenőrzik a tevékenységnaplókat egy új tevékenységnapló-eseményhez, amely megfelel a megadott feltételeknek.

Érdemes lehet tevékenységnapló-riasztásokat használni az ilyen típusú forgatókönyvekhez:

  • Ha egy adott művelet egy adott erőforráscsoportban vagy előfizetésben lévő erőforrásokon történik. Előfordulhat például, hogy értesítést szeretne kapni a következő esetekben:
    • Egy éles erőforráscsoportban lévő virtuális gép törlődik.
    • Az új szerepkörök egy felhasználóhoz vannak rendelve az előfizetésben.
  • Service Health-esemény történik. A Service Health-események közé tartoznak az előfizetés erőforrásaira vonatkozó incidensek és karbantartási események értesítései.

Tevékenységnapló-riasztást a következőn hozhat létre:

  • A tevékenységnapló eseménykategóriáinak bármelyike, a riasztási eseményeken kívül.
  • A JSON-objektum legfelső szintű tulajdonságában található tevékenységnapló-események.

A tevékenységnapló-riasztási szabályok Azure-erőforrások, ezért azure Resource Manager-sablonnal hozhatók létre. Ezek az Azure Portalon is létrehozhatók, frissíthetők vagy törölhetők.

A tevékenységnapló-riasztások csak abban az előfizetésben figyelik az eseményeket, amelyben a riasztás létrejön.

Service Health-riasztások

A Service Health-riasztások tevékenységriasztások. A Service Health tájékoztatja a kimaradásokról, a tervezett karbantartási tevékenységekről és más állapot-tanácsadásokról, mivel a hitelesített Service Health-élmény tudja, hogy mely szolgáltatásokat és erőforrásokat használja jelenleg.

A Service Health használatának legjobb módja, ha Service Health-riasztásokat állít be, amelyek értesítést küldenek Önnek az előnyben részesített kommunikációs csatornák használatával, amikor a szolgáltatásproblémák, a tervezett karbantartás vagy egyéb változások hatással lehetnek a használt Azure-szolgáltatásokra és régiókra.

Resource Health-riasztások

A Resource Health-riasztások tevékenységriasztások. A Resource Health áttekintése segítséget nyújt az Azure-erőforrásokat érintő szolgáltatásproblémák diagnosztizálásában és támogatásában. Jelentést készít az erőforrásai aktuális és korábbi állapotáról.

A Resource Health különböző Azure-szolgáltatások jelzéseire támaszkodik annak felméréséhez, hogy egy erőforrás kifogástalan állapotban van-e. Ha egy erőforrás nem megfelelő, a Resource Health további információkat elemez a probléma forrásának meghatározásához. Emellett a Microsoft által a probléma megoldására tett műveletekről is beszámol, és azonosítja a megoldáshoz szükséges műveleteket.

Intelligens észlelési riasztások

Miután beállította az Application Insightst a projekthez, és az alkalmazás létrehoz egy bizonyos mennyiségű adatot, az intelligens észlelés 24 órát vesz igénybe az alkalmazás normál viselkedésének megismeréséhez. Az alkalmazás teljesítménye jellemző viselkedési mintával rendelkezik. Egyes kérések vagy függőségi hívások nagyobb valószínűséggel lesznek sikertelenek, mint mások, és a terhelés növekedésével a teljes hibaarány növekedhet.

Az intelligens észlelés gépi tanulással keresi meg ezeket az anomáliákat. Az intelligens észlelés figyeli az alkalmazástól kapott adatokat, és különösen a meghibásodási arányokat. Az Application Insights közel valós időben automatikusan riasztást küld, ha a webalkalmazás rendellenesen megemeli a sikertelen kérelmek arányát.

Mivel az adatok a webalkalmazásból kerülnek be az Application Insightsba, az intelligens észlelés összehasonlítja az aktuális viselkedést az elmúlt néhány napban látott mintákkal. Ha a korábbi teljesítményhez képest rendellenesen emelkedik a hibaarány, a rendszer elemzést indít el.

A problémák osztályozásának és diagnosztizálásának megkönnyítése érdekében a riasztás részletei között a hibák jellemzőinek és a kapcsolódó alkalmazásadatoknak az elemzése is elérhető. A további diagnosztika érdekében az Application Insights portálra mutató hivatkozások is találhatók. A funkciónak nincs szüksége beállításra vagy konfigurációra, mert gépi tanulási algoritmusokkal előrejelzi a normál meghibásodási arányt.

Bár a metrikariasztások azt jelzik, hogy probléma merülhet fel, az intelligens észlelés elindítja a diagnosztikai munkát. Elvégzi az elemzés nagy részét, amit egyébként saját magának kellene elvégeznie. Az eredményeket szépen csomagolja, ami segít a probléma gyökerének gyors eléréséhez.

Az intelligens észlelés a felhőben vagy saját kiszolgálókon üzemeltetett webalkalmazások esetében működik, amelyek alkalmazáskéréseket vagy függőségi adatokat hoznak létre.

Prometheus-riasztások

A Prometheus-riasztások az Azure Monitor által felügyelt Prometheus-szolgáltatásokban tárolt metrikák monitorozására szolgálnak. A Prometheus riasztási szabályai a Prometheus-szabálycsoportok részeként vannak konfigurálva. Akkor aktiválódnak, ha egy PromQL-kifejezés eredménye igaznak oldódik. Az aktivált Prometheus-riasztások más riasztástípusokhoz hasonlóan jelennek meg és kezelhetők.

Következő lépések