Az Azure Monitor-riasztások típusai

Ez a cikk a létrehozható Azure Monitor-riasztások típusait ismerteti, és segít megérteni, hogy mikor érdemes használni az egyes riasztástípusokat.

Négy riasztástípus létezik:

A megfelelő riasztástípus kiválasztása

Ez a táblázat segíthet eldönteni, hogy milyen típusú riasztást használjon. A díjszabással kapcsolatos további információkért tekintse meg a díjszabási oldalt.

Riasztás típusa Mikor érdemes használni? Díjszabási információk
Metrikariasztás A metrikaadatok tárolása a 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 módosításra nincs szükség. Javasoljuk, hogy metrikariasztásokat használjon, ha a figyelni kívánt adatok elérhetők a metrikaadatokban. Minden metrikariasztási szabályt a figyelt idősorok száma alapján számítunk fel.
Naplóriasztás A naplóriasztásokkal speciális logikai műveleteket hajthat végre az adatokon. Ha a monitorozni kívánt adatok elérhetők a naplókban, vagy speciális logikát igényelnek, a KQL robusztus funkcióival naplóriasztások használatával módosíthatja az adatokat. Minden naplóriasztási szabály számlázása a napló lekérdezésének kiértékelési időköze alapján történik (a gyakoribb lekérdezéskiértékelés magasabb költséggel jár). Emellett a nagy léptékű monitorozáshoz konfigurált naplóriasztások esetében a költség a lekérdezésből származó 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 naplózá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 jelezhetik, 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 lapon olvasható.
Prometheus-riasztások (előzetes verzió) A Prometheus-riasztások elsősorban a Kubernetes-fürtök (köztük az AKS) teljesítményével és állapotával kapcsolatos riasztásokhoz használatosak. A riasztási szabályok a PromQL-en alapulnak, amely egy nyílt forráskód lekérdezési nyelv. A Prometheus-riasztások az előzetes verzió időszakában díjmentesen vehetők igénybe.

Metrikákhoz kapcsolódó riasztások

A metrikariasztási szabályok az erőforrás-metrikák feltételeinek rendszeres időközönként történő kiértékelésével figyelik az erőforrásokat. Ha a feltételek teljesülnek, riasztás aktiválódik. A metrikaidősorok egy adott időszakban 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:

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

  • Egyetlen erőforrás, például egy virtuális gép. A támogatott erőforrástípusokról ebben a cikkben olvashat.
  • Több azonos típusú erőforrás ugyanabban az Azure-régióban, például egy erőforráscsoportban.

Több feltétel

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 figyeléséhez, és riasztást is készíthet, ha a "Százalékos processzorhasználat meghaladja a 90%-ot" és a "Várólista hossza meghaladja a 300 elemet". Ha egy riasztási szabálynak több feltétele van, a riasztás akkor aktiválódik, ha a riasztási szabályban szereplő összes feltétel teljesül, és akkor oldódik fel, ha a feltételek legalább egyike már nem teljesül három egymást követő ellenőrzés esetén.

A cél szűkítése Dimenziók használatával

A dimenziók olyan név-érték párok, amelyek több adatot tartalmaznak a metrikaértékről. A dimenziók használatával szűrheti a metrikákat, és figyelheti az adott idősorokat ahelyett, hogy az összes dimenziós érték összesítését figyeli. A tárfiók Tranzakciók metrikája például rendelkezhet olyan API-névdimenzióval, amely az egyes tranzakciók által meghívott API nevét tartalmazza (például GetBlob, DeleteBlob, PutPage). Dönthet úgy, hogy riasztást aktivál, ha bármilyen API-névben nagy számú tranzakció szerepel (ez az összesített adatok), vagy dimenziókkal tovább bonthatja azt riasztásra, ha adott API-nevek esetében a tranzakciók száma magas. Ha egynél több dimenziót használ, a metrikariasztási szabály több dimenzióértéket is monitorozhat egy metrika különböző dimenzióiból. A riasztási szabály külön figyeli az összes dimenzióérték-kombinációt. Ebben a cikkben részletes útmutatást talál a dimenziók metrikariasztási szabályokban való használatáról.

Erőforrás-központú riasztások létrehozása dimenziók szerinti felosztással

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

Dönthet úgy is, hogy nem osztja fel a elemet, ha egy feltételt több erőforrásra szeretne alkalmazni a hatókörben. Ha például riasztást szeretne aktiválni, 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

A 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. A rendszer minden monitorozott erőforráshoz külön értesítéseket küld.

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

Szolgáltatás Globális Azure Államigazgatás Kína
Virtuális gépek* Igen Igen Yes
SQL Server-adatbázisok Igen Igen Yes
Rugalmas SQL Server-készletek Igen Igen Yes
NetApp-fájlok kapacitáskészlete Igen Igen Yes
NetApp-fájlok kötetei Igen Igen Yes
Kulcstartók Igen Igen Yes
Azure Cache for Redis Igen Igen Yes
Azure Stack Edge-eszközök Igen Igen Yes
Recovery Services-tárolók Igen Nem Nem
Azure Database for PostgreSQL – rugalmas kiszolgálók Igen Igen Yes

Megjegyzés

A több erőforrásból álló metrikariasztások nem támogatottak a következő forgatókönyvekben:

  • Riasztások a virtuális gépek vendégmetrikáiról
  • Riasztások a virtuális gépek hálózati metrikáiról (Network In Total, Network Out Total, Inbound Flows, Outbound Flows, Inbound Flows Maximum Creation Rate, Outbound Flows Maximum Creation Rate, Outbound Flows Maximum Creation Rate).

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 (egy Azure-régióban lévő) virtuális gépek listája
  • egy előfizetés egy vagy több erőforráscsoportjában lévő összes virtuális gép (egy Azure-régióban)
  • az előfizetésben lévő összes virtuális gép (egy Azure-régióban)

Dinamikus küszöbértékek

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

  • A metrikák előzményeinek megismerése
  • 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.
  • A lehetséges szolgáltatásproblémákat jelző anomáliák felismerése
  • A metrika legmegfelelőbb küszöbértékének kiszámítása

A Machine Learning folyamatosan új adatokat használ a további információk és a küszöbérték pontosabbá tétele érdekében. Mivel a rendszer idővel alkalmazkodik a metrikák viselkedéséhez, és a mintától való eltérésen alapuló riasztásokat is, nem kell ismernie az egyes metrikák "megfelelő" küszöbértékét.

A dinamikus küszöbértékek a következőket segítik:

  • Skálázható riasztások létrehozása több száz metrikasorhoz egyetlen riasztási szabmánnyal. Ha kevesebb riasztási szabálya van, kevesebb időt tölt a 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
  • Metrikariasztások konfigurálása magas szintű fogalmak használatával, a metrikával kapcsolatos széles körű tartományi ismeretek nélkül
  • A várt mintával nem rendelkező zajos (alacsony pontosságú) vagy széles (alacsony visszahívási) küszöbértékek megelőzése
  • Kezelje a zajos metrikákat (például a gép processzor- vagy memóriahasználatát) és az alacsony szórású metrikákat (például a rendelkezésre állást és a hibaarányt).

Ebben a cikkben részletes útmutatást talál a dinamikus küszöbértékek metrikariasztási szabályokban való használatáról.

Naplóriasztások

A naplóriasztási szabály egy Log Analytics-lekérdezéssel figyeli az erőforrásokat az erőforrásnaplók meghatározott gyakorisággal történő 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 manipulálhatja a naplóadatokat.

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

  • Egyetlen erőforrás, például egy virtuális gép.
  • Több azonos típusú erőforrás ugyanabban az Azure-régióban, például egy erőforráscsoportban. Ez jelenleg a kiválasztott erőforrástípusokhoz érhető el.
  • Több erőforrás erőforrásközi lekérdezéssel.

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

  • Táblasorok: 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ételeket.
  • Numerikus oszlop kiszámítása: A numerikus oszlopokon alapuló számítások tetszőleges számú erőforrást tartalmazhatnak. Például a processzorhasználat százalékos értéke.

Beállíthatja, hogy a naplóriasztások állapotalapúak vagy állapot nélküliek -e (jelenleg előzetes verzióban).

Megjegyzés

A napló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ésével. Mivel a naplók részben strukturált adatok, eredendően rejtettebbek, mint a virtuális gépek szívverésére vonatkozó adatok metrikaadatai. 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. A naplókból adatokat küldhet a metrikatárolóba a naplók metrikariasztásaival.

Dimenziók a naplóriasztási szabályokban

A dimenziók használatával napló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. A rendszer minden példányt külön-külön figyel, és minden példányról értesítést küld.

Felosztás dimenziók szerint a naplóriasztási szabályokban

Ha több Azure-erőforráson szeretné monitorozni ugyanazt a feltételt, dimenziók szerinti felosztást használhat. A dimenziók szerinti felosztással 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 a kombinációk numerikus vagy sztringoszlopok használatával történő csoportosításával. Az Azure-erőforrásazonosító oszlop felosztása a megadott erőforrást a riasztási célhelyre osztja. Dönthet úgy is, hogy nem osztja fel a elemet, ha egy feltételt több erőforrásra szeretne alkalmazni a hatókörben. Ha például riasztást szeretne aktiválni, ha az erőforráscsoport hatókörében legalább öt gép processzorhasználata meghaladja a 80%-ot.

Az API használata

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

Megjegyzés

A Log Analytics-naplóriasztásokat korábban az örökölt Log Analytics Alert API-val kellett kezelni. További információ az aktuális ScheduledQueryRules API-ra való váltásról.

Riasztások naplózása az Azure-számlán

A naplóriasztások a microsoft.insights/scheduledqueryrules erőforrás-szolgáltatónál jelennek meg a következőkkel:

  • Naplóriasztások az Application Insightsban pontos erőforrásnévvel, erőforráscsoporttal és riasztási tulajdonságokkal.
  • Naplóriasztások a Log Analyticsben pontos erőforrásnévvel, erőforráscsoporttal és riasztási tulajdonságokkal; az scheduledQueryRules API-val történő létrehozáskor.
  • Az örökölt Log Analytics API-ból létrehozott napló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óriasztásai rejtett erőforrásnévvel, valamint erőforráscsoport- és riasztástulajdonságokkal jelennek meg.

Megjegyzés

A nem támogatott erőforráskarakterek (például <, >, %, &, , ?, /) helyett a rejtett erőforrásnevekben a _ karakter jelenik meg, és ez a számlázási adatokban is megjelenik.

Tevékenységnapló-riasztások

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

É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:
    • Az éles erőforráscsoportban lévő összes virtuális gép törlődik.
    • Minden új szerepkör hozzá lesz rendelve egy felhasználóhoz az előfizetésében.
  • Szolgáltatásállapot-esemény következik be. Szolgáltatásállapot 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ő időpontban hozhat létre:

  • A tevékenységnapló eseménykategóriáinak bármelyike, kivéve a riasztási eseményeket.
  • 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 a Azure Portal 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 szolgáltatáskimaradásokról, a tervezett karbantartási tevékenységekről és egyéb egészségügyi tanácsadásokról, mert 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 a Service Health-riasztások beállítása, amelyek értesítik Önt az előnyben részesített kommunikációs csatornák használatáról, ha 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.

riasztások Resource Health

Resource Health riasztások tevékenységriasztások. Resource Health áttekintés 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. 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-e. Ha egy erőforrás állapota nem megfelelő, Resource Health további információkat elemez a probléma forrásának meghatározásához. Emellett olyan műveletekről is jelentést készít, amelyeket Microsoft a probléma megoldásához, és azonosítja azokat a műveleteket, amelyeket meg tud oldani.

Intelligens észlelési riasztások

Miután beállította az Application Insightst a projekthez, amikor az alkalmazás létrehoz egy bizonyos minimális 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 mértékben lesznek hajlamosak a sikertelenségre, mint mások; és a teljes meghibásodási arány a terhelés növekedésével nőhet. 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 hibák arányát. Az Application Insights közel valós időben automatikusan riasztást küld, ha a webalkalmazás rendellenesen emelkedik a sikertelen kérések arányában.

Ahogy a webalkalmazásból az Application Insightsba kerülnek az adatok, az intelligens észlelés összehasonlítja az aktuális viselkedést az elmúlt napokban látott mintákkal. Ha a korábbi teljesítményhez képest rendellenes hibaarány-növekedés tapasztalható, a rendszer elemzést indít el. A probléma osztályozásának és diagnosztizálásának megkönnyítése érdekében a riasztás részletei között található a hibák és a kapcsolódó alkalmazásadatok jellemzőinek elemzése. A további diagnosztika érdekében az Application Insights portálra mutató hivatkozások is találhatók. A szolgáltatásnak nincs szüksége beállításra és konfigurálásra, mivel gépi tanulási algoritmusokkal előrejelzi a normál hibaarányt.

Bár a metrikariasztások azt jelzik, hogy probléma merülhet fel, az intelligens észlelés elindítja a diagnosztikai munkát, és 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, így gyorsan megtalálhatja a probléma gyökerét.

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 (előzetes verzió)

A Prometheus-riasztások az Azure Monitor által felügyelt Prometheus-szolgáltatásokban tárolt metrikaértékeken alapulnak. Akkor aktiválódnak, ha egy PromQL-lekérdezés eredménye igazra oldódik fel. A Prometheus-riasztások más riasztástípusokhoz hasonlóan jelennek meg és kezelhetők, amikor aktiválódnak, de prometheus-szabálycsoporttal vannak konfigurálva. A részletekért lásd: Szabálycsoportok az Azure Monitor által felügyelt szolgáltatásban a Prometheushoz .

Következő lépések