Az Azure Monitor riasztásaival kapcsolatos problémák elhárítása

Ez a cikk az Azure Monitor-riasztások és -értesítések gyakori problémáit ismerteti. Az Azure Monitor-riasztások proaktív módon értesítik, ha fontos feltételek találhatók a monitorozási adatokban.

Az Azure-metrika- vagy naplókeresési riasztások hibaelhárításával kapcsolatos további információkért lásd:

• Azure Monitor-metrikariasztások hibaelhárítása
• Azure Monitor naplókeresési riasztások hibaelhárítása

Hibaelhárítás előtt

Ha a riasztás a kívánt módon aktiválódik, de a megfelelő értesítések nem a várt módon működnek, először tesztelje a műveletcsoportot , hogy biztosan megfelelően legyen konfigurálva.

Ellenkező esetben a cikk többi részében található információk segítségével háríthatja el a problémát.

Nem kaptam meg a várt e-mailt

Ha aktivált riasztást lát az Azure Portalon, de nem kapta meg a konfigurált e-mailt, kövesse az alábbi lépéseket:

1. Letiltotta az e-mailt egy riasztásfeldolgozási szabály?

   Ennek az ellenőrzéséhez kattintson az aktivált riasztásra a portálon, és tekintse meg a letiltott műveletcsoportok előzménylapját:

   

2. A művelet típusa „E-mail – Azure Resource Manager-szerepkör”?

   Ez a művelet csak az előfizetés hatókörében lévő, felhasználó vagy csoport típusú Azure Resource Manager-szerepkör-hozzárendeléseket vizsgálja. Győződjön meg arról, hogy a szerepkört az előfizetés szintjén rendelte hozzá, és ne az erőforrás vagy az erőforráscsoport szintjén.

3. Az e-mail-kiszolgálója és postaládája fogad külső e-maileket?

   Ellenőrizze, hogy nincsenek-e letiltva az alábbi három címről érkező e-mailek:

   • azure-noreply@microsoft.com
   • azureemail-noreply@microsoft.com
   • alerts-noreply@mail.windowsazure.com

   A belső levelezőlisták vagy terjesztési listák gyakran letiltják a külső e-mail-címekről érkező e-maileket. Győződjön meg arról, hogy engedélyezi a fenti e-mail-címekről érkező leveleket. A teszteléshez adjon hozzá egy normál munkahelyi e-mail-címet (nem levelezési listát) a műveleti csoporthoz, és ellenőrizze, hogy érkeznek-e riasztások a címre.

4. Az e-mailt a beérkezett e-mailekre vonatkozó szabályok vagy levélszemétszűrő dolgozta fel?

   Ellenőrizze, hogy nincsenek-e a beérkezett e-mailekre vonatkozó olyan szabályok, amelyek az ilyen e-maileket más mappába irányítják át vagy törlik. A beérkezett e-mailekre vonatkozó szabályok szűrhetnek például az e-mail feladója, vagy az e-mail tárgyában szereplő szavak alapján is. Emellett ellenőrizze az alábbiakat:

   • Az e-mail-ügyfél levélszemétbeállításai (például Outlook, Gmail)
   • A feladó korlátozza a levelezési kiszolgáló levélszemét-beállításait/karanténbeállításait (például Exchange, Microsoft 365, G-suite)
   • Ha használ e-mail-biztonsági berendezéseket (például Barracudát, Ciscót), azok beállításait.

5. Előfordulhat, hogy véletlenül leiratkozott a műveletcsoportról?

   Feljegyzés

   Ne feledje, ha leiratkozik egy műveletcsoportról, akkor a terjesztési listából származó összes tag is le lesz iratkozik. Továbbra is használhatja a terjesztési lista e-mail-címét. Azonban tájékoztatnia kell a terjesztési listáról a felhasználókat, hogy ha leiratkoznak, nem csak magukról, hanem a teljes terjesztési listáról leiratkoznak. Ehhez érdemes egyenként hozzáadni a műveletcsoport összes felhasználójának e-mail-címét. Egy műveletcsoport legfeljebb 1000 e-mail-címet tartalmazhat. Ezután, ha egy adott felhasználó le szeretne iratkozni, akkor ezt anélkül teheti meg, hogy a többi felhasználót érintené. Azt is láthatja, hogy mely felhasználók iratkoztak le.

   A riasztási e-mailek a műveletcsoportról való leiratkozásra mutató hivatkozást tartalmaznak. Ha ellenőrizni szeretné, hogy véletlenül leiratkozott-e erről a műveletcsoportról, az alábbi módon:

   1. Nyissa meg a műveletcsoportot a portálon, és ellenőrizze az Állapot oszlopot:

   

   2. Keresse meg az e-mailben a leiratkozásra vonatkozó megerősítést:

   

   Az újbóli feliratkozáshoz használja a kapott leiratkozási visszaigazoló e-mailben található hivatkozást, vagy távolítsa el az e-mail-címet a műveletcsoportból, majd adja hozzá újra.

6. Túllépte a szolgáltatási korlátokat azáltal, hogy több e-mailt küldött egyetlen e-mail-címre?

   Az egyes e-mail-címekre egy óránként legfeljebb 100 e-mailes korlátozás vonatkozik. Ha túllépi ezt a küszöbértéket, a rendszer nem küld további e-mail-értesítéseket. Ellenőrizze, hogy kapott-e olyan üzenetet, amely azt jelzi, hogy az e-mail-cím ideiglenesen korlátozott:

   

   Ha nagy mennyiségű értesítést szeretne kapni sebességkorlátozás nélkül, fontolja meg egy másik művelet használatát, például:

   • Webhook
   • Logikai alkalmazás
   • Azure-függvény
   • Automation-runbookok

   Ezen műveletek egyike sem korlátozott.

Nem kaptam meg a várt SMS-t, hanghívást vagy leküldéses értesítést

Ha aktivált riasztást lát a portálon, de nem kapta meg a konfigurált SMS-t, hanghívást vagy leküldéses értesítést, kövesse az alábbi lépéseket:

1. A műveletet riasztásfeldolgozási szabály tiltotta le?

   Ennek az ellenőrzéséhez kattintson az aktivált riasztásra a portálon, és tekintse meg a letiltott műveletcsoportok előzménylapját:

   

   Ha a letiltás nem volt szándékos, módosíthatja, letilthatja vagy törölheti a riasztásfeldolgozási szabályt.

2. SMS/hang: Helyes a telefonszáma?

   Nézze meg, hogy nincsenek-e elírások az SMS-művelet országkódjában vagy telefonszámában.

3. SMS/hang: túllépte a szolgáltatási korlátokat?

   Az SMS-ek és a hanghívások ötpercenként legfeljebb egy értesítésre vannak korlátozva telefonszámonként. Ha túllépi ezt a küszöbértéket, a rendszer elveti az értesítéseket.

   • Hanghívás – ellenőrizze a híváselőzményeit, és ellenőrizze, hogy az előző öt percben más hívása volt-e az Azure-tól.
   • SMS – Ellenőrizze az SMS előzményeit egy üzenetnél, amely jelzi, hogy a telefonszáma korlátozott.

   Ha nagy mennyiségű értesítést szeretne kapni sebességkorlátozás nélkül, fontolja meg egy másik művelet használatát, például:

   • Webhook
   • Logikai alkalmazás
   • Azure-függvény
   • Automation-runbookok

   Ezen műveletek egyike sem korlátozott.

4. SMS: Előfordulhat, hogy véletlenül leiratkozott a műveletcsoportról?

   Nyissa meg az SMS-előzményeket, és ellenőrizze, hogy az adott műveletcsoportból (a DISABLE action_group_short_name válasz használatával) vagy az összes műveletcsoportból (a STOP válasz használatával) letiltotta-e az SMS-kézbesítést.

   Az újbóli feliratkozáshoz küldje el a megfelelő SMS-parancsot (ENABLE action_group_short_name vagy START), vagy távolítsa el az SMS-műveletet a műveletcsoportból, és adja hozzá újra. További információkért lásd az SMS-riasztás viselkedését a műveletcsoportokban.

5. Előfordulhat, hogy véletlenül letiltotta az értesítéseket a telefonján?

   A legtöbb mobiltelefon lehetővé teszi a bizonyos telefonszámokról vagy rövid hívókódokról érkező hívások vagy SMS-ek, vagy a bizonyos alkalmazások (például az Azure mobile app) által küldött leküldéses értesítések letiltását. Ha ellenőrizni szeretné, hogy nem tiltotta-e le véletlenül az értesítéseket a telefonján, keresse meg a telefon operációs rendszerére és a modelljére vonatkozó dokumentációt, vagy végezzen tesztet egy másik telefonnal és telefonszámmal.

A várt művelet nem aktiválódik

Ha aktivált riasztást lát a portálon, de a konfigurált művelet nem aktiválódott, kövesse az alábbi lépéseket:

1. A műveletet letiltotta egy riasztásfeldolgozási szabály?

   Ennek az ellenőrzéséhez kattintson az aktivált riasztásra a portálon, és tekintse meg a letiltott műveletcsoportok előzménylapját:

   

   Ha a letiltás nem volt szándékos, módosíthatja, letilthatja vagy törölheti a riasztásfeldolgozási szabályt.

2. Aktiválta a webhook?

   1. Le van tiltva a forrás IP-címe?

      Adja hozzá a webhook által meghívott IP-címeket az engedélyezési listához.

   2. Megfelelően működik a webhook-végpont?

      Ellenőrizze, hogy a webhook-végpont helyes-e, és hogy a végpont megfelelően működik-e. Tekintse meg a webhook naplóit, vagy instrumentálja úgy a kódját, hogy átvizsgálható legyen (például naplózza a bejövő hasznos adatokat).

   3. A Slack vagy a Microsoft Teams hívásához a megfelelő formátumot használja?
      Ezek a végpontok meghatározott JSON-formátumot várnak el. Kövesse ezeket az utasításokat, hogy inkább egy logikai alkalmazási műveletet konfiguráljon.

   4. A webhook nem válaszol vagy hibát ad vissza?

      A webhook műveleti csoportjai általában az alábbi szabályokat követik, amikor meghívják őket:

      • Webhook meghívása esetén, ha az első hívás meghiúsul, a művelet legalább 1 alkalommal újrapróbálkozott, és legfeljebb ötször (5 újrapróbálkozás) különböző késleltetési időközönként (5, 20, 40 másodperc).
        • Az 1. és 2. kísérlet közötti késleltetés 5 másodperc
        • A 2. és 3. kísérlet közötti késleltetés 20 másodperc
        • A 3. és 4. kísérlet közötti késleltetés 5 másodperc
        • A 4. és 5. kísérlet közötti késleltetés 40 másodperc
        • Az 5. és 6. kísérlet közötti késleltetés 5 másodperc
      • Miután újrapróbálkozott a webhook sikertelen meghívásával, egyetlen műveletcsoport sem hívja meg a végpontot 15 percig.
      • Az újrapróbálkozás logikája feltételezi, hogy a hívás újrapróbálkozható. Az állapotkódok: 408, 429, 503, 504 vagy HttpRequestException, WebExceptionvagy TaskCancellationException engedélyezi a hívás újrapróbáltatását.

A művelet vagy értesítés többször is megtörtént

Ha többször kapott értesítést egy riasztásról (például e-mailről vagy SMS-ről), vagy a riasztás művelete (például webhook vagy Azure-függvény) többször is aktiválódott, kövesse az alábbi lépéseket:

1. Valóban ugyanarról a riasztásról van szó?

   Vannak olyan esetek, amikor több hasonló riasztás is aktiválódik nagyjából ugyanabban az időpontban. Ezért úgy tűnhet, mintha ugyanaz a riasztás aktiválta volna többször a műveleteit. Előfordulhat például, hogy egy tevékenységnapló riasztási szabálya úgy van konfigurálva, hogy az esemény indításakor és befejezésekor (sikeres vagy sikertelen) is aktiváljon, ha nem szűr az eseményállapot-mezőre.

   Ha ellenőrizni szeretné, hogy az érintett műveletek vagy értesítések különböző riasztásokhoz tartoznak-e, tekintse meg a riasztás részleteit, például az időbélyegét és a riasztás azonosítóját vagy korrelációs azonosítóját. Másik megoldásként tekintse meg az aktivált riasztások listáját a portálon. Ebben az esetben a riasztási szabály logikáját kell módosítania, vagy más módon konfigurálnia kell a riasztási forrást.

2. Több műveletcsoportban is megismétlődik a művelet?

   Egy riasztás aktiválásakor a rendszer egymástól függetlenül dolgozza fel annak műveletcsoportjait. Így ha egy művelet (például egy e-mail-cím) több aktivált műveletcsoportban is szerepel, a rendszer műveletcsoportonként egyszer meg fogja hívni.

   A riasztási előzmények lapon ellenőrizheti, hogy mely műveletcsoportok aktiválódtak. Látni fogja, hogy a riasztási szabályban mindkét műveletcsoport definiálva van, és a riasztáshoz műveletcsoportok is hozzáadva riasztásfeldolgozási szabályokkal:

   

A művelet vagy értesítés nem várt tartalommal rendelkezik

1. Volt olyan üzemkimaradás, amely aktiválta a tartalék e-mail-szolgáltató használatát?

   A műveletcsoportok két különböző e-mail-szolgáltatót használnak az e-mail-értesítések kézbesítésének biztosítására. Az elsődleges e-mail-szolgáltató rugalmas és gyors, de időnként kimaradásokat szenved. Kimaradás esetén a másodlagos e-mail-szolgáltató kezeli az e-mail-kérelmeket. A másodlagos szolgáltató csak tartalék megoldás. A szolgáltatói különbségek miatt előfordulhat, hogy a másodlagos szolgáltatótól küldött e-mail csökkentett e-mail-élményt nyújt. A romlás kissé eltérő e-mail-formázást és -tartalmat eredményez. Mivel az e-mail-sablonok eltérnek a két rendszerben, a paritás fenntartása a két rendszerben nem lehetséges.

   A tartalék megoldás által létrehozott értesítések a következő megjegyzést tartalmazzák:

   "Ez egy csökkentett e-mail-élmény. Ez azt jelenti, hogy a formázás ki van kapcsolva, vagy a részletek hiányoznak. A csökkentett e-mail-élményről itt olvashat bővebben."

   Ha az értesítés nem tartalmazza ezt a megjegyzést, és megkapta a riasztást, de úgy véli, hogy néhány mező hiányzik vagy helytelen, ellenőrizze a hasznos adatformátumot.

2. Milyen formátumot használt a riasztási szabály konfigurálásakor?

   Minden művelettípusnak (e-mail, webhook stb.) két formátuma van: az alapértelmezett, az örökölt és a közös sémaformátum. Műveletcsoport létrehozásakor meg kell adnia a művelet formátumát. A műveletcsoportok különböző műveleteinek különböző formátumai lehetnek.

   Webhookműveletek esetén például:

   

   Ellenőrizze, hogy a műveleti szinten megadott formátum az elvárt-e. Előfordulhat például, hogy olyan kódot fejlesztett ki, amely a riasztásokra (webhook, függvény, logikai alkalmazás stb.) reagál, és egy formátumot vár, de a művelet későbbi részében Ön vagy egy másik személy más formátumot adott meg.

   Emellett ellenőrizze a hasznos adatformátumot (JSON) és a gyakori riasztási sémát.

A keresési eredmények nem szerepelnek a naplókeresési riasztások értesítéseiben.

A naplókeresési riasztások API 2021-08-01-es verziójától kezdve a keresési eredmények el lettek távolítva a riasztási értesítések hasznos adataiból. A keresési eredmények csak a régebbi API-verziókkal létrehozott riasztási szabályokhoz érhetők el (2018-04-16). Az új riasztási szabályok létrehozása az Azure Portalon alapértelmezés szerint az újabb verzióval hozza létre a szabályt. A naplóriasztási szabály létrehozási felületének módosításait követve megismerheti a frissített verzióval kapcsolatos módosításokat és javasolt módosításokat.

A MetricValue mező "null" értéket tartalmaz a megoldott naplókeresési riasztások értesítéseihez.

Ez az elvárt működés. Az állapotalapú naplókeresési riasztások értékalapú helyett időalapú megoldási logikát használnak. Az Azure Monitor null metrikaértéket küld, mivel nincs olyan érték, amely a riasztás feloldását eredményezte, hanem az eltelt idő.

A dimenziólista üres, vagy a riasztás címe nem tartalmaz dimenziónevet

Ha olyan naplókeresési riasztási szabálya van, amely nem ad vissza eredményt, a riasztás a várt módon aktiválható, de a dimenziólista üres, vagy a riasztás címe nem tartalmaz dimenziónevet. Ha egy lekérdezés nem ad vissza sorokat, az erőforrás-azonosító mező (amely a dimenzió- és címmezők feltöltésének alapja) üres.

Egy tevékenységnapló-riasztás adatai hiányoznak

A tevékenységnapló-riasztások olyan riasztások , amelyek az Azure-tevékenységnaplóba írt eseményeken alapulnak, például az Azure-erőforrások létrehozásával, frissítésével vagy törlésével, a szolgáltatás állapotával és az erőforrás állapotával kapcsolatos eseményeken, vagy az Azure Advisor és az Azure Policy eredményein alapulnak. Ha a tevékenységnapló alapján kapott riasztást, de néhány szükséges mező hiányzik vagy helytelen, először ellenőrizze magát a tevékenységnaplóban lévő eseményeket. Ha az Azure-erőforrás nem írta meg a keresett mezőket a tevékenységnapló eseményében, ezek a mezők nem szerepelnek a megfelelő riasztásban.

Az egyéni tulajdonságok hiányoznak az e-mailekből, SMS-ekből vagy leküldéses értesítésekből.

Az egyéni tulajdonságok csak a műveletek hasznos adatainak lesznek átadva, például webhookokhoz, Azure-függvényekhez vagy logikai alkalmazásokhoz. Az egyéni tulajdonságok nem szerepelnek az értesítésekben (e-mail/SMS/leküldés).

A riasztásfeldolgozási szabály nem a várt módon működik

Ha aktivált riasztást lát a portálon, de egy kapcsolódó riasztásfeldolgozási szabály nem a várt módon működött, kövesse az alábbi lépéseket:

1. Engedélyezve van a riasztásfeldolgozási szabály?

   Ellenőrizze a riasztásfeldolgozási szabály állapotmezőben, hogy engedélyezve van-e a kapcsolódó műveleti szerepkör. Alapértelmezés szerint a portál csak az engedélyezett riasztási szabályokat jeleníti meg, a szűrőt azonban módosíthatja úgy, hogy az összes szabály megjelenjen.

   

   Ha nincs engedélyezve, a riasztásfeldolgozási szabályt úgy engedélyezheti, hogy kijelöli, majd az Engedélyezés gombra kattint.

2. Szolgáltatásállapotra vonatkozik a riasztás?

   Szolgáltatásállapot riasztásokat a riasztásfeldolgozási szabályok nem befolyásolják. Ha tehát egy szolgáltatásállapot-riasztásokat tartalmazó hatókörhöz konfigurált riasztásfeldolgozási szabály van konfigurálva, míg a szolgáltatásállapot-riasztások a hatókörön belül vannak, a riasztásfeldolgozási szabály nem lesz hatással rájuk.

3. A riasztásfeldolgozási szabály feldolgozta a riasztást?

   Válassza ki az aktivált riasztást a portálon, és tekintse meg az Előzmények lapot, és ellenőrizze, hogy a riasztásfeldolgozási szabály feldolgozásra került-e.

   Íme egy példa a riasztásfeldolgozási szabályra, amely az összes műveletcsoportot letiltja:

   

   Íme egy példa egy riasztásfeldolgozási szabályra, amely egy másik műveletcsoportot ad hozzá:

   

4. A riasztásfeldolgozási szabály hatóköre és szűrője megfelel az aktivált riasztásnak?

   Ha úgy gondolja, hogy a riasztásfeldolgozási szabálynak aktiválnia kellett volna, de nem, vagy nem kellett volna aktiválnia, de mégis, gondosan vizsgálja meg a riasztásfeldolgozási szabály hatókörét, és szűrje a feltételeket, és hasonlítsa össze azokat az aktivált riasztás tulajdonságaival.

Riasztásfeldolgozási szabályok létrehozásával, frissítésével vagy törlésével kapcsolatos problémák az Azure Portalon

Ha hibaüzenetet kapott egy riasztásfeldolgozási szabály létrehozása, frissítése vagy törlése során, kövesse az alábbi lépéseket:

1. Ellenőrizze az engedélyeket.

   A figyelési közreműködő beépített szerepkörével vagy a riasztásfeldolgozási szabályokhoz és riasztásokhoz kapcsolódó konkrét engedélyekkel kell rendelkeznie.

2. Ellenőrizze a riasztásfeldolgozási szabály paramétereit.

   Ellenőrizze a riasztásfeldolgozási szabály dokumentációját vagy a PowerShell Set-AzAlertProcessingRule parancs riasztásfeldolgozási szabályát.

Következő lépések

• Azure Monitor-metrikariasztások hibaelhárítása
• Azure Monitor naplókeresési riasztások hibaelhárítása